draft-ietf-anima-bootstrapping-keyinfra-28.txt   draft-ietf-anima-bootstrapping-keyinfra-29.txt 
ANIMA WG M. Pritikin ANIMA WG M. Pritikin
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Richardson Intended status: Standards Track M. Richardson
Expires: March 21, 2020 Sandelman Expires: April 30, 2020 Sandelman
T. Eckert T. Eckert
Futurewei USA Futurewei USA
M. Behringer M. Behringer
K. Watsen K. Watsen
Watsen Networks Watsen Networks
September 18, 2019 October 28, 2019
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-28 draft-ietf-anima-bootstrapping-keyinfra-29
Abstract Abstract
This document specifies automated bootstrapping of an Autonomic This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Remote Secure Key Infrastructure (BRSKI) Control Plane. To do this a Secure Key Infrastructure is
is created using manufacturer installed X.509 certificates, in bootstrapped. This is done using manufacturer-installed X.509
combination with a manufacturer's authorizing service, both online certificates, in combination with a manufacturer's authorizing
and offline. Bootstrapping a new device can occur using a routable service, both online and offline. We call this process the
address and a cloud service, or using only link-local connectivity, Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
or on limited/disconnected networks. Support for lower security Bootstrapping a new device can occur using a routable address and a
models, including devices with minimal identity, is described for cloud service, or using only link-local connectivity, or on limited/
legacy reasons but not encouraged. Bootstrapping to is complete when disconnected networks. Support for deployment models with less
the cryptographic identity of the new key infrastructure is stringent security requirements is included. Bootstrapping is
successfully deployed to the device. The established secure complete when the cryptographic identity of the new key
connection can be used to deploy a locally issued certificate to the infrastructure is successfully deployed to the device. The
device as well. established secure connection can be used to deploy a locally issued
certificate to the device as well.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2020.
This Internet-Draft will expire on March 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 10 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 10
1.3.1. Support environment . . . . . . . . . . . . . . . . . 10 1.3.1. Support environment . . . . . . . . . . . . . . . . . 10
1.3.2. Constrained environments . . . . . . . . . . . . . . 11 1.3.2. Constrained environments . . . . . . . . . . . . . . 11
1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12
1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12 1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12
1.4. Leveraging the new key infrastructure / next steps . . . 12 1.4. Leveraging the new key infrastructure / next steps . . . 12
1.5. Requirements for Autonomic Network Infrastructure (ANI) 1.5. Requirements for Autonomic Network Infrastructure (ANI)
devices . . . . . . . . . . . . . . . . . . . . . . . . . 12 devices . . . . . . . . . . . . . . . . . . . . . . . . . 13
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13
2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17
2.3.1. Identification of the Pledge . . . . . . . . . . . . 18 2.3.1. Identification of the Pledge . . . . . . . . . . . . 18
2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 18 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 18
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 20 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 20
2.5. Architectural Components . . . . . . . . . . . . . . . . 23 2.5. Architectural Components . . . . . . . . . . . . . . . . 23
2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 2, line 51 skipping to change at page 3, line 4
2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23
2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23
2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23
2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 24 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 24
2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24
2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24
2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24
2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 25 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 25
2.8. Determining the MASA to contact . . . . . . . . . . . . . 25 2.8. Determining the MASA to contact . . . . . . . . . . . . . 25
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26
3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 26 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 27
3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 29
4. Proxying details (Pledge - Proxy - 4. Proxying details (Pledge - Proxy -
Registrar) . . . . . . . . . . . . . . . . . . . . . . . . . 32 Registrar) . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 33 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 33
4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 35 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 35
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 36 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 36
4.3. Proxy discovery and communication of Registrar . . . . . 36 4.3. Proxy discovery and communication of Registrar . . . . . 36
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 37 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 38
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 39 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 39
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 40 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 40
5.3. Registrar Authorization of 5.3. Registrar Authorization of
Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 41 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 42 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 43
5.4.1. MASA authentication of 5.4.1. MASA authentication of
customer Registrar . . . . . . . . . . . . . . . . . 42 customer Registrar . . . . . . . . . . . . . . . . . 43
5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 43 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 44
5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 45 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 46
5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 45 5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 46
5.5.3. MASA checking of voucher request signature . . . . . 45 5.5.3. MASA checking of voucher request signature . . . . . 46
5.5.4. MASA verification of domain registrar . . . . . . . . 46 5.5.4. MASA verification of domain registrar . . . . . . . . 47
5.5.5. MASA verification of pledge prior-signed-voucher- 5.5.5. MASA verification of pledge prior-signed-voucher-
request . . . . . . . . . . . . . . . . . . . . . . . 47 request . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 47 5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 48
5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 47 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 48
5.6.1. Pledge voucher verification . . . . . . . . . . . . . 50 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 51
5.6.2. Pledge authentication of provisional TLS connection . 51 5.6.2. Pledge authentication of provisional TLS connection . 52
5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 52 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 53
5.8. Registrar audit-log request . . . . . . . . . . . . . . . 53 5.8. Registrar audit-log request . . . . . . . . . . . . . . . 54
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 54 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 55
5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 57 5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 58
5.8.3. Registrar audit log verification . . . . . . . . . . 57 5.8.3. Registrar audit log verification . . . . . . . . . . 58
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 59 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 60
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 59 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 60
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 59 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 60
5.9.3. EST Client Certificate Request . . . . . . . . . . . 60 5.9.3. EST Client Certificate Request . . . . . . . . . . . 61
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 60 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 61
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 61 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 62
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 61 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 62
6. Clarification of transfer-encoding . . . . . . . . . . . . . 62 6. Clarification of transfer-encoding . . . . . . . . . . . . . 63
7. Reduced security operational modes . . . . . . . . . . . . . 62 7. Reduced security operational modes . . . . . . . . . . . . . 63
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 62 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 63
7.2. Pledge security reductions . . . . . . . . . . . . . . . 63 7.2. Pledge security reductions . . . . . . . . . . . . . . . 64
7.3. Registrar security reductions . . . . . . . . . . . . . . 64 7.3. Registrar security reductions . . . . . . . . . . . . . . 65
7.4. MASA security reductions . . . . . . . . . . . . . . . . 65 7.4. MASA security reductions . . . . . . . . . . . . . . . . 66
7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 65 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 66
7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 66 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 67
7.4.3. Updating or extending voucher trust anchors . . . . . 66 7.4.3. Updating or extending voucher trust anchors . . . . . 67
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 67 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69
8.2. Well-known EST registration . . . . . . . . . . . . . . . 67 8.2. Well-known EST registration . . . . . . . . . . . . . . . 69
8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 68 8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 69
8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 68 8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 69
8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 68 8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70
8.6. MUD File Extension for the MASA . . . . . . . . . . . . . 69 8.6. MUD File Extension for the MASA . . . . . . . . . . . . . 70
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 69 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 70
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 70 9.1. Operational Requirements . . . . . . . . . . . . . . . . 71
10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 70 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 72
10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 71 9.1.2. Domain Owner Operational Requirements . . . . . . . . 72
10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 71 9.1.3. Device Operational Requirements . . . . . . . . . . . 73
10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 74 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 73
10.5. Manufacturers and Grey market equipment . . . . . . . . 75 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 73
10.6. Some mitigations for meddling by manufacturers . . . . . 75 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 74
10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 76 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 75
11. Security Considerations . . . . . . . . . . . . . . . . . . . 77 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 77
11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 78 10.5. Manufacturers and Grey market equipment . . . . . . . . 78
11.2. Availability of good random numbers . . . . . . . . . . 78 10.6. Some mitigations for meddling by manufacturers . . . . . 79
11.3. Freshness in Voucher-Requests . . . . . . . . . . . . . 79 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 80
11.4. Trusting manufacturers . . . . . . . . . . . . . . . . . 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 80
11.5. Manufacturer Maintenance of trust anchors . . . . . . . 81 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 81
11.5.1. Compromise of Manufacturer IDevID signing keys . . . 82 11.2. Availability of good random numbers . . . . . . . . . . 82
11.5.2. Compromise of MASA signing keys . . . . . . . . . . 83 11.3. Freshness in Voucher-Requests . . . . . . . . . . . . . 82
11.5.3. Compromise of MASA web service . . . . . . . . . . . 85 11.4. Trusting manufacturers . . . . . . . . . . . . . . . . . 83
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 85 11.5. Manufacturer Maintenance of trust anchors . . . . . . . 84
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 11.5.1. Compromise of Manufacturer IDevID signing keys . . . 86
13.1. Normative References . . . . . . . . . . . . . . . . . . 86 11.5.2. Compromise of MASA signing keys . . . . . . . . . . 86
13.2. Informative References . . . . . . . . . . . . . . . . . 89 11.5.3. Compromise of MASA web service . . . . . . . . . . . 88
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 92 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 89
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 93 13.1. Normative References . . . . . . . . . . . . . . . . . . 89
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 93 13.2. Informative References . . . . . . . . . . . . . . . . . 93
Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 94 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 96
Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 96 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 96
D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 96 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 96
D.1.1. MASA key pair for voucher signatures . . . . . . . . 96 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 97
D.1.2. Manufacturer key pair for IDevID signatures . . . . . 96 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 97
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 97 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 100
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 99 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 100
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 100 D.1.1. MASA key pair for voucher signatures . . . . . . . . 100
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 101 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 100
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 104 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 101
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 109 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 103
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 104
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 105
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 108
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117
1. Introduction 1. Introduction
BRSKI provides a solution for secure zero-touch (automated) bootstrap The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
of new (unconfigured) devices that are called pledges in this provides a solution for secure zero-touch (automated) bootstrap of
document. new (unconfigured) devices that are called pledges in this document.
Pledges have an IDevID installed in them at the factory.
"BRSKI" is pronounced like "brewski", a colloquial term for beer in
Canada and parts of the US-midwest. [brewski]
This document primarily provides for the needs of the ISP and This document primarily provides for the needs of the ISP and
Enterprise focused ANIMA Autonomic Control Plane (ACP) Enterprise focused ANIMA Autonomic Control Plane (ACP)
[I-D.ietf-anima-autonomic-control-plane]. This bootstrap process [I-D.ietf-anima-autonomic-control-plane]. This bootstrap process
satisfies the [RFC7575] section 3.3 of making all operations secure satisfies the [RFC7575] requirements of section 3.3 of making all
by default. Other users of the BRSKI protocol will need to provide operations secure by default. Other users of the BRSKI protocol will
separate applicability statements that include privacy and security need to provide separate applicability statements that include
considerations appropriate to that deployment. Section 9 explains privacy and security considerations appropriate to that deployment.
the details applicability for this the ACP usage. Section 9 explains the detailed applicability for this the ACP usage.
The BRSKI protocol requires a significant amount of communication The BRSKI protocol requires a significant amount of communication
between manufacturer and owner: in it's default modes it provides a between manufacturer and owner: in its default modes it provides a
cryptographic transfer of control to the initial owner. In it's cryptographic transfer of control to the initial owner. In its
strongest modes, it leverages sales channel information to identify strongest modes, it leverages sales channel information to identify
the owner in advance. Resale of devices is possible, provided that the owner in advance. Resale of devices is possible, provided that
the manufacturer is willing to authorize the transfer. Mechanisms to the manufacturer is willing to authorize the transfer. Mechanisms to
enable transfers of ownership without manufacturer authorization are enable transfers of ownership without manufacturer authorization are
not included in this version of the protocol, but could be designed not included in this version of the protocol, but could be designed
into future versions. into future versions.
This document describes how pledges discover (or are discovered by) This document describes how pledges discover (or are discovered by)
an element of the network domain to which the pledge belongs that an element of the network domain to which the pledge belongs that
will perform the bootstrap. This element (device) is called the will perform the bootstrap. This element (device) is called the
skipping to change at page 6, line 21 skipping to change at page 6, line 30
message that is a minor extension to the voucher format (see message that is a minor extension to the voucher format (see
Section 3) defined by [RFC8366]. Section 3) defined by [RFC8366].
BRSKI results in the pledge storing an X.509 root certificate BRSKI results in the pledge storing an X.509 root certificate
sufficient for verifying the registrar identity. In the process a sufficient for verifying the registrar identity. In the process a
TLS connection is established that can be directly used for TLS connection is established that can be directly used for
Enrollment over Secure Transport (EST). In effect BRSKI provides an Enrollment over Secure Transport (EST). In effect BRSKI provides an
automated mechanism for the "Bootstrap Distribution of CA automated mechanism for the "Bootstrap Distribution of CA
Certificates" described in [RFC7030] Section 4.1.1 wherein the pledge Certificates" described in [RFC7030] Section 4.1.1 wherein the pledge
"MUST [...] engage a human user to authorize the CA certificate using "MUST [...] engage a human user to authorize the CA certificate using
out-of-band" information". With BRSKI the pledge now can automate out-of-band" information. With BRSKI the pledge now can automate
this process using the voucher. Integration with a complete EST this process using the voucher. Integration with a complete EST
enrollment is optional but trivial. enrollment is optional but trivial.
BRSKI is agile enough to support bootstrapping alternative key BRSKI is agile enough to support bootstrapping alternative key
infrastructures, such as a symmetric key solutions, but no such infrastructures, such as a symmetric key solutions, but no such
system is described in this document. system is described in this document.
1.1. Prior Bootstrapping Approaches 1.1. Prior Bootstrapping Approaches
To literally "pull yourself up by the bootstraps" is an impossible To literally "pull yourself up by the bootstraps" is an impossible
skipping to change at page 7, line 48 skipping to change at page 8, line 7
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are defined for clarity: The following terms are defined for clarity:
domainID: The domain IDentity is a unique hash based upon the ANI: The Autonomic Network Infrastructure as defined by
Registrar CA's certificate. Section 5.8.2 specifies how it is [I-D.ietf-anima-reference-model]. This document details specific
calculated. requirements for pledges, proxies and registrars when they are
part of an ANI.
Circuit Proxy: A stateful implementation of the join proxy. This is
the assumed type of proxy.
drop-ship: The physical distribution of equipment containing the drop-ship: The physical distribution of equipment containing the
"factory default" configuration to a final destination. In zero- "factory default" configuration to a final destination. In zero-
touch scenarios there is no staging or pre-configuration during touch scenarios there is no staging or pre-configuration during
drop-ship. drop-ship.
Domain: The set of entities that share a common local trust anchor.
This includes the proxy, registrar, Domain Certificate Authority,
Management components and any existing entity that is already a
member of the domain.
domainID: The domain IDentity is a unique value based upon the
Registrar CA's certificate. Section 5.8.2 specifies how it is
calculated.
Domain CA: The domain Certification Authority (CA) provides
certification functionalities to the domain. At a minimum it
provides certification functionalities to a registrar and manages
the private key that defines the domain. Optionally, it certifies
all elements.
enrollment: The process where a device presents key material to a
network and acquires a network-specific identity. For example
when a certificate signing request is presented to a certification
authority and a certificate is obtained in response.
imprint: The process where a device obtains the cryptographic key imprint: The process where a device obtains the cryptographic key
material to identify and trust future interactions with a network. material to identify and trust future interactions with a network.
This term is taken from Konrad Lorenz's work in biology with new This term is taken from Konrad Lorenz's work in biology with new
ducklings: during a critical period, the duckling would assume ducklings: during a critical period, the duckling would assume
that anything that looks like a mother duck is in fact their that anything that looks like a mother duck is in fact their
mother. An equivalent for a device is to obtain the fingerprint mother. An equivalent for a device is to obtain the fingerprint
of the network's root certification authority certificate. A of the network's root certification authority certificate. A
device that imprints on an attacker suffers a similar fate to a device that imprints on an attacker suffers a similar fate to a
duckling that imprints on a hungry wolf. Securely imprinting is a duckling that imprints on a hungry wolf. Securely imprinting is a
primary focus of this document [imprinting]. The analogy to primary focus of this document [imprinting]. The analogy to
Lorenz's work was first noted in [Stajano99theresurrecting]. Lorenz's work was first noted in [Stajano99theresurrecting].
enrollment: The process where a device presents key material to a IDevID: An Initial Device Identity X.509 certificate installed by
network and acquires a network-specific identity. For example the vendor on new equipment. This is a term from 802.1AR [IDevID]
when a certificate signing request is presented to a certification
authority and a certificate is obtained in response.
Pledge: The prospective device, which has an identity installed at
the factory.
Voucher: A signed artifact from the MASA that indicates to a pledge
the cryptographic identity of the registrar it should trust.
There are different types of vouchers depending on how that trust
is asserted. Multiple voucher types are defined in [RFC8366]
Domain: The set of entities that share a common local trust anchor. IPIP Proxy: A stateless proxy alternative.
This includes the proxy, registrar, Domain Certificate Authority,
Management components and any existing entity that is already a
member of the domain.
Domain CA: The domain Certification Authority (CA) provides Join Proxy: A domain entity that helps the pledge join the domain.
certification functionalities to the domain. At a minimum it A join proxy facilitates communication for devices that find
provides certification functionalities to a registrar and manages themselves in an environment where they are not provided
the private key that defines the domain. Optionally, it certifies connectivity until after they are validated as members of the
all elements. domain. For simplicity this document sometimes uses the term of
'proxy' to indicate the join proxy. The pledge is unaware that
they are communicating with a proxy rather than directly with a
registrar.
Join Registrar (and Coordinator): A representative of the domain Join Registrar (and Coordinator): A representative of the domain
that is configured, perhaps autonomically, to decide whether a new that is configured, perhaps autonomically, to decide whether a new
device is allowed to join the domain. The administrator of the device is allowed to join the domain. The administrator of the
domain interfaces with a "join registrar (and coordinator)" to domain interfaces with a "join registrar (and coordinator)" to
control this process. Typically a join registrar is "inside" its control this process. Typically a join registrar is "inside" its
domain. For simplicity this document often refers to this as just domain. For simplicity this document often refers to this as just
"registrar". Within [I-D.ietf-anima-reference-model] this is "registrar". Within [I-D.ietf-anima-reference-model] this is
referred to as the "join registrar autonomic service agent". referred to as the "join registrar autonomic service agent".
Other communities use the abbreviation "JRC". Other communities use the abbreviation "JRC".
(Public) Key Infrastructure: The collection of systems and processes LDevID: A Local Device Identity X.509 certificate installed by the
that sustain the activities of a public key system. The registrar owner of the equipment. This is a term from 802.1AR [IDevID]
acts as an [RFC5280] and [RFC5272] (see section 7) "Registration
Authority".
Join Proxy: A domain entity that helps the pledge join the domain.
A join proxy facilitates communication for devices that find
themselves in an environment where they are not provided
connectivity until after they are validated as members of the
domain. For simplicity this document sometimes uses the term of
'proxy' to indicate the join proxy. The pledge is unaware that
they are communicating with a proxy rather than directly with a
registrar.
Circuit Proxy: A stateful implementation of the join proxy. This is manufacturer: the term manufacturer is used throughout this document
the assumed type of proxy. to be the entity that created the device. This is typically the
"original equipment manufacturer" or OEM, but in more complex
situations it could be a "value added retailer" (VAR), or possibly
even a systems integrator. In general, it a goal of BRSKI to
eliminate small distinctions between different sales channels.
The reason for this is that it permits a single device, with a
uniform firmware load, to be shipped directly to all customers.
This eliminates costs for the manufacturer. This also reduces the
number of products supported in the field increasing the chance
that firmware will be more up to date.
IPIP Proxy: A stateless proxy alternative. MASA Audit-Log: A list of previous owners maintained by the MASA on
a per device (per pledge) basis. Described in Section 5.8.1.
MASA Service: A third-party Manufacturer Authorized Signing MASA Service: A third-party Manufacturer Authorized Signing
Authority (MASA) service on the global Internet. The MASA signs Authority (MASA) service on the global Internet. The MASA signs
vouchers. It also provides a repository for audit-log information vouchers. It also provides a repository for audit-log information
of privacy protected bootstrapping events. It does not track of privacy protected bootstrapping events. It does not track
ownership. ownership.
MASA Audit-Log: A list of previous owners maintained by the MASA on nonced: a voucher (or request) that contains a nonce (the normal
a per device (per pledge) basis. Described in Section 5.8.1. case).
nonceless: a voucher (or request) that does not contain a nonce,
relying upon accurate clocks for expiration, or which does not
expire.
offline: When an architectural component cannot perform realtime
communications with a peer, either due to network connectivity or
because the peer is turned off, the operation is said to be
occurring offline.
Ownership Tracker: An Ownership Tracker service on the global Ownership Tracker: An Ownership Tracker service on the global
Internet. The Ownership Tracker uses business processes to Internet. The Ownership Tracker uses business processes to
accurately track ownership of all devices shipped against domains accurately track ownership of all devices shipped against domains
that have purchased them. Although optional, this component that have purchased them. Although optional, this component
allows vendors to provide additional value in cases where their allows vendors to provide additional value in cases where their
sales and distribution channels allow for accurately tracking of sales and distribution channels allow for accurately tracking of
such ownership. Ownership tracking information is indicated in such ownership. Ownership tracking information is indicated in
vouchers as described in [RFC8366] vouchers as described in [RFC8366]
IDevID: An Initial Device Identity X.509 certificate installed by Pledge: The prospective (unconfigured) device, which has an identity
the vendor on new equipment. installed at the factory.
(Public) Key Infrastructure: The collection of systems and processes
that sustain the activities of a public key system. The registrar
acts as an [RFC5280] and [RFC5272] (see section 7) "Registration
Authority".
TOFU: Trust on First Use. Used similarly to [RFC7435]. This is TOFU: Trust on First Use. Used similarly to [RFC7435]. This is
where a pledge device makes no security decisions but rather where a pledge device makes no security decisions but rather
simply trusts the first registrar it is contacted by. This is simply trusts the first registrar it is contacted by. This is
also known as the "resurrecting duckling" model. also known as the "resurrecting duckling" model.
nonced: a voucher (or request) that contains a nonce (the normal Voucher: A signed artifact from the MASA that indicates to a pledge
case). the cryptographic identity of the registrar it should trust.
There are different types of vouchers depending on how that trust
nonceless: a voucher (or request) that does not contain a nonce, is asserted. Multiple voucher types are defined in [RFC8366]
relying upon accurate clocks for expiration, or which does not
expire.
manufacturer: the term manufacturer is used throughout this document
to be the entity that created the device. This is typically the
"original equipment manufacturer" or OEM, but in more complex
situations it could be a "value added retailer" (VAR), or possibly
even a systems integrator. In general, it a goal of BRSKI to
eliminate small distinctions between different sales channels.
The reason for this is that it permits a single device, with a
uniform firmware load, to be shipped directly to all customers.
This eliminates costs for the manufacturer. This also reduces the
number of products supported in the field increasing the chance
that firmware will be more up to date.
ANI: The Autonomic Network Infrastructure as defined by
[I-D.ietf-anima-reference-model]. This document details specific
requirements for pledges, proxies and registrars when they are
part of an ANI.
offline: When an architectural component cannot perform realtime
communications with a peer, either due to network connectivity or
because the peer is turned off, the operation is said to be
occurring offline.
1.3. Scope of solution 1.3. Scope of solution
1.3.1. Support environment 1.3.1. Support environment
This solution (BRSKI) can support large router platforms with multi- This solution (BRSKI) can support large router platforms with multi-
gigabit inter-connections, mounted in controlled access data centers. gigabit inter-connections, mounted in controlled access data centers.
But this solution is not exclusive to large equipment: it is intended But this solution is not exclusive to large equipment: it is intended
to scale to thousands of devices located in hostile environments, to scale to thousands of devices located in hostile environments,
such as ISP provided CPE devices which are drop-shipped to the end such as ISP provided CPE devices which are drop-shipped to the end
skipping to change at page 11, line 27 skipping to change at page 11, line 37
Questions have been posed as to whether this solution is suitable in Questions have been posed as to whether this solution is suitable in
general for Internet of Things (IoT) networks. This depends on the general for Internet of Things (IoT) networks. This depends on the
capabilities of the devices in question. The terminology of capabilities of the devices in question. The terminology of
[RFC7228] is best used to describe the boundaries. [RFC7228] is best used to describe the boundaries.
The solution described in this document is aimed in general at non- The solution described in this document is aimed in general at non-
constrained (i.e., class 2+ [RFC7228]) devices operating on a non- constrained (i.e., class 2+ [RFC7228]) devices operating on a non-
Challenged network. The entire solution as described here is not Challenged network. The entire solution as described here is not
intended to be useable as-is by constrained devices operating on intended to be useable as-is by constrained devices operating on
challenged networks (such as 802.15.4 LLNs). challenged networks (such as 802.15.4 Low-power Lossy Networks
(LLN)s).
Specifically, there are protocol aspects described here that might Specifically, there are protocol aspects described here that might
result in congestion collapse or energy-exhaustion of intermediate result in congestion collapse or energy-exhaustion of intermediate
battery powered routers in an LLN. Those types of networks SHOULD battery powered routers in an LLN. Those types of networks should
NOT use this solution. These limitations are predominately related not use this solution. These limitations are predominately related
to the large credential and key sizes required for device to the large credential and key sizes required for device
authentication. Defining symmetric key techniques that meet the authentication. Defining symmetric key techniques that meet the
operational requirements is out-of-scope but the underlying protocol operational requirements is out-of-scope but the underlying protocol
operations (TLS handshake and signing structures) have sufficient operations (TLS handshake and signing structures) have sufficient
algorithm agility to support such techniques when defined. algorithm agility to support such techniques when defined.
The imprint protocol described here could, however, be used by non- The imprint protocol described here could, however, be used by non-
energy constrained devices joining a non-constrained network (for energy constrained devices joining a non-constrained network (for
instance, smart light bulbs are usually mains powered, and speak instance, smart light bulbs are usually mains powered, and speak
802.11). It could also be used by non-constrained devices across a 802.11). It could also be used by non-constrained devices across a
skipping to change at page 12, line 42 skipping to change at page 12, line 48
certificate has optionally been issued from the Domain CA. This certificate has optionally been issued from the Domain CA. This
makes it possible to securely deploy functionalities across the makes it possible to securely deploy functionalities across the
domain, e.g: domain, e.g:
o Device management. o Device management.
o Routing authentication. o Routing authentication.
o Service discovery. o Service discovery.
The major intended beneficiary is that it possible to use the The major intended benefit is that it possible to use the credentials
credentials deployed by this protocol to secure the Autonomic Control deployed by this protocol to secure the Autonomic Control Plane (ACP)
Plane (ACP) ([I-D.ietf-anima-autonomic-control-plane]). ([I-D.ietf-anima-autonomic-control-plane]).
1.5. Requirements for Autonomic Network Infrastructure (ANI) devices 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices
The BRSKI protocol can be used in a number of environments. Some of The BRSKI protocol can be used in a number of environments. Some of
the options in this document are the result of requirements that are the options in this document are the result of requirements that are
out of the ANI scope. This section defines the base requirements for out of the ANI scope. This section defines the base requirements for
ANI devices. ANI devices.
For devices that intend to become part of an Autonomic Network For devices that intend to become part of an Autonomic Network
Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes
an Autonomic Control Plane an Autonomic Control Plane
([I-D.ietf-anima-autonomic-control-plane]), the BRSKI protocol MUST ([I-D.ietf-anima-autonomic-control-plane]), the BRSKI protocol MUST
be implemented. be implemented.
The pledge must perform discovery of the proxy as described in The pledge must perform discovery of the proxy as described in
Section 4.1 using GRASP DULL [I-D.ietf-anima-grasp] M_FLOOD Section 4.1 using Generic Autonomic Signaling Protocol (GRASP)'s DULL
announcements. [I-D.ietf-anima-grasp] M_FLOOD announcements.
Upon successfully validating a voucher artifact, a status telemetry Upon successfully validating a voucher artifact, a status telemetry
MUST be returned. See Section 5.7. MUST be returned. See Section 5.7.
An ANIMA ANI pledge MUST implement the EST automation extensions An ANIMA ANI pledge MUST implement the EST automation extensions
described in Section 5.9. They supplement the [RFC7030] EST to described in Section 5.9. They supplement the [RFC7030] EST to
better support automated devices that do not have an end user. better support automated devices that do not have an end user.
The ANI Join Registrar Autonomic Service Agent (ASA) MUST support all The ANI Join Registrar Autonomic Service Agent (ASA) MUST support all
the BRSKI and above listed EST operations. the BRSKI and above listed EST operations.
skipping to change at page 14, line 6 skipping to change at page 14, line 6
All ANI devices SHOULD support the BRSKI proxy function, using All ANI devices SHOULD support the BRSKI proxy function, using
circuit proxies over the ACP. (See Section 4.3) circuit proxies over the ACP. (See Section 4.3)
2. Architectural Overview 2. Architectural Overview
The logical elements of the bootstrapping framework are described in The logical elements of the bootstrapping framework are described in
this section. Figure 1 provides a simplified overview of the this section. Figure 1 provides a simplified overview of the
components. components.
+------------------------+ +------------------------+
+--------------Drop Ship--------------->| Vendor Service | +--------------Drop Ship----------------| Vendor Service |
| +------------------------+ | +------------------------+
| | M anufacturer| | | | M anufacturer| |
| | A uthorized |Ownership| | | A uthorized |Ownership|
| | S igning |Tracker | | | S igning |Tracker |
| | A uthority | | | | A uthority | |
| +--------------+---------+ | +--------------+---------+
| ^ | ^
| | BRSKI- | | BRSKI-
V | MASA V | MASA
+-------+ ............................................|... +-------+ ............................................|...
skipping to change at page 15, line 21 skipping to change at page 15, line 21
/ Factory \ / Factory \
\ default / \ default /
-----+------ -----+------
| |
+------v-------+ +------v-------+
| (1) Discover | | (1) Discover |
+------------> | +------------> |
| +------+-------+ | +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | (2) Identity | | | (2) Identify |
^------------+ | ^------------+ |
| rejected +------+-------+ | rejected +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | (3) Request | | | (3) Request |
| | Join | | | Join |
| +------+-------+ | +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | (4) Imprint | | | (4) Imprint |
skipping to change at page 16, line 15 skipping to change at page 16, line 15
2. Identify itself. This is done by presenting an X.509 IDevID 2. Identify itself. This is done by presenting an X.509 IDevID
credential to the discovered registrar (via the proxy) in a TLS credential to the discovered registrar (via the proxy) in a TLS
handshake. (The registrar credentials are only provisionally handshake. (The registrar credentials are only provisionally
accepted at this time). accepted at this time).
3. Request to join the discovered registrar. A unique nonce is 3. Request to join the discovered registrar. A unique nonce is
included ensuring that any responses can be associated with this included ensuring that any responses can be associated with this
particular bootstrapping attempt. particular bootstrapping attempt.
4. Imprint on the registrar. This requires verification of the 4. Imprint on the registrar. This requires verification of the
manufacturer service provided voucher. A voucher contains manufacturer-service-provided voucher. A voucher contains
sufficient information for the pledge to complete authentication sufficient information for the pledge to complete authentication
of a registrar. This document details this step in depth. of a registrar. This document details this step in depth.
5. Enroll. After imprint an authenticated TLS (HTTPS) connection 5. Enroll. After imprint an authenticated TLS (HTTPS) connection
exists between pledge and registrar. Enrollment over Secure exists between pledge and registrar. Enrollment over Secure
Transport (EST) [RFC7030] can then be used to obtain a domain Transport (EST) [RFC7030] can then be used to obtain a domain
certificate from a registrar. certificate from a registrar.
The pledge is now a member of, and can be managed by, the domain and The pledge is now a member of, and can be managed by, the domain and
will only repeat the discovery aspects of bootstrapping if it is will only repeat the discovery aspects of bootstrapping if it is
returned to factory default settings. returned to factory default settings.
This specification details integration with EST enrollment so that This specification details integration with EST enrollment so that
pledges can optionally obtain a locally issued certificate, although pledges can optionally obtain a locally issued certificate, although
any REST interface could be integrated in future work. any Representational State Transfer (REST) (see [REST]) interface
could be integrated in future work.
2.2. Secure Imprinting using Vouchers 2.2. Secure Imprinting using Vouchers
A voucher is a cryptographically protected artifact (using a digital A voucher is a cryptographically protected artifact (using a digital
signature) to the pledge device authorizing a zero-touch imprint on signature) to the pledge device authorizing a zero-touch imprint on
the registrar domain. the registrar domain.
The format and cryptographic mechanism of vouchers is described in The format and cryptographic mechanism of vouchers is described in
detail in [RFC8366]. detail in [RFC8366].
skipping to change at page 18, line 12 skipping to change at page 18, line 12
This is consistent with [RFC5280] section 4.2.1.3, which does not This is consistent with [RFC5280] section 4.2.1.3, which does not
require key usage restrictions for end entity certificates. require key usage restrictions for end entity certificates.
2.3.1. Identification of the Pledge 2.3.1. Identification of the Pledge
In the context of BRSKI, pledges have a 1:1 relationship with a In the context of BRSKI, pledges have a 1:1 relationship with a
"serial-number". This serial-number is used both in the "serial- "serial-number". This serial-number is used both in the "serial-
number" field of voucher or voucher-requests (see Section 3) and in number" field of voucher or voucher-requests (see Section 3) and in
local policies on registrar or MASA (see Section 5). local policies on registrar or MASA (see Section 5).
The serialNumber fields is defined in [RFC5280], and is a SHOULD The serialNumber fields is defined in [RFC5280]. That specification
field in [IDevID]. IDevID certificates for use with this protocol allows for the field to be omitted if there is a good technical
MUST include the "serialNumber" attribute with the device's unique reason. IDevID certificates for use with this protocol are REQUIRED
to include the "serialNumber" attribute with the device's unique
serial number (from [IDevID] section 7.2.8, and [RFC5280] section serial number (from [IDevID] section 7.2.8, and [RFC5280] section
4.1.2.4's list of standard attributes). 4.1.2.2's list of standard attributes).
The serialNumber field is used as follows by the pledge to build the The serialNumber field is used as follows by the pledge to build the
"serial-number" that is placed in the voucher-request. In order to "serial-number" that is placed in the voucher-request. In order to
build it, the fields need to be converted into a serial-number of build it, the fields need to be converted into a serial-number of
"type string". "type string".
An example of a printable form of the "serialNumber" field is An example of a printable form of the "serialNumber" field is
provided in [RFC4519] section 2.31 ("WI-3005"). That section further provided in [RFC4519] section 2.31 ("WI-3005"). That section further
provides equality and syntax attributes. provides equality and syntax attributes.
skipping to change at page 19, line 4 skipping to change at page 19, line 5
Section 7.4 of [RFC5280]. Section 7.4 of [RFC5280].
The URI provides the authority information. The BRSKI "/.well-known" The URI provides the authority information. The BRSKI "/.well-known"
tree ([RFC5785]) is described in Section 5. tree ([RFC5785]) is described in Section 5.
A complete URI MAY be in this extension, including the 'scheme', A complete URI MAY be in this extension, including the 'scheme',
'authority', and 'path', The complete URI will typically be used in 'authority', and 'path', The complete URI will typically be used in
diagnostic or experimental situations. Typically, (and in diagnostic or experimental situations. Typically, (and in
consideration to constrained systems), this SHOULD be reduced to only consideration to constrained systems), this SHOULD be reduced to only
the 'authority', in which case a scheme of "https://" ([RFC7230] the 'authority', in which case a scheme of "https://" ([RFC7230]
section 2.7.3) and 'path' of "/.well-known/est" is to be assumed, as section 2.7.3) and 'path' of "/.well-known/est" is to be assumed.
explained in Section 5.
The registrar can assume that only the 'authority' is present in the The registrar can assume that only the 'authority' is present in the
extension, if there are no slash ("/") characters in the extension. extension, if there are no slash ("/") characters in the extension.
Section 7.4 of [RFC5280] calls out various schemes that MUST be Section 7.4 of [RFC5280] calls out various schemes that MUST be
supported, including LDAP, HTTP and FTP. However, the registrar MUST supported, including LDAP, HTTP and FTP. However, the registrar MUST
use HTTPS for the BRSKI-MASA connection. use HTTPS for the BRSKI-MASA connection.
The new extension is identified as follows: The new extension is identified as follows:
skipping to change at page 23, line 32 skipping to change at page 23, line 32
2.5.3. Domain Registrar 2.5.3. Domain Registrar
The domain's registrar operates as the BRSKI-MASA client when The domain's registrar operates as the BRSKI-MASA client when
requesting vouchers from the MASA (see Section 5.4). The registrar requesting vouchers from the MASA (see Section 5.4). The registrar
operates as the BRSKI-EST server when pledges request vouchers (see operates as the BRSKI-EST server when pledges request vouchers (see
Section 5.1). The registrar operates as the BRSKI-EST server Section 5.1). The registrar operates as the BRSKI-EST server
"Registration Authority" if the pledge requests an end entity "Registration Authority" if the pledge requests an end entity
certificate over the BRSKI-EST connection (see Section 5.9). certificate over the BRSKI-EST connection (see Section 5.9).
The registrar uses an Implicit Trust Anchor database for The registrar uses an Implicit Trust Anchor database for
authenticating the BRSKI-MASA TLS connection MASA certificate. The authenticating the BRSKI-MASA connection's MASA TLS Server
registrar uses a different Implicit Trust Anchor database for Certificate. Configuration or distribution of trust anchors is out-
authenticating the BRSKI-EST TLS connection pledge client of-scope for this specification.
certificate. Configuration or distribution of these trust anchor
databases is out-of-scope of this specification.
Configuration or distribution of this trust anchor databases is out- The registrar uses a different Implicit Trust Anchor database for
of-scope of this specification. Note that the trust anchors in/ authenticating the BRSKI-EST connection's Pledge TLS Client
excluded from the database will affect which manufacturers' devices Certificate. Configuration or distribution of the BRSKI-EST client
are acceptable to the registrar as pledges, and can also be used to trust anchors is out-of-scope of this specification. Note that the
limit the set of MASAs that are trusted for enrollment. trust anchors in/excluded from the database will affect which
manufacturers' devices are acceptable to the registrar as pledges,
and can also be used to limit the set of MASAs that are trusted for
enrollment.
2.5.4. Manufacturer Service 2.5.4. Manufacturer Service
The Manufacturer Service provides two logically separate functions: The Manufacturer Service provides two logically separate functions:
the Manufacturer Authorized Signing Authority (MASA) described in the Manufacturer Authorized Signing Authority (MASA) described in
Section 5.5 and Section 5.6, and an ownership tracking/auditing Section 5.5 and Section 5.6, and an ownership tracking/auditing
function described in Section 5.7 and Section 5.8. function described in Section 5.7 and Section 5.8.
2.5.5. Public Key Infrastructure (PKI) 2.5.5. Public Key Infrastructure (PKI)
skipping to change at page 25, line 36 skipping to change at page 25, line 36
become the local registrar. become the local registrar.
In order to support these scenarios, the pledge MAY contact a well In order to support these scenarios, the pledge MAY contact a well
known URI of a cloud registrar if a local registrar cannot be known URI of a cloud registrar if a local registrar cannot be
discovered or if the pledge's target use cases do not include a local discovered or if the pledge's target use cases do not include a local
registrar. registrar.
If the pledge uses a well known URI for contacting a cloud registrar If the pledge uses a well known URI for contacting a cloud registrar
a manufacturer-assigned Implicit Trust Anchor database (see a manufacturer-assigned Implicit Trust Anchor database (see
[RFC7030]) MUST be used to authenticate that service as described in [RFC7030]) MUST be used to authenticate that service as described in
[RFC6125]. This is consistent with the human user configuration of [RFC6125]. The use of a DNS-ID for validation is appropriate, and it
an EST server URI in [RFC7030] which also depends on RFC6125. may include wildcard components on the left-mode side. This is
consistent with the human user configuration of an EST server URI in
[RFC7030] which also depends on RFC6125.
2.8. Determining the MASA to contact 2.8. Determining the MASA to contact
The registrar needs to be able to contact a MASA that is trusted by The registrar needs to be able to contact a MASA that is trusted by
the pledge in order to obtain vouchers. There are three mechanisms the pledge in order to obtain vouchers. There are three mechanisms
described: described:
The device's Initial Device Identifier (IDevID) will normally contain The device's Initial Device Identifier (IDevID) will normally contain
the MASA URL as detailed in Section 2.3. This is the RECOMMENDED the MASA URL as detailed in Section 2.3. This is the RECOMMENDED
mechanism. mechanism.
skipping to change at page 26, line 12 skipping to change at page 26, line 14
the MASA URL from the MUD file. The MUD file extension for the MASA the MASA URL from the MUD file. The MUD file extension for the MASA
URL is defined in Appendix C. URL is defined in Appendix C.
It can be operationally difficult to ensure the necessary X.509 It can be operationally difficult to ensure the necessary X.509
extensions are in the pledge's IDevID due to the difficulty of extensions are in the pledge's IDevID due to the difficulty of
aligning current pledge manufacturing with software releases and aligning current pledge manufacturing with software releases and
development. As a final fallback the registrar MAY be manually development. As a final fallback the registrar MAY be manually
configured or distributed with a MASA URL for each manufacturer. configured or distributed with a MASA URL for each manufacturer.
Note that the registrar can only select the configured MASA URL based Note that the registrar can only select the configured MASA URL based
on the trust anchor -- so manufacturers can only leverage this on the trust anchor -- so manufacturers can only leverage this
approach if they ensure a single MASA URL works for all pledge's approach if they ensure a single MASA URL works for all pledges
associated with each trust anchor. associated with each trust anchor.
3. Voucher-Request artifact 3. Voucher-Request artifact
Voucher-requests are how vouchers are requested. The semantics of Voucher-requests are how vouchers are requested. The semantics of
the vouchers are described below, in the YANG model. the voucher-request are described below, in the YANG model.
A pledge forms the "pledge voucher-request", signs it with it's A pledge forms the "pledge voucher-request", signs it with it's
IDevID and submits it to the registrar. IDevID and submits it to the registrar.
The registrar in turn forms the "registrar voucher-request", signs it The registrar in turn forms the "registrar voucher-request", signs it
with it's Registrar keypair and submits it to the MASA. with it's Registrar keypair and submits it to the MASA.
The "proximity-registrar-cert" leaf is used in the pledge voucher- The "proximity-registrar-cert" leaf is used in the pledge voucher-
requests. This provides a method for the pledge to assert the requests. This provides a method for the pledge to assert the
registrar's proximity. registrar's proximity.
This network proximity results from the following properties in the
ACP context: the pledge is connected to the Join Proxy (Section 4)
using a Link-Local IPv6 connection. While the Join Proxy does not
participate in any meaningful sense in the cryptography of the TLS
connection (such as via a Channel Binding), the Registrar can observe
that the connection is via the private ACP (ULA) address of the join
proxy, and could not come from outside the ACP. The Pledge must
therefore be at most one IPv6 Link-Local hop away from an existing
node on the ACP.
Other users of BRSKI will need to define other kinds of assertions if
the network proximity described above does not match their needs.
The "prior-signed-voucher-request" leaf is used in registrar voucher- The "prior-signed-voucher-request" leaf is used in registrar voucher-
requests. If present, it is the signed pledge voucher-request requests. If present, it is the signed pledge voucher-request
artifact. This provides a method for the registrar to forward the artifact. This provides a method for the registrar to forward the
pledge's signed request to the MASA. This completes transmission of pledge's signed request to the MASA. This completes transmission of
the signed "proximity-registrar-cert" leaf. the signed "proximity-registrar-cert" leaf.
Unless otherwise signaled (outside the voucher-request artifact), the Unless otherwise signaled (outside the voucher-request artifact), the
signing structure is as defined for vouchers, see [RFC8366]. signing structure is as defined for vouchers, see [RFC8366].
3.1. Nonceless Voucher Requests 3.1. Nonceless Voucher Requests
skipping to change at page 27, line 35 skipping to change at page 27, line 49
+---- nonce? binary +---- nonce? binary
+---- last-renewal-date? yang:date-and-time +---- last-renewal-date? yang:date-and-time
+---- prior-signed-voucher-request? binary +---- prior-signed-voucher-request? binary
+---- proximity-registrar-cert? binary +---- proximity-registrar-cert? binary
Figure 5: YANG Tree diagram for Voucher-Request Figure 5: YANG Tree diagram for Voucher-Request
3.3. Examples 3.3. Examples
This section provides voucher-request examples for illustration This section provides voucher-request examples for illustration
purposes. The contents of the certificate have been elided to save purposes. These examples show the JSON prior to CMS wrapping. JSON
space. For detailed examples, see Appendix D.2. These examples encoding rules specify that any binary content by base64 encoded
([RFC4648]). The contents of the certificate have been elided to
save space. For detailed examples, see Appendix D.2. These examples
conform to the encoding rules defined in [RFC7951]. conform to the encoding rules defined in [RFC7951].
Example (1) The following example illustrates a pledge voucher- Example (1) The following example illustrates a pledge voucher-
request. The assertion leaf is indicated as 'proximity' request. The assertion leaf is indicated as 'proximity'
and the registrar's TLS server certificate is included and the registrar's TLS server certificate is included
in the 'proximity-registrar-cert' leaf. See in the 'proximity-registrar-cert' leaf. See
Section 5.2. Section 5.2.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
skipping to change at page 28, line 23 skipping to change at page 28, line 31
} }
Figure 6: JSON representation of example Voucher-Request Figure 6: JSON representation of example Voucher-Request
Example (2) The following example illustrates a registrar voucher- Example (2) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is request. The 'prior-signed-voucher-request' leaf is
populated with the pledge's voucher-request (such as the populated with the pledge's voucher-request (such as the
prior example). The pledge's voucher-request is a prior example). The pledge's voucher-request is a
binary CMS signed object. In the JSON encoding used binary CMS signed object. In the JSON encoding used
here it must be base64 encoded. The nonce and assertion here it must be base64 encoded. The nonce and assertion
MAY be carried forward from the pledge request to the have been carried forward from the pledge request to the
registrar request. The serial-number is extracted from registrar request. The serial-number is extracted from
the pledge's Client Certificate from the TLS connection. the pledge's Client Certificate from the TLS connection.
See Section 5.5. See Section 5.5.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"assertion" : "proximity", "assertion" : "proximity",
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue==",
"serial-number": "JADA123456789" "serial-number": "JADA123456789",
"prior-signed-voucher-request": "base64encodedvalue==" "prior-signed-voucher-request": "base64encodedvalue=="
} }
} }
Figure 7: JSON representation of example Prior-Signed Voucher-Request Figure 7: JSON representation of example Prior-Signed Voucher-Request
Example (3) The following example illustrates a registrar voucher- Example (3) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is not request. The 'prior-signed-voucher-request' leaf is not
populated with the pledge's voucher-request nor is the populated with the pledge's voucher-request nor is the
nonce leaf. This form might be used by a registrar nonce leaf. This form might be used by a registrar
requesting a voucher when the pledge can not communicate requesting a voucher when the pledge can not communicate
with the registrar (such as when it is powered down, or with the registrar (such as when it is powered down, or
still in packaging), and therefore could not submit a still in packaging), and therefore could not submit a
nonce. This scenario is most useful when the registrar nonce. This scenario is most useful when the registrar
is aware that it will not be able to reach the MASA is aware that it will not be able to reach the MASA
during deployment. See Section 5.5. during deployment. See Section 5.5.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue==",
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
Figure 8: JSON representation of Offline Voucher-Request Figure 8: JSON representation of Offline Voucher-Request
3.4. YANG Module 3.4. YANG Module
Following is a YANG [RFC7950] module formally extending the [RFC8366] Following is a YANG [RFC7950] module formally extending the [RFC8366]
voucher into a voucher-request. voucher into a voucher-request.
<CODE BEGINS> file "ietf-voucher-request@2018-02-14.yang" <CODE BEGINS> file "ietf-voucher-request@2018-02-14.yang"
module ietf-voucher-request { module ietf-voucher-request {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-voucher-request"; "urn:ietf:params:xml:ns:yang:ietf-voucher-request";
prefix "vch"; prefix "vcr";
import ietf-restconf { import ietf-restconf {
prefix rc; prefix rc;
description "This import statement is only present to access description "This import statement is only present to access
the yang-data extension defined in RFC 8040."; the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol"; reference "RFC 8040: RESTCONF Protocol";
} }
import ietf-voucher { import ietf-voucher {
prefix v; prefix vch;
description "This module defines the format for a voucher, description "This module defines the format for a voucher,
which is produced by a pledge's manufacturer or which is produced by a pledge's manufacturer or
delegate (MASA) to securely assign a pledge to delegate (MASA) to securely assign a pledge to
an 'owner', so that the pledge may establish a secure an 'owner', so that the pledge may establish a secure
connection to the owner's network infrastructure"; connection to the owner's network infrastructure";
reference "RFC 8366: Voucher Profile for Bootstrapping Protocols"; reference "RFC 8366: Voucher Profile for Bootstrapping Protocols";
} }
organization organization
"IETF ANIMA Working Group"; "IETF ANIMA Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/anima/> "WG Web: <https://datatracker.ietf.org/wg/anima/>
WG List: <mailto:anima@ietf.org> WG List: <mailto:anima@ietf.org>
Author: Kent Watsen Author: Kent Watsen
<mailto:kwatsen@juniper.net> <mailto:kent+ietf@watsen.net>
Author: Michael H. Behringer Author: Michael H. Behringer
<mailto:Michael.H.Behringer@gmail.com> <mailto:Michael.H.Behringer@gmail.com>
Author: Toerless Eckert Author: Toerless Eckert
<mailto:ttef@cs.fau.de> <mailto:tte+ietf@cs.fau.de>
Author: Max Pritikin Author: Max Pritikin
<mailto:pritikin@cisco.com> <mailto:pritikin@cisco.com>
Author: Michael Richardson Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>"; <mailto:mcr+ietf@sandelman.ca>";
description description
"This module defines the format for a voucher request. "This module defines the format for a voucher request.
It is a superset of the voucher itself. It is a superset of the voucher itself.
It provides content to the MASA for consideration It provides content to the MASA for consideration
during a voucher request. during a voucher request.
skipping to change at page 31, line 7 skipping to change at page 31, line 14
// Top-level statement // Top-level statement
rc:yang-data voucher-request-artifact { rc:yang-data voucher-request-artifact {
uses voucher-request-grouping; uses voucher-request-grouping;
} }
// Grouping defined for future usage // Grouping defined for future usage
grouping voucher-request-grouping { grouping voucher-request-grouping {
description description
"Grouping to allow reuse/extensions in future work."; "Grouping to allow reuse/extensions in future work.";
uses v:voucher-artifact-grouping { uses vch:voucher-artifact-grouping {
refine "voucher/created-on" { refine "voucher/created-on" {
mandatory false; mandatory false;
} }
refine "voucher/pinned-domain-cert" { refine "voucher/pinned-domain-cert" {
mandatory false; mandatory false;
} }
refine "voucher/domain-cert-revocation-checks" { refine "voucher/domain-cert-revocation-checks" {
description "The domain-cert-revocation-checks field description "The domain-cert-revocation-checks field
is not valid in a voucher request, and is not valid in a voucher request, and
any occurence MUST be ignored"; any occurence MUST be ignored";
} }
refine "voucher/assertion" { refine "voucher/assertion" {
mandatory false; mandatory false;
description "Any assertion included in voucher description "Any assertion included in registrar voucher
requests SHOULD be ignored by the MASA."; requests SHOULD be ignored by the MASA.";
} }
augment "voucher" { augment "voucher" {
description description
"Adds leaf nodes appropriate for requesting vouchers."; "Adds leaf nodes appropriate for requesting vouchers.";
leaf prior-signed-voucher-request { leaf prior-signed-voucher-request {
type binary; type binary;
description description
skipping to change at page 32, line 34 skipping to change at page 32, line 41
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 9: YANG module for Voucher-Request Figure 9: YANG module for Voucher-Request
4. Proxying details (Pledge - Proxy - Registrar) 4. Proxying details (Pledge - Proxy - Registrar)
This section applies is normative for uses with an ANIMA ACP. The This section is normative for uses with an ANIMA ACP. The use of
use of GRASP mechanism part of the ACP. Other users of BRSKI will GRASP mechanism is part of the ACP. Other users of BRSKI will need
need to define an equivalent proxy mechanism, and an equivalent to define an equivalent proxy mechanism, and an equivalent mechanism
mechanism to configure the proxy. to configure the proxy.
The role of the proxy is to facilitate communications. The proxy The role of the proxy is to facilitate communications. The proxy
forwards packets between the pledge and a registrar that has been forwards packets between the pledge and a registrar that has been
provisioned to the proxy via full GRASP ACP discovery. provisioned to the proxy via full GRASP ACP discovery.
This section defines a stateful proxy mechanism which is referred to This section defines a stateful proxy mechanism which is referred to
as a "circuit" proxy. This is a form of Application Level Gateway as a "circuit" proxy. This is a form of Application Level Gateway
([RFC2663] section 2.9). ([RFC2663] section 2.9).
The proxy does not terminate the TLS handshake: it passes streams of The proxy does not terminate the TLS handshake: it passes streams of
bytes onward without examination. A proxy MUST NOT assume any bytes onward without examination. A proxy MUST NOT assume any
specific TLS version. Please see {{RFC8446}} section 9.3 for details specific TLS version. Please see [RFC8446] section 9.3 for details
on TLS invariants. on TLS invariants.
A Registrar can directly provide the proxy announcements described A Registrar can directly provide the proxy announcements described
below, in which case the announced port can point directly to the below, in which case the announced port can point directly to the
Registrar itself. In this scenario the pledge is unaware that there Registrar itself. In this scenario the pledge is unaware that there
is no proxing occurring. This is useful for Registrars which are is no proxying occurring. This is useful for Registrars which are
servicing pledges on directly connected networks. servicing pledges on directly connected networks.
As a result of the proxy Discovery process in Section 4.1.1, the port As a result of the proxy Discovery process in Section 4.1.1, the port
number exposed by the proxy does not need to be well known, or number exposed by the proxy does not need to be well known, or
require an IANA allocation. require an IANA allocation.
During the discovery of the Registrar by the Join Proxy, the Join During the discovery of the Registrar by the Join Proxy, the Join
Proxy will also learn which kinds of proxy mechanisms are available. Proxy will also learn which kinds of proxy mechanisms are available.
This will allow the Join Proxy to use the lowest impact mechanism This will allow the Join Proxy to use the lowest impact mechanism
which the Join Proxy and Registrar have in common. which the Join Proxy and Registrar have in common.
skipping to change at page 34, line 11 skipping to change at page 34, line 20
2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp])
announcements of the objective: "AN_Proxy". See section announcements of the objective: "AN_Proxy". See section
Section 4.1.1 for the details of the objective. The pledge MAY Section 4.1.1 for the details of the objective. The pledge MAY
listen concurrently for other sources of information, see listen concurrently for other sources of information, see
Appendix B. Appendix B.
Once a proxy is discovered the pledge communicates with a registrar Once a proxy is discovered the pledge communicates with a registrar
through the proxy using the bootstrapping protocol defined in through the proxy using the bootstrapping protocol defined in
Section 5. Section 5.
While the GRASP M_FLOOD mechanism is passive for the pledge, the While the GRASP M_FLOOD mechanism is passive for the pledge, the non-
optional other methods (mDNS, and IPv4 methods) are active. The normative other methods (mDNS, and IPv4 methods) described Appendix B
pledge SHOULD run those methods in parallel with listening to for the are active. The pledge SHOULD run those methods in parallel with
M_FLOOD. The active methods SHOULD back-off by doubling to a maximum listening to for the M_FLOOD. The active methods SHOULD back-off by
of one hour to avoid overloading the network with discovery attempts. doubling to a maximum of one hour to avoid overloading the network
Detection of change of physical link status (Ethernet carrier for with discovery attempts. Detection of change of physical link status
instance) SHOULD reset the back off timers. (Ethernet carrier for instance) SHOULD reset the back off timers.
The pledge could discover more than one proxy on a given physical The pledge could discover more than one proxy on a given physical
interface. The pledge can have a multitude of physical interfaces as interface. The pledge can have a multitude of physical interfaces as
well: a layer-2/3 Ethernet switch may have hundreds of physical well: a layer-2/3 Ethernet switch may have hundreds of physical
ports. ports.
Each possible proxy offer SHOULD be attempted up to the point where a Each possible proxy offer SHOULD be attempted up to the point where a
voucher is received: while there are many ways in which the attempt valid voucher is received: while there are many ways in which the
may fail, it does not succeed until the voucher has been validated. attempt may fail, it does not succeed until the voucher has been
validated.
The connection attempts via a single proxy SHOULD exponentially back- The connection attempts via a single proxy SHOULD exponentially back-
off to a maximum of one hour to avoid overloading the network off to a maximum of one hour to avoid overloading the network
infrastructure. The back-off timer for each MUST be independent of infrastructure. The back-off timer for each MUST be independent of
other connection attempts. other connection attempts.
Connection attempts SHOULD be run in parallel to avoid head of queue Connection attempts SHOULD be run in parallel to avoid head of queue
problems wherein an attacker running a fake proxy or registrar could problems wherein an attacker running a fake proxy or registrar could
perform protocol actions intentionally slowly. Connection attempts perform protocol actions intentionally slowly. Connection attempts
to different proxies SHOULD be sent with an interval of 3 to 5s. The to different proxies SHOULD be sent with an interval of 3 to 5s. The
skipping to change at page 35, line 11 skipping to change at page 35, line 21
SHOULD periodically retry any manufacturer-specific mechanisms. The SHOULD periodically retry any manufacturer-specific mechanisms. The
pledge MAY prioritize selection order as appropriate for the pledge MAY prioritize selection order as appropriate for the
anticipated environment. anticipated environment.
4.1.1. Proxy GRASP announcements 4.1.1. Proxy GRASP announcements
A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself.
This announcement can be within the same message as the ACP This announcement can be within the same message as the ACP
announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. announcement detailed in [I-D.ietf-anima-autonomic-control-plane].
The formal CDDL [RFC8610] definition is: The formal Concise Data Definition Language (CDDL) [RFC8610]
definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_Proxy", objective-flags, loop-count, objective = ["AN_Proxy", objective-flags, loop-count,
objective-value] objective-value]
ttl = 180000 ; 180,000 ms (3 minutes) ttl = 180000 ; 180,000 ms (3 minutes)
initiator = ACP address to contact Registrar initiator = ACP address to contact Registrar
objective-flags = sync-only ; as in GRASP spec objective-flags = sync-only ; as in GRASP spec
skipping to change at page 36, line 49 skipping to change at page 37, line 20
initiator = ACP address to contact Registrar initiator = ACP address to contact Registrar
objective-flags = sync-only ; as in GRASP spec objective-flags = sync-only ; as in GRASP spec
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 255 ; mandatory maximum loop-count = 255 ; mandatory maximum
objective-value = text ; name of the (list of) of supported objective-value = text ; name of the (list of) of supported
; protocols: "EST-TLS" for RFC7030. ; protocols: "EST-TLS" for RFC7030.
Figure 13: CDDL definition for Registrar announcement message Figure 13: CDDL definition for Registrar announcement message
The M_FLOOD message MUST be sent periodically. The default SHOULD be The M_FLOOD message MUST be sent periodically. The default period
60 seconds, the value SHOULD be operator configurable but SHOULD be SHOULD be 60 seconds, the value SHOULD be operator configurable but
not smaller than 60 seconds. The frequency of sending MUST be such SHOULD NOT be smaller than 60 seconds. The frequency of sending MUST
that the aggregate amount of periodic M_FLOODs from all flooding be such that the aggregate amount of periodic M_FLOODs from all
sources cause only negligible traffic across the ACP. flooding sources cause only negligible traffic across the ACP.
Here are some examples of locators for illustrative purposes. Only Here are some examples of locators for illustrative purposes. Only
the first one ($transport-protocol = 6, TCP) is defined in this the first one ($transport-protocol = 6, TCP) is defined in this
document and is mandatory to implement. document and is mandatory to implement.
locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443]
locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
A protocol of 6 indicates that TCP proxying on the indicated port is A protocol of 6 indicates that TCP proxying on the indicated port is
skipping to change at page 38, line 7 skipping to change at page 38, line 28
The communication channel between the registrar and MASA is similarly The communication channel between the registrar and MASA is similarly
described as extensions to EST within the same "/.well-known" tree. described as extensions to EST within the same "/.well-known" tree.
For clarity this channel is referred to as "BRSKI-MASA". (See For clarity this channel is referred to as "BRSKI-MASA". (See
Figure 1). Figure 1).
The MASA URI is "https://" authority "/.well-known/est". The MASA URI is "https://" authority "/.well-known/est".
BRSKI uses existing CMS message formats for existing EST operations. BRSKI uses existing CMS message formats for existing EST operations.
BRSKI uses JSON [RFC8259] for all new operations defined here, and BRSKI uses JSON [RFC8259] for all new operations defined here, and
voucher formats. voucher formats. In all places where a binary value must be carried
in a JSON string, the use of base64 format ([RFC4648] section 4) is
to be used, as per [RFC7951] section 6.6.
While EST section 3.2 does not insist upon use of HTTP persistent While EST section 3.2 does not insist upon use of HTTP persistent
connections, ([RFC7230] section 6.3) BRSKI-EST connections SHOULD use connections ([RFC7230] section 6.3), BRSKI-EST connections SHOULD use
persistent connections. The intention of this guidance is to ensure persistent connections. The intention of this guidance is to ensure
the provisional TLS state occurs only once, and that the subsequent the provisional TLS state occurs only once, and that the subsequent
resolution of the provision state is not subject to a MITM attack resolution of the provision state is not subject to a MITM attack
during a critical phase. during a critical phase.
If non-persistent connections are used, then both the pledge and the If non-persistent connections are used, then both the pledge and the
registrar MUST remember the certificates seen, and also sent for the registrar MUST remember the certificates seen, and also sent for the
first connection. They MUST check each subsequent connections for first connection. They MUST check each subsequent connections for
the same certificates, and each end MUST use the same certificates as the same certificates, and each end MUST use the same certificates as
well. This places a difficult restriction on rolling certificates on well. This places a difficult restriction on rolling certificates on
skipping to change at page 38, line 32 skipping to change at page 39, line 8
Summarized automation extensions for the BRSKI-EST flow are: Summarized automation extensions for the BRSKI-EST flow are:
o The pledge either attempts concurrent connections via each o The pledge either attempts concurrent connections via each
discovered proxy, or it times out quickly and tries connections in discovered proxy, or it times out quickly and tries connections in
series, as explained at the end of Section 5.1. series, as explained at the end of Section 5.1.
o The pledge provisionally accepts the registrar certificate during o The pledge provisionally accepts the registrar certificate during
the TLS handshake as detailed in Section 5.1. the TLS handshake as detailed in Section 5.1.
o The pledge requests and validates a voucher using the new REST o The pledge requests a voucher using the new REST calls described
calls described below. below. This voucher is then validated.
o The pledge completes authentication of the server certificate as o The pledge completes authentication of the server certificate as
detailed in Section 5.6.1. This moves the BRSKI-EST TLS detailed in Section 5.6.1. This moves the BRSKI-EST TLS
connection out of the provisional state. connection out of the provisional state.
o Mandatory bootstrap steps conclude with voucher status telemetry o Mandatory bootstrap steps conclude with voucher status telemetry
(see Section 5.7). (see Section 5.7).
The BRSKI-EST TLS connection can now be used for EST enrollment. The BRSKI-EST TLS connection can now be used for EST enrollment.
skipping to change at page 39, line 21 skipping to change at page 39, line 46
5.1. BRSKI-EST TLS establishment details 5.1. BRSKI-EST TLS establishment details
The pledge establishes the TLS connection with the registrar through The pledge establishes the TLS connection with the registrar through
the circuit proxy (see Section 4) but the TLS handshake is with the the circuit proxy (see Section 4) but the TLS handshake is with the
registrar. The BRSKI-EST pledge is the TLS client and the BRSKI-EST registrar. The BRSKI-EST pledge is the TLS client and the BRSKI-EST
registrar is the TLS server. All security associations established registrar is the TLS server. All security associations established
are between the pledge and the registrar regardless of proxy are between the pledge and the registrar regardless of proxy
operations. operations.
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED. REQUIRED on the Pledge side. TLS 1.3 (or newer) SHOULD be available
on the Registrar server interface, and the Registrar client
interface, but TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be
available on the MASA server interface, but TLS 1.2 MAY be used.
Establishment of the BRSKI-EST TLS connection is as specified in EST Establishment of the BRSKI-EST TLS connection is as specified in EST
[RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates"
[RFC7030] wherein the client is authenticated with the IDevID [RFC7030] wherein the client is authenticated with the IDevID
certificate, and the EST server (the registrar) is provisionally certificate, and the EST server (the registrar) is provisionally
authenticated with an unverified server certificate. Configuration authenticated with an unverified server certificate. Configuration
or distribution of the trust anchor database used for validating the or distribution of the trust anchor database used for validating the
IDevID certificate is out-of-scope of this specification. Note that IDevID certificate is out-of-scope of this specification. Note that
the trust anchors in/excluded from the database will affect which the trust anchors in/excluded from the database will affect which
manufacturers' devices are acceptable to the registrar as pledges, manufacturers' devices are acceptable to the registrar as pledges,
and can also be used to limit the set of MASAs that are trusted for and can also be used to limit the set of MASAs that are trusted for
enrollment. enrollment.
skipping to change at page 39, line 40 skipping to change at page 40, line 20
the trust anchors in/excluded from the database will affect which the trust anchors in/excluded from the database will affect which
manufacturers' devices are acceptable to the registrar as pledges, manufacturers' devices are acceptable to the registrar as pledges,
and can also be used to limit the set of MASAs that are trusted for and can also be used to limit the set of MASAs that are trusted for
enrollment. enrollment.
The signatures in the certificate MUST be validated even if a signing The signatures in the certificate MUST be validated even if a signing
key can not (yet) be validated. The certificate (or chain) MUST be key can not (yet) be validated. The certificate (or chain) MUST be
retained for later validation. retained for later validation.
A self-signed certificate for the Registrar is acceptable as the A self-signed certificate for the Registrar is acceptable as the
voucher will validate it. voucher can validate it upon successful enrollment.
The pledge performs input validation of all data received until a The pledge performs input validation of all data received until a
voucher is verified as specified in Section 5.6.1 and the TLS voucher is verified as specified in Section 5.6.1 and the TLS
connection leaves the provisional state. Until these operations are connection leaves the provisional state. Until these operations are
complete the pledge could be communicating with an attacker. complete the pledge could be communicating with an attacker.
The pledge code needs to be written with the assumption that all data The pledge code needs to be written with the assumption that all data
is being transmitted at this point to an unauthenticated peer, and is being transmitted at this point to an unauthenticated peer, and
that received data, while inside a TLS connection, MUST be considered that received data, while inside a TLS connection, MUST be considered
untrusted. This particularly applies to HTTP headers and CMS untrusted. This particularly applies to HTTP headers and CMS
structures that make up the voucher. structures that make up the voucher.
A pledge that can connect to multiple registries concurrently SHOULD A pledge that can connect to multiple Registrars concurrently SHOULD
do so. Some devices may be unable to do so for lack of threading, or do so. Some devices may be unable to do so for lack of threading, or
resource issues. Concurrent connections defeat attempts by a resource issues. Concurrent connections defeat attempts by a
malicious proxy from causing a TCP Slowloris-like attack (see malicious proxy from causing a TCP Slowloris-like attack (see
[slowloris]). [slowloris]).
A pledge that can not maintain as many connections as there are A pledge that can not maintain as many connections as there are
eligible proxies will need to rotate among the various choices, eligible proxies will need to rotate among the various choices,
terminating connections that do not appear to be making progress. If terminating connections that do not appear to be making progress. If
no connection is making progess after 5 seconds then the pledge no connection is making progress after 5 seconds then the pledge
SHOULD drop the oldest connection and go on to a different proxy: the SHOULD drop the oldest connection and go on to a different proxy: the
proxy that has been communicated with least recently. If there were proxy that has been communicated with least recently. If there were
no other proxies discovered, the pledge MAY continue to wait, as long no other proxies discovered, the pledge MAY continue to wait, as long
as it is concurrently listening for new proxy announcements. as it is concurrently listening for new proxy announcements.
5.2. Pledge Requests Voucher from the Registrar 5.2. Pledge Requests Voucher from the Registrar
When the pledge bootstraps it makes a request for a voucher from a When the pledge bootstraps it makes a request for a voucher from a
registrar. registrar.
This is done with an HTTPS POST using the operation path value of This is done with an HTTPS POST using the operation path value of
"/.well-known/est/requestvoucher". "/.well-known/est/requestvoucher".
The pledge voucher-request Content-Type is: The pledge voucher-request Content-Type is:
application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON
document that has been signed using a CMS structure", and the document that has been signed using a CMS structure", and the
voucher-request described in Section 3 is created in the same way. voucher-request described in Section 3 is created in the same way.
The media type is the same as defined in [RFC8366]. and is also The media type is the same as defined in [RFC8366]. This is also
used for the pledge voucher-request. The pledge MUST sign the used for the pledge voucher-request. The pledge MUST sign the
request using the Section 2.3 credential. request using the Section 2.3 credential.
Registrar implementations SHOULD anticipate future media types but of Registrar implementations SHOULD anticipate future media types but of
course will simply fail the request if those types are not yet known. course will simply fail the request if those types are not yet known.
The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header
field indicating the acceptable media type for the voucher response. field indicating the acceptable media type for the voucher response.
The "application/voucher-cms+json" media type is defined in [RFC8366] The "application/voucher-cms+json" media type is defined in [RFC8366]
but constrained voucher formats are expected in the future. but constrained voucher formats are expected in the future.
Registrars and MASA are expected to be flexible in what they accept. Registrars and MASA are expected to be flexible in what they accept.
The pledge populates the voucher-request fields as follows: The pledge populates the voucher-request fields as follows:
created-on: Pledges that have a realtime clock are RECOMMENDED to created-on: Pledges that have a realtime clock are RECOMMENDED to
populate this field with the current date and time in yang:date- populate this field with the current date and time in yang:date-
and-time format. This provides additional information to the and-time format. This provides additional information to the
MASA. Pledges that have no real-time clocks MAY omit this field. MASA. Pledges that have no real-time clocks MAY omit this field.
nonce: The pledge voucher-request MUST contain a cryptographically nonce: The pledge voucher-request MUST contain a cryptographically
strong random or pseudo-random number nonce. (see [RFC4086]) Doing strong random or pseudo-random number nonce (see [RFC4086] section
so ensures Section 2.6.1 functionality. The nonce MUST NOT be 6.2). As the nonce is usually generated very early in the boot
reused for multiple bootstrapping attempts. (The registrar sequence there is a concern that the same nonce might generated
voucher-request MAY omit the nonce as per Section 3.1) across multiple boots, or after a factory reset. Difference
nonces MUST NOT generated for each bootstrapping attempt, whether
in series or concurrently. The freshness of this nonce mitigates
against the lack of real-time clock as explained in Section 2.6.1.
assertion: The pledge indicates support for the mechanism described
in this document, by putting the value "proximity" in the voucher-
request, and MUST include the "proximity-registrar-cert" field
(below).
proximity-registrar-cert: In a pledge voucher-request this is the proximity-registrar-cert: In a pledge voucher-request this is the
first certificate in the TLS server 'certificate_list' sequence first certificate in the TLS server 'certificate_list' sequence
(see [RFC5246]) presented by the registrar to the pledge. That (see [RFC5246]) presented by the registrar to the pledge. That
is, it is the end-entity certificate. This MUST be populated in a is, it is the end-entity certificate. This MUST be populated in a
pledge voucher-request if the "proximity" assertion is populated. pledge voucher-request.
serial-number The serial number of the pledge is included in the
voucher-request from the Pledge. This value is included as a
sanity check only, but it is not to be forwarded by the Registrar
as described in Section 5.5.
All other fields MAY be omitted in the pledge voucher-request. All other fields MAY be omitted in the pledge voucher-request.
An example JSON payload of a pledge voucher-request is in Section 3.3 An example JSON payload of a pledge voucher-request is in Section 3.3
Example 1. Example 1.
The registrar confirms that the assertion is 'proximity' and that The registrar confirms that the assertion is 'proximity' and that
pinned 'proximity-registrar-cert' is the Registrar's certificate. If pinned 'proximity-registrar-cert' is the Registrar's certificate. If
this validation fails, then there a On-Path Attacker (MITM), and the this validation fails, then there is an On-Path Attacker (MITM), and
connection MUST be closed after the returning an HTTP 401 error code. the connection MUST be closed after the returning an HTTP 401 error
code.
5.3. Registrar Authorization of Pledge 5.3. Registrar Authorization of Pledge
In a fully automated network all devices must be securely identified In a fully automated network all devices must be securely identified
and authorized to join the domain. and authorized to join the domain.
A Registrar accepts or declines a request to join the domain, based A Registrar accepts or declines a request to join the domain, based
on the authenticated identity presented. For different networks, on the authenticated identity presented. For different networks,
examples of Automated acceptance may include: examples of automated acceptance may include:
o allow any device of a specific type (as determined by the X.509 o allow any device of a specific type (as determined by the X.509
IDevID), IDevID),
o allow any device from a specific vendor (as determined by the o allow any device from a specific vendor (as determined by the
X.509 IDevID), X.509 IDevID),
o allow a specific device from a vendor (as determined by the X.509 o allow a specific device from a vendor (as determined by the X.509
IDevID) against a domain white list. (The mechanism for checking IDevID) against a domain white list. (The mechanism for checking
a shared white list potentially used by multiple Registrars is out a shared white list potentially used by multiple Registrars is out
skipping to change at page 42, line 15 skipping to change at page 43, line 11
If authorization is successful the registrar obtains a voucher from If authorization is successful the registrar obtains a voucher from
the MASA service (see Section 5.5) and returns that MASA signed the MASA service (see Section 5.5) and returns that MASA signed
voucher to the pledge as described in Section 5.6. voucher to the pledge as described in Section 5.6.
5.4. BRSKI-MASA TLS establishment details 5.4. BRSKI-MASA TLS establishment details
The BRSKI-MASA TLS connection is a 'normal' TLS connection The BRSKI-MASA TLS connection is a 'normal' TLS connection
appropriate for HTTPS REST interfaces. The registrar initiates the appropriate for HTTPS REST interfaces. The registrar initiates the
connection and uses the MASA URL obtained as described in connection and uses the MASA URL obtained as described in
Section 2.8. The mechanisms in [RFC6125] SHOULD be used Section 2.8. The mechanisms in [RFC6125] SHOULD be used
authentication of the MASA. Some vendors will establish explicit (or authentication of the MASA using a DNS-ID that matches that which is
private) trust anchors for validating their MASA; this will typically found in the IDevID. Registrars MAY include a mechanism to override
done as part of a sales channel integration. the MASA URL on a manufacturer-by-manufacturer basis, and within that
override it is appropriate to provide alternate anchors. This will
typically used by some vendors to establish explicit (or private)
trust anchors for validating their MASA that is part of a sales
channel integration.
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED. REQUIRED. TLS 1.3 (or newer) SHOULD be available.
As described in [RFC7030], the MASA and the registrars SHOULD be As described in [RFC7030], the MASA and the registrars SHOULD be
prepared to support TLS client certificate authentication and/or HTTP prepared to support TLS client certificate authentication and/or HTTP
Basic or Digest authentication. This connection MAY also have no Basic or Digest authentication. This connection MAY also have no
client authentication at all. client authentication at all.
Registrars SHOULD permit trust anchors to be pre-configured on a per- Registrars SHOULD permit trust anchors to be pre-configured on a per-
vendor(MASA) basis. Registrars SHOULD include the ability to vendor(MASA) basis. Registrars SHOULD include the ability to
configure a TLS ClientCertificate on a per-MASA basis, or to use no configure a TLS ClientCertificate on a per-MASA basis, or to use no
client certificate. Registrars SHOULD also permit an HTTP Basic and client certificate. Registrars SHOULD also permit HTTP Basic and
Digest authentication to be configured. Digest authentication to be configured.
The authentication of the BRSKI-MASA connection does not change the The authentication of the BRSKI-MASA connection does not change the
voucher-request process, as voucher-requests are already signed by voucher-request process, as voucher-requests are already signed by
the registrar. Instead, this authentication provides access control the registrar. Instead, this authentication provides access control
to the audit-log as described in Section 5.8. to the audit-log as described in Section 5.8.
Implementors are advised that contacting the MASA is to establish a Implementors are advised that contacting the MASA is to establish a
secured REST connection with a web service and that there are a secured API connection with a web service and that there are a number
number of authentication models being explored within the industry. of authentication models being explored within the industry.
Registrars are RECOMMENDED to fail gracefully and generate useful Registrars are RECOMMENDED to fail gracefully and generate useful
administrative notifications or logs in the advent of unexpected HTTP administrative notifications or logs in the advent of unexpected HTTP
401 (Unauthorized) responses from the MASA. 401 (Unauthorized) responses from the MASA.
5.4.1. MASA authentication of customer Registrar 5.4.1. MASA authentication of customer Registrar
Providing per-customer options requires that the customer's registrar Providing per-customer options requires that the customer's registrar
be uniquely identified. This can be done by any stateless method be uniquely identified. This can be done by any stateless method
that HTTPS supports: such as with HTTP Basic or Digest authentication that HTTPS supports such as with HTTP Basic or Digest authentication
(that is using a password), but the use of TLS Client Certificate (that is using a password), but the use of TLS Client Certificate
authentication is RECOMMENDED. authentication is RECOMMENDED.
Stateful methods involving API tokens, or HTTP Cookies are not Stateful methods involving API tokens, or HTTP Cookies, are not
recommended. recommended.
It is expected that the setup and configuration of per-customer It is expected that the setup and configuration of per-customer
Client Certificates is done as part of a sales ordering process. Client Certificates is done as part of a sales ordering process.
The use of public PKI (i.e. WebPKI) End-Entity Certificates to The use of public PKI (i.e. WebPKI) End-Entity Certificates to
identify the Registrar is reasonable, and if done universally this identify the Registrar is reasonable, and if done universally this
would permit a MASA to identify a customers' Registrar simply by a would permit a MASA to identify a customers' Registrar simply by a
FQDN. FQDN.
skipping to change at page 43, line 27 skipping to change at page 44, line 27
of a FQDN to identify customer Registrars. of a FQDN to identify customer Registrars.
A third (and simplest, but least flexible) mechanism would be for the A third (and simplest, but least flexible) mechanism would be for the
MASA to simply store the Registrar's certificate pinned in a MASA to simply store the Registrar's certificate pinned in a
database. database.
A MASA without any supply chain integration can simply accept A MASA without any supply chain integration can simply accept
Registrars without any authentication, or can accept them on a blind Registrars without any authentication, or can accept them on a blind
Trust-on-First-Use basis as described in Section 7.4.2. Trust-on-First-Use basis as described in Section 7.4.2.
This document does not make a specific recommendation as there is This document does not make a specific recommendation on how the MASA
likely different tradeoffs in different environments and product authenticates the Registrar as there are likely different tradeoffs
values. Even within the ANIMA ACP applicability, there is a in different environments and product values. Even within the ANIMA
significant difference between supply chain logistics for $100 CPE ACP applicability, there is a significant difference between supply
devices and $100,000 core routers. chain logistics for $100 CPE devices and $100,000 core routers.
5.5. Registrar Requests Voucher from MASA 5.5. Registrar Requests Voucher from MASA
When a registrar receives a pledge voucher-request it in turn submits When a registrar receives a pledge voucher-request it in turn submits
a registrar voucher-request to the MASA service via an HTTPS a registrar voucher-request to the MASA service via an HTTPS
interface ([RFC7231]). interface ([RFC7231]).
This is done with an HTTP POST using the operation path value of This is done with an HTTP POST using the operation path value of
"/.well-known/est/requestvoucher". "/.well-known/est/requestvoucher".
skipping to change at page 44, line 32 skipping to change at page 45, line 32
like a voucher for. The registrar determines this value by like a voucher for. The registrar determines this value by
parsing the authenticated pledge IDevID certificate. See parsing the authenticated pledge IDevID certificate. See
Section 2.3. The registrar MUST verify that the serial number Section 2.3. The registrar MUST verify that the serial number
field it parsed matches the serial number field the pledge field it parsed matches the serial number field the pledge
provided in its voucher-request. This provides a sanity check provided in its voucher-request. This provides a sanity check
useful for detecting error conditions and logging. The registrar useful for detecting error conditions and logging. The registrar
MUST NOT simply copy the serial number field from a pledge voucher MUST NOT simply copy the serial number field from a pledge voucher
request as that field is claimed but not certified. request as that field is claimed but not certified.
idevid-issuer: The Issuer value from the pledge IDevID certificate idevid-issuer: The Issuer value from the pledge IDevID certificate
is included to ensure a uniqueness of the serial-number. In the is included to ensure unique interpretation of the serial-number.
case of nonceless (offline) voucher-request, then an appropriate In the case of nonceless (offline) voucher-request, then an
value needs to be configured from the same out-of-band source as appropriate value needs to be configured from the same out-of-band
the serial-number. source as the serial-number.
prior-signed-voucher-request: The signed pledge voucher-request prior-signed-voucher-request: The signed pledge voucher-request
SHOULD be included in the registrar voucher-request. The entire SHOULD be included in the registrar voucher-request. The entire
CMS signed structure is to be included, base64 encoded for CMS signed structure is to be included, base64 encoded for
transport in the JSON structure. transport in the JSON structure.
A nonceless registrar voucher-request MAY be submitted to the MASA. A nonceless registrar voucher-request MAY be submitted to the MASA.
Doing so allows the registrar to request a voucher when the pledge is Doing so allows the registrar to request a voucher when the pledge is
offline, or when the registrar anticipates not being able to connect offline, or when the registrar anticipates not being able to connect
to the MASA while the pledge is being deployed. Some use cases to the MASA while the pledge is being deployed. Some use cases
skipping to change at page 45, line 13 skipping to change at page 46, line 13
All other fields MAY be omitted in the registrar voucher-request. All other fields MAY be omitted in the registrar voucher-request.
The "proximity-registrar-cert" field MUST NOT be present in the The "proximity-registrar-cert" field MUST NOT be present in the
registrar voucher-request. registrar voucher-request.
Example JSON payloads of registrar voucher-requests are in Example JSON payloads of registrar voucher-requests are in
Section 3.3 Examples 2 through 4. Section 3.3 Examples 2 through 4.
The MASA verifies that the registrar voucher-request is internally The MASA verifies that the registrar voucher-request is internally
consistent but does not necessarily authenticate the registrar consistent but does not necessarily authenticate the registrar
certificate since the registrar MAY not be known to the MASA in certificate since the registrar MAY be unknown to the MASA in
advance. The MASA performs the actions and validation checks advance. The MASA performs the actions and validation checks
described in the following sub-sections before issuing a voucher. described in the following sub-sections before issuing a voucher.
5.5.1. MASA renewal of expired vouchers 5.5.1. MASA renewal of expired vouchers
As described in [RFC8366] vouchers are normally short lived to avoid As described in [RFC8366] vouchers are normally short lived to avoid
revocation issues. If the request is for a previous (expired) revocation issues. If the request is for a previous (expired)
voucher using the same registrar (that is, a Registrar with the same voucher using the same registrar (that is, a Registrar with the same
Domain CA) then the request for a renewed voucher SHOULD be Domain CA) then the request for a renewed voucher SHOULD be
automatically authorized. The MASA has sufficient information to automatically authorized. The MASA has sufficient information to
skipping to change at page 47, line 10 skipping to change at page 48, line 10
In the nonced case, validation of the Registrar's identity (via TLS In the nonced case, validation of the Registrar's identity (via TLS
Client Certificate or HTTP authentication) MAY be omitted if the Client Certificate or HTTP authentication) MAY be omitted if the
device policy is to accept audit-only vouchers. device policy is to accept audit-only vouchers.
5.5.5. MASA verification of pledge prior-signed-voucher-request 5.5.5. MASA verification of pledge prior-signed-voucher-request
The MASA MAY verify that the registrar voucher-request includes the The MASA MAY verify that the registrar voucher-request includes the
'prior-signed-voucher-request' field. If so the prior-signed- 'prior-signed-voucher-request' field. If so the prior-signed-
voucher-request MUST include a 'proximity-registrar-cert' that is voucher-request MUST include a 'proximity-registrar-cert' that is
consistent with to the certificate used to sign the registrar consistent with the certificate used to sign the registrar voucher-
voucher-request. Additionally the voucher-request serial-number leaf request. Additionally the voucher-request serial-number leaf MUST
MUST match the pledge serial-number that the MASA extracts from the match the pledge serial-number that the MASA extracts from the
signing certificate of the prior-signed-voucher-request. The signing certificate of the prior-signed-voucher-request. The
consistency check described above is checking that the 'proximity- consistency check described above is checking that the 'proximity-
registrar-cert' SPKI fingerprint exists within the registrar voucher- registrar-cert' SPKI fingerprint exists within the registrar voucher-
request CMS signature's certificate chain. This is substantially the request CMS signature's certificate chain. This is substantially the
same as the pin validation described in in [RFC7469] section 2.6, same as the pin validation described in in [RFC7469] section 2.6,
paragraph three. paragraph three.
If these checks succeed the MASA updates the voucher and audit-log If these checks succeed the MASA updates the voucher and audit-log
assertion leafs with the "proximity" assertion. assertion leafs with the "proximity" assertion, as defined by
[RFC8366] section 5.3.
5.5.6. MASA nonce handling 5.5.6. MASA nonce handling
The MASA does not verify the nonce itself. If the registrar voucher- The MASA does not verify the nonce itself. If the registrar voucher-
request contains a nonce, and the prior-signed-voucher-request request contains a nonce, and the prior-signed-voucher-request
exists, then the MASA MUST verify that the nonce is consistent. exists, then the MASA MUST verify that the nonce is consistent.
(Recall from above that the voucher-request might not contain a (Recall from above that the voucher-request might not contain a
nonce, see Section 5.5 and Section 5.5.4). nonce, see Section 5.5 and Section 5.5.4).
The MASA populates the audit-log with the nonce that was verified. The MASA populates the audit-log with the nonce that was verified.
skipping to change at page 50, line 30 skipping to change at page 51, line 30
from that point onwards. The lifetime of the voucher has no from that point onwards. The lifetime of the voucher has no
impact on the lifespan of the ownership relationship. impact on the lifespan of the ownership relationship.
Whenever a voucher is issued the MASA MUST update the audit-log Whenever a voucher is issued the MASA MUST update the audit-log
sufficiently to generate the response as described in Section 5.8.1. sufficiently to generate the response as described in Section 5.8.1.
The internal state requirements to maintain the audit-log are out-of- The internal state requirements to maintain the audit-log are out-of-
scope. scope.
5.6.1. Pledge voucher verification 5.6.1. Pledge voucher verification
The pledge MUST verify the voucher signature using the manufacturer The pledge MUST verify the voucher signature using the manufacturer-
installed trust anchor(s) associated with the manufacturer's MASA installed trust anchor(s) associated with the manufacturer's MASA
(this is likely included in the pledge's firmware). Management of (this is likely included in the pledge's firmware). Management of
the manufacturer installed trust anchor(s) is out-of-scope of this the manufacturer-installed trust anchor(s) is out-of-scope of this
document; this protocol does not update these trust anchor(s). document; this protocol does not update these trust anchor(s).
The pledge MUST verify the serial-number field of the signed voucher The pledge MUST verify the serial-number field of the signed voucher
matches the pledge's own serial-number. matches the pledge's own serial-number.
The pledge MUST verify that the voucher nonce field is accurate and The pledge MUST verify the nonce information in the voucher. If
matches the nonce the pledge submitted to this registrar, or that the present, the nonce in the voucher must match the nonce the pledge
voucher is nonceless (see Section 7.2). submitted to the registrar; vouchers with no nonce can also be
accepted (according to local policy, see Section 7.2.
The pledge MUST be prepared to parse and fail gracefully from a The pledge MUST be prepared to parse and fail gracefully from a
voucher response that does not contain a 'pinned-domain-cert' field. voucher response that does not contain a 'pinned-domain-cert' field.
Such a thing indicates a failure to enroll in this domain, and the Such a thing indicates a failure to enroll in this domain, and the
pledge MUST attempt joining with other available Join Proxy. pledge MUST attempt joining with other available Join Proxy.
The pledge MUST be prepared to ignore additional fields that it does The pledge MUST be prepared to ignore additional fields that it does
not recognize. not recognize.
5.6.2. Pledge authentication of provisional TLS connection 5.6.2. Pledge authentication of provisional TLS connection
skipping to change at page 51, line 22 skipping to change at page 52, line 22
If a registrar's credentials cannot be verified using the pinned- If a registrar's credentials cannot be verified using the pinned-
domain-cert trust anchor from the voucher then the TLS connection is domain-cert trust anchor from the voucher then the TLS connection is
immediately discarded and the pledge abandons attempts to bootstrap immediately discarded and the pledge abandons attempts to bootstrap
with this discovered registrar. The pledge SHOULD send voucher with this discovered registrar. The pledge SHOULD send voucher
status telemetry (described below) before closing the TLS connection. status telemetry (described below) before closing the TLS connection.
The pledge MUST attempt to enroll using any other proxies it has The pledge MUST attempt to enroll using any other proxies it has
found. It SHOULD return to the same proxy again after unsuccessful found. It SHOULD return to the same proxy again after unsuccessful
attempts with other proxies. Attempts should be made repeated at attempts with other proxies. Attempts should be made repeated at
intervals according to the backoff timer described earlier. Attempts intervals according to the backoff timer described earlier. Attempts
SHOULD be repeated as failure may be the result of a temporary SHOULD be repeated as failure may be the result of a temporary
inconsistently (an inconsistently rolled registrar key, or some other inconsistency (an inconsistently rolled registrar key, or some other
mis-configuration). The inconsistently could also be the result an mis-configuration). The inconsistency could also be the result an
active MITM attack on the EST connection. active MITM attack on the EST connection.
The registrar MUST use a certificate that chains to the pinned- The registrar MUST use a certificate that chains to the pinned-
domain-cert as its TLS server certificate. domain-cert as its TLS server certificate.
The pledge's PKIX path validation of a registrar certificate's The pledge's PKIX path validation of a registrar certificate's
validity period information is as described in Section 2.6.1. Once validity period information is as described in Section 2.6.1. Once
the PKIX path validation is successful the TLS connection is no the PKIX path validation is successful the TLS connection is no
longer provisional. longer provisional.
skipping to change at page 52, line 16 skipping to change at page 53, line 16
The domain is expected to provide indications to the system The domain is expected to provide indications to the system
administrators concerning device lifecycle status. To facilitate administrators concerning device lifecycle status. To facilitate
this it needs telemetry information concerning the device's status. this it needs telemetry information concerning the device's status.
To indicate pledge status regarding the voucher, the pledge MUST post To indicate pledge status regarding the voucher, the pledge MUST post
a status message to the Registrar. a status message to the Registrar.
The posted data media type: application/json The posted data media type: application/json
The client HTTP POSTs the following to the server at the URI ".well- The client sends an HTTP POST to the server at the URI ".well-
known/est/voucher_status". known/est/voucher_status".
The format and semantics described below are for version 1. A The format and semantics described below are for version 1. A
version field is included to permit significant changes to this version field is included to permit significant changes to this
feedback in the future. A Registrar that receives a status message feedback in the future. A Registrar that receives a status message
with a version larger than it knows about SHOULD log the contents and with a version larger than it knows about SHOULD log the contents and
alert a human. alert a human.
The Status field indicates if the voucher was acceptable. Boolean The Status field indicates if the voucher was acceptable. Boolean
values are acceptable. values are acceptable, where "true" indicates the voucher was
accesptable.
If the voucher was not acceptable the Reason string indicates why. If the voucher was not acceptable the Reason string indicates why.
In the failure case this message may be sent to an unauthenticated, In the failure case this message may be sent to an unauthenticated,
potentially malicious registrar and therefore the Reason string potentially malicious registrar and therefore the Reason string
SHOULD NOT provide information beneficial to an attacker. The SHOULD NOT provide information beneficial to an attacker. The
operational benefit of this telemetry information is balanced against operational benefit of this telemetry information is balanced against
the operational costs of not recording that an voucher was ignored by the operational costs of not recording that an voucher was ignored by
a client the registrar expected to continue joining the domain. a client the registrar expected to continue joining the domain.
The reason-context attribute is an arbitrary JSON object (literal The reason-context attribute is an arbitrary JSON object (literal
value or hash of values) which provides additional information value or hash of values) which provides additional information
specific to this pledge. The contents of this field are not subject specific to this pledge. The contents of this field are not subject
to standardization. to standardization.
The version, and status fields MUST be present. The Reason field The version and status fields MUST be present. The Reason field
SHOULD be present whenever the status field is negative. The Reason- SHOULD be present whenever the status field is false. The Reason-
Context field is optional. Context field is optional.
The keys to this JSON hash are case-insensitive. Figure 15 shows an The keys to this JSON object are case-sensitive and MUST be
example JSON. lowercase. Figure 15 shows an example JSON.
{ {
"version":"1", "version":"1",
"status":false, "status":false,
"reason":"Informative human readable message", "reason":"Informative human readable message",
"reason-context": { "additional" : "JSON" } "reason-context": { "additional" : "JSON" }
} }
Figure 15: Example Status Telemetry Figure 15: Example Status Telemetry
skipping to change at page 55, line 27 skipping to change at page 56, line 27
"domainID": text, "domainID": text,
"nonce": text / null, "nonce": text / null,
"assertion": "verified" / "logged" / "proximity", "assertion": "verified" / "logged" / "proximity",
? "truncated": uint, ? "truncated": uint,
} }
Figure 16: CDDL for audit-log response Figure 16: CDDL for audit-log response
As an abstract example: As an abstract example:
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"<date and time as per RFC3339 section 5.6>", "date":"2019-05-15T17:25:55.644-04:00",
"domainID":"<domainID extracted from voucher-request>", "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=",
"nonce":"<nonce as supplied (or NULL)>", "nonce":"VOUFT-WwrEv0NuAQEHoV7Q",
"assertion":"<the value from the voucher assertion leaf>", "assertion":"proximity",
"truncated":"<the number of domainID entries truncated>" "truncated":"0"
}, },
{ {
"date":"<date and time as per RFC3339 section 5.6>", "date":"2017-05-15T17:25:55.644-04:00",
"domainID":"<anotherDomainID extracted from voucher-request>", "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=",
"nonce":"<nonce as supplied (or NULL)>", "nonce":"f4G6Vi1t8nKo/FieCVgpBg==",
"assertion":"<the value from the voucher assertion leaf>" "assertion":"proximity"
}
],
"truncation": {
"nonced duplicates": "<total number of entries truncated>",
"nonceless duplicates": "<total number of entries truncated>",
"arbitrary": "<number of domainID entries removed entirely>"
} }
} ],
"truncation": {
"nonced duplicates": "0",
"nonceless duplicates": "1",
"arbitrary": "2"
}
}
Figure 17: Example of audit-log response Figure 17: Example of audit-log response
The domainID is a binary value calculated SubjectKeyIdentifier The domainID is a binary SubjectKeyIdentifier value calculated
according to Section 5.8.2. It is encoded once in base64 in order to according to Section 5.8.2. It is encoded once in base64 in order to
be transported in this JSON container. be transported in this JSON container.
The date is in [RFC3339] format, which is consistent with typical The date is in [RFC3339] format, which is consistent with typical
JavaScript usage of JSON. JavaScript usage of JSON.
The truncation structure MAY be omitted if all values are zero. Any The truncation structure MAY be omitted if all values are zero. Any
counter missing from the truncation structure is the be assumed to be counter missing from the truncation structure is the be assumed to be
zero. zero.
skipping to change at page 57, line 15 skipping to change at page 58, line 15
SHOULD anticipate new kinds of responses, and SHOULD provide operator SHOULD anticipate new kinds of responses, and SHOULD provide operator
controls to indicate how to process unknown responses. controls to indicate how to process unknown responses.
5.8.2. Calculation of domainID 5.8.2. Calculation of domainID
The domainID is a binary value (a BIT STRING) that uniquely The domainID is a binary value (a BIT STRING) that uniquely
identifies a Registrar by the "pinned-domain-cert" identifies a Registrar by the "pinned-domain-cert"
If the "pinned-domain-cert" certificate includes the If the "pinned-domain-cert" certificate includes the
SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
used as the domainID. If not, then it is the SPKI Fingerprint as used as the domainID. If not, the SPKI Fingerprint as described in
described in [RFC7469] section 2.4 is to be used. This value needs [RFC7469] section 2.4 is to be used. This value needs to be
to be calculated by both MASA (to populate the audit-log), and by the calculated by both MASA (to populate the audit-log), and by the
Registrar (to recognize itself). Registrar (to recognize itself in the audit log).
[RFC5280] section 4.2.1.2 does not mandate that the [RFC5280] section 4.2.1.2 does not mandate that the
SubjectKeyIdentifier extension be present in non-CA certificates. It SubjectKeyIdentifier extension be present in non-CA certificates. It
is RECOMMENDED that Registrar certificates (even if self-signed), is RECOMMENDED that Registrar certificates (even if self-signed),
always include the SubjectKeyIdentifier to be used as a domainID. always include the SubjectKeyIdentifier to be used as a domainID.
The domainID is determined from the certificate chain associated with The domainID is determined from the certificate chain associated with
the pinned-domain-cert and is used to update the audit-log. the pinned-domain-cert and is used to update the audit-log.
5.8.3. Registrar audit log verification 5.8.3. Registrar audit log verification
skipping to change at page 58, line 39 skipping to change at page 59, line 39
the MASA issued the associated voucher as a result of positive the MASA issued the associated voucher as a result of positive
verification of ownership but this can still be problematic for verification of ownership but this can still be problematic for
registrar's that expected only new (not pre-owned) pledges. A registrar's that expected only new (not pre-owned) pledges. A
"logged" assertion informs the registrar that the prior vouchers "logged" assertion informs the registrar that the prior vouchers
were issued with minimal verification. A "proximity" assertion were issued with minimal verification. A "proximity" assertion
assures the registrar that the pledge was truly communicating with assures the registrar that the pledge was truly communicating with
the prior domain and thus provides assurance that the prior domain the prior domain and thus provides assurance that the prior domain
really has deployed the pledge. really has deployed the pledge.
A relatively simple policy is to white list known (internal or A relatively simple policy is to white list known (internal or
external) domainIDs. To require all vouchers to have a nonce. external) domainIDs, and require all vouchers to have a nonce. An
Alternatively to require that all nonceless vouchers be from a subset alternative is to require that all nonceless vouchers be from a
(e.g. only internal) of domainIDs. If the policy is violated a subset (e.g. only internal) of domainIDs. If the policy is violated
simple action is to revoke any locally issued credentials for the a simple action is to revoke any locally issued credentials for the
pledge in question or to refuse to forward the voucher. The pledge in question or to refuse to forward the voucher. The
Registrar MUST then refuse any EST actions, and SHOULD inform a human Registrar MUST then refuse any EST actions, and SHOULD inform a human
via a log. A registrar MAY be configured to ignore (i.e. override via a log. A registrar MAY be configured to ignore (i.e. override
the above policy) the history of the device but it is RECOMMENDED the above policy) the history of the device but it is RECOMMENDED
that this only be configured if hardware assisted (i.e. TPM that this only be configured if hardware assisted (i.e. TPM
anchored) Network Endpoint Assessment (NEA) [RFC5209] is supported. anchored) Network Endpoint Assessment (NEA) [RFC5209] is supported.
5.9. EST Integration for PKI bootstrapping 5.9. EST Integration for PKI bootstrapping
The pledge SHOULD follow the BRSKI operations with EST enrollment The pledge SHOULD follow the BRSKI operations with EST enrollment
operations including "CA Certificates Request", "CSR Attributes" and operations including "CA Certificates Request", "CSR Attributes" and
"Client Certificate Request" or "Server-Side Key Generation", etc. "Client Certificate Request" or "Server-Side Key Generation", etc.
This is a relatively seamless integration since BRSKI REST calls This is a relatively seamless integration since BRSKI API calls
provide an automated alternative to the manual bootstrapping method provide an automated alternative to the manual bootstrapping method
described in [RFC7030]. As noted above, use of HTTP 1.1 persistent described in [RFC7030]. As noted above, use of HTTP persistent
connections simplifies the pledge state machine. connections simplifies the pledge state machine.
Although EST allows clients to obtain multiple certificates by Although EST allows clients to obtain multiple certificates by
sending multiple CSR requests, BRSKI does not support this mechanism sending multiple Certificate Signing Requests (CSR) requests, BRSKI
directly. This is because BRSKI pledges MUST use the CSR Attributes does not support this mechanism directly. This is because BRSKI
request ([RFC7030] section 4.5). The registrar MUST validate the CSR pledges MUST use the CSR Attributes request ([RFC7030] section 4.5).
against the expected attributes. This implies that client requests The registrar MUST validate the CSR against the expected attributes.
will "look the same" and therefore result in a single logical This implies that client requests will "look the same" and therefore
certificate being issued even if the client were to make multiple result in a single logical certificate being issued even if the
requests. Registrars MAY contain more complex logic but doing so is client were to make multiple requests. Registrars MAY contain more
out-of-scope of this specification. BRSKI does not signal any complex logic but doing so is out-of-scope of this specification.
enhancement or restriction to this capability. BRSKI does not signal any enhancement or restriction to this
capability.
5.9.1. EST Distribution of CA Certificates 5.9.1. EST Distribution of CA Certificates
The pledge SHOULD request the full EST Distribution of CA The pledge SHOULD request the full EST Distribution of CA
Certificates message. See RFC7030, section 4.1. Certificates message. See RFC7030, section 4.1.
This ensures that the pledge has the complete set of current CA This ensures that the pledge has the complete set of current CA
certificates beyond the pinned-domain-cert (see Section 5.6.2 for a certificates beyond the pinned-domain-cert (see Section 5.6.2 for a
discussion of the limitations inherent in having a single certificate discussion of the limitations inherent in having a single certificate
instead of a full CA Certificates response.) Although these instead of a full CA Certificates response.) Although these
skipping to change at page 61, line 8 skipping to change at page 62, line 8
following to the server at the new EST endpoint at "/.well-known/est/ following to the server at the new EST endpoint at "/.well-known/est/
enrollstatus". enrollstatus".
To indicate successful enrollment the client SHOULD first re- To indicate successful enrollment the client SHOULD first re-
establish the EST TLS session using the newly obtained credentials. establish the EST TLS session using the newly obtained credentials.
TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The
client SHOULD therefore close the existing TLS connection, and start client SHOULD therefore close the existing TLS connection, and start
a new one. a new one.
In the case of a FAIL, the Reason string indicates why the most In the case of a FAIL, the Reason string indicates why the most
recent enrollment failed. The SubjectKeyIdentifier field MUST be recent enrollment failed.
included if the enrollment attempt was for a keypair that is locally
known to the client. If EST /serverkeygen was used and failed then
the field is omitted from the status telemetry.
In the case of a SUCCESS the Reason string is omitted. The The reason-context attribute is an arbitrary JSON object (literal
SubjectKeyIdentifier is included so that the server can record the value or hash of values) which provides additional information
successful certificate distribution. specific to the failure to unroll from this pledge. The contents of
this field are not subject to standardization.
In the case of a SUCCESS the Reason string is omitted.
An example status report can be seen below. It is sent with with the An example status report can be seen below. It is sent with with the
media type: application/json media type: application/json
{ {
"version":"1", "version":"1",
"Status":true, "Status":true,
"Reason":"Informative human readable message", "Reason":"Informative human readable message",
"reason-context": "Additional information" "reason-context": { "additional" : "JSON" }
} }
Figure 18: Example of enrollment status POST Figure 18: Example of enrollment status POST
The server SHOULD respond with an HTTP 200 but MAY simply fail with The server SHOULD respond with an HTTP 200 but MAY simply fail with
an HTTP 404 error. an HTTP 404 error.
Within the server logs the server MUST capture if this message was Within the server logs the server MUST capture if this message was
received over an TLS session with a matching client certificate. received over an TLS session with a matching client certificate.
skipping to change at page 62, line 13 skipping to change at page 63, line 13
mappings for BRSKI will be discussed either there or in future work. mappings for BRSKI will be discussed either there or in future work.
6. Clarification of transfer-encoding 6. Clarification of transfer-encoding
[RFC7030] defines its endpoints to include a "Content-Transfer- [RFC7030] defines its endpoints to include a "Content-Transfer-
Encoding" heading, and the payloads to be [RFC4648] Base64 encoded Encoding" heading, and the payloads to be [RFC4648] Base64 encoded
DER. DER.
When used within BRSKI, the original RFC7030 EST endpoints remain When used within BRSKI, the original RFC7030 EST endpoints remain
Base64 encoded, but the new BRSKI end points which send and receive Base64 encoded, but the new BRSKI end points which send and receive
binary artifacts (specifically, /requestvoucher) are binary. That binary artifacts (specifically, "/.well-known/est/requestvoucher")
is, no encoding is used. are binary. That is, no encoding is used.
In the BRSKI context, the EST "Content-Transfer-Encoding" header In the BRSKI context, the EST "Content-Transfer-Encoding" header
field if present, SHOULD be ignored. This header field does not need field if present, SHOULD be ignored. This header field does not need
to be included. to be included.
7. Reduced security operational modes 7. Reduced security operational modes
A common requirement of bootstrapping is to support less secure A common requirement of bootstrapping is to support less secure
operational modes for support specific use cases. The following operational modes for support specific use cases. This section
sections detail specific ways that the pledge, registrar and MASA can suggests a range of mechanisms that would alter the security
be configured to run in a less secure mode for the indicated reasons. assurance of BRSKI to accommodate alternative deployment
architectures and mitigate lifecycle management issues identified in
Section 10. They are presented here as informative (non-normative)
design guidance for future standardization activities. Section 9
provides standardization applicability statements for the ANIMA ACP.
Other users would be expected that subsets of these mechanisms could
be profiled with an accompanying applicability statements similar to
the one described in Section 9.
This section is considered non-normative in the generality of the This section is considered non-normative in the generality of the
protocol. Use of the suggested mechanism here MUST be detailed in protocol. Use of the suggested mechanisms here MUST be detailed in
specific profiles of BRSKI, such as in Section 9. specific profiles of BRSKI, such as in Section 9.
7.1. Trust Model 7.1. Trust Model
This section explains the trust relationships detailed in This section explains the trust relationships detailed in
Section 2.4: Section 2.4:
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| Pledge | | Join | | Domain | |Manufacturer| | Pledge | | Join | | Domain | |Manufacturer|
| | | Proxy | | Registrar | | Service | | | | Proxy | | Registrar | | Service |
skipping to change at page 63, line 22 skipping to change at page 64, line 28
devices are associated with which domains. These claims could be devices are associated with which domains. These claims could be
strengthened by using cryptographic log techniques to provide strengthened by using cryptographic log techniques to provide
append only, cryptographic assured, publicly auditable logs. append only, cryptographic assured, publicly auditable logs.
Vendor Service, Ownership Validation: This form of manufacturer Vendor Service, Ownership Validation: This form of manufacturer
service is trusted to accurately know which device is owned by service is trusted to accurately know which device is owned by
which domain. which domain.
7.2. Pledge security reductions 7.2. Pledge security reductions
The following are a list of alternatives behaviours that the pledge The following is a list of alternative behaviours that the pledge can
can be programmed to implement. These behaviours are not mutually be programmed to implement. These behaviours are not mutually
exclusive, nor are they dependant upon other. Some of these methods exclusive, nor are they dependent upon each other. Some of these
enable offline and emergency (touch based) deployment use cases. methods enable offline and emergency (touch based) deployment use
Normative language is used as these behaviours are referenced in cases. Normative language is used as these behaviours are referenced
later sections in a normative fashion. in later sections in a normative fashion.
1. The pledge MUST accept nonceless vouchers. This allows for a use 1. The pledge MUST accept nonceless vouchers. This allows for a use
case where the registrar can not connect to the MASA at the case where the registrar can not connect to the MASA at the
deployment time. Logging and validity periods address the deployment time. Logging and validity periods address the
security considerations of supporting these use cases. security considerations of supporting these use cases.
2. Many devices already support "trust on first use" for physical 2. Many devices already support "trust on first use" for physical
interfaces such as console ports. This document does not change interfaces such as console ports. This document does not change
that reality. Devices supporting this protocol MUST NOT support that reality. Devices supporting this protocol MUST NOT support
"trust on first use" on network interfaces. This is because "trust on first use" on network interfaces. This is because
skipping to change at page 64, line 19 skipping to change at page 65, line 26
voucher validation (including use of craft serial console) only be voucher validation (including use of craft serial console) only be
available if hardware assisted Network Endpoint Assessment (NEA: available if hardware assisted Network Endpoint Assessment (NEA:
[RFC5209]) is supported. This recommendation ensures that domain [RFC5209]) is supported. This recommendation ensures that domain
network monitoring can detect inappropriate use of offline or network monitoring can detect inappropriate use of offline or
emergency deployment procedures when voucher-based bootstrapping is emergency deployment procedures when voucher-based bootstrapping is
not used. not used.
7.3. Registrar security reductions 7.3. Registrar security reductions
A registrar can choose to accept devices using less secure methods. A registrar can choose to accept devices using less secure methods.
These methods are acceptable when low security models are needed, as They MUST NOT be the default behavior. These methods may be
the security decisions are being made by the local administrator, but acceptable in situations where threat models indicate that low
they MUST NOT be the default behavior: security is adequate. This includes situations where security
decisions are being made by the local administrator:
1. A registrar MAY choose to accept all devices, or all devices of a 1. A registrar MAY choose to accept all devices, or all devices of a
particular type, at the administrator's discretion. This could particular type, at the administrator's discretion. This could
occur when informing all registrars of unique identifiers of new occur when informing all registrars of unique identifiers of new
entities might be operationally difficult. entities might be operationally difficult.
2. A registrar MAY choose to accept devices that claim a unique 2. A registrar MAY choose to accept devices that claim a unique
identity without the benefit of authenticating that claimed identity without the benefit of authenticating that claimed
identity. This could occur when the pledge does not include an identity. This could occur when the pledge does not include an
X.509 IDevID factory installed credential. New Entities without X.509 IDevID factory installed credential. New Entities without
skipping to change at page 65, line 7 skipping to change at page 66, line 15
3. A registrar MAY submit a nonceless voucher-requests to the MASA 3. A registrar MAY submit a nonceless voucher-requests to the MASA
service (by not including a nonce in the voucher-request.) The service (by not including a nonce in the voucher-request.) The
resulting vouchers can then be stored by the registrar until they resulting vouchers can then be stored by the registrar until they
are needed during bootstrapping operations. This is for use are needed during bootstrapping operations. This is for use
cases where the target network is protected by an air gap and cases where the target network is protected by an air gap and
therefore cannot contact the MASA service during pledge therefore cannot contact the MASA service during pledge
deployment. deployment.
4. A registrar MAY ignore unrecognized nonceless log entries. This 4. A registrar MAY ignore unrecognized nonceless log entries. This
could occur when used equipment is purchased with a valid history could occur when used equipment is purchased with a valid history
being deployed in air gap networks that required permanent being deployed in air gap networks that required offline
vouchers. vouchers.
5. A registrar MAY accept voucher formats of future types that can 5. A registrar MAY accept voucher formats of future types that can
not be parsed by the Registrar. This reduces the Registrar's not be parsed by the Registrar. This reduces the Registrar's
visibility into the exact voucher contents but does not change visibility into the exact voucher contents but does not change
the protocol operations. the protocol operations.
7.4. MASA security reductions 7.4. MASA security reductions
Lower security modes chosen by the MASA service affect all device Lower security modes chosen by the MASA service affect all device
deployments unless the lower-security behavior is tied to specific deployments unless the lower-security behavior is tied to specific
device identities. The modes described below can be applied to device identities. The modes described below can be applied to
specific devices via knowledge of what devices were sold. They can specific devices via knowledge of what devices were sold. They can
also be bound to specific customers (independent of the device also be bound to specific customers (independent of the device
identity) by authenticating the customer's Registrar. identity) by authenticating the customer's Registrar.
7.4.1. Issuing Nonceless vouchers 7.4.1. Issuing Nonceless vouchers
A MASA has the option of not including a nonce is in the voucher, A MASA has the option of not including a nonce in the voucher, and/or
and/or not requiring one to be present in the voucher-request. This not requiring one to be present in the voucher-request. This results
results in distribution of a voucher that never expires and in effect in distribution of a voucher that may never expire and in effect
makes the Domain an always trusted entity to the pledge during any makes the specified Domain an always trusted entity to the pledge
subsequent bootstrapping attempts. That a nonceless voucher was during any subsequent bootstrapping attempts. That a nonceless
issued is captured in the log information so that the registrar can voucher was issued is captured in the log information so that the
make appropriate security decisions when a pledge joins the Domain. registrar can make appropriate security decisions when a pledge joins
This is useful to support use cases where registrars might not be the Domain. Nonceless vouchers are useful to support use cases where
online during actual device deployment. registrars might not be online during actual device deployment.
While a nonceless voucher may include an expiry date, a typical use While a nonceless voucher may include an expiry date, a typical use
for a nonceless voucher is for it to be long-lived. If the device for a nonceless voucher is for it to be long-lived. If the device
can be trusted to have an accurate clock (the MASA will know), then a can be trusted to have an accurate clock (the MASA will know), then a
nonceless voucher CAN be issued with a limited lifetime. nonceless voucher CAN be issued with a limited lifetime.
A more typical case for a nonceless voucher is for use with offline A more typical case for a nonceless voucher is for use with offline
onboarding scenarios where it is not possible to pass a fresh onboarding scenarios where it is not possible to pass a fresh
voucher-request to the MASA. The use of a long-lived voucher also voucher-request to the MASA. The use of a long-lived voucher also
eliminates concern about the availability of the MASA many years in eliminates concern about the availability of the MASA many years in
the future. Thus many nonceless vouchers will have no expiry dates. the future. Thus many nonceless vouchers will have no expiry dates.
Thus, the long lived nonceless voucher does not require the proof Thus, the long lived nonceless voucher does not require the proof
that the device is online. Issuing such a thing is only accepted that the device is online. Issuing such a thing is only accepted
when the registrar is authenticated by the MASA and the MASA is when the registrar is authenticated by the MASA and the MASA is
authorized to provide this functionality to this customer. The MASA authorized to provide this functionality to this customer. The MASA
is RECOMMENDED to use this functionality only in concert with an is RECOMMENDED to use this functionality only in concert with an
enhanced level of ownership tracking (out-of-scope.) enhanced level of ownership tracking, the details of which are out of
scope for this document.
If the pledge device is known to have a real-time-clock that is set If the pledge device is known to have a real-time-clock that is set
from the factory, use of a voucher validity period is RECOMMENDED. from the factory, use of a voucher validity period is RECOMMENDED.
7.4.2. Trusting Owners on First Use 7.4.2. Trusting Owners on First Use
A MASA has the option of not verifying ownership before responding A MASA has the option of not verifying ownership before responding
with a voucher. This is expected to be a common operational model with a voucher. This is expected to be a common operational model
because doing so relieves the manufacturer providing MASA services because doing so relieves the manufacturer providing MASA services
from having to track ownership during shipping and supply chain and from having to track ownership during shipping and supply chain and
allows for a very low overhead MASA service. A registrar uses the allows for a very low overhead MASA service. A registrar uses the
audit log information as a defense in depth strategy to ensure that audit log information as a defense in depth strategy to ensure that
this does not occur unexpectedly (for example when purchasing new this does not occur unexpectedly (for example when purchasing new
equipment the registrar would throw an error if any audit log equipment the registrar would throw an error if any audit log
information is reported.) The MASA SHOULD verify the 'prior-signed- information is reported.) The MASA SHOULD verify the 'prior-signed-
voucher-request' information for pledges that support that voucher-request' information for pledges that support that
functionality. This provides a proof-of-proximity check that reduces functionality. This provides a proof-of-proximity check that reduces
the need for ownership verification. the need for ownership verification. The proof-of-proximity comes
from the assumption that the pledge and Join Proxy are on the same
link-local connection.
A MASA that practices Trust-on-First-Use (TOFU) for Registrar A MASA that practices Trust-on-First-Use (TOFU) for Registrar
identity may wish to annotate the origin of the connection by IP identity may wish to annotate the origin of the connection by IP
address or netblock, and restrict future use of that identity from address or netblock, and restrict future use of that identity from
other locations. A MASA that does this SHOULD take care to not other locations. A MASA that does this SHOULD take care to not
create nuissance situations for itself when a customer has multiple create nuisance situations for itself when a customer has multiple
registrars, or uses outgoing IPv4 NAT44 connections that change registrars, or uses outgoing IPv4 NAT44 connections that change
frequently. frequently.
7.4.3. Updating or extending voucher trust anchors 7.4.3. Updating or extending voucher trust anchors
This section deals with the problem of a MASA that is no longer
available due to a failed business, or the situation where a MASA is
uncooperative to a secondary sale.
A manufacturer could offer a management mechanism that allows the A manufacturer could offer a management mechanism that allows the
list of voucher verification trust anchors to be extended. list of voucher verification trust anchors to be extended.
[I-D.ietf-netconf-keystore] is one such interface that could be [I-D.ietf-netconf-keystore] is one such interface that could be
implemented using YANG. Pretty much any configuration mechanism used implemented using YANG. Pretty much any configuration mechanism used
today could be extended to provide the needed additional update. A today could be extended to provide the needed additional update. A
manufacturer could even decide to install the domain CA trust anchors manufacturer could even decide to install the domain CA trust anchors
received during the EST "cacerts" step as voucher verification received during the EST "cacerts" step as voucher verification
anchors. Some additional signals will be needed to clearly identify anchors. Some additional signals will be needed to clearly identify
which keys have voucher validation authority from among those signed which keys have voucher validation authority from among those signed
by the domain CA. This is future work. by the domain CA. This is future work.
skipping to change at page 67, line 22 skipping to change at page 68, line 39
be needed to initiate it. This is most suitable for redeploying a be needed to initiate it. This is most suitable for redeploying a
device within the same Enterprise. This would entail having previous device within the same Enterprise. This would entail having previous
configuration in the system until entirely replaced by the new owner, configuration in the system until entirely replaced by the new owner,
and represents some level of risk. and represents some level of risk.
The second mechanism is that there would need to be two levels of The second mechanism is that there would need to be two levels of
factory reset. One would take the system back entirely to factory reset. One would take the system back entirely to
manufacturer state, including removing any added trust anchors, and manufacturer state, including removing any added trust anchors, and
the second (more commonly used) one would just restore the the second (more commonly used) one would just restore the
configuration back to a known default without erasing trust anchors. configuration back to a known default without erasing trust anchors.
This weaker factor reset might leave valuable credentials on the This weaker factory reset might leave valuable credentials on the
device and this may be unacceptable to some owners. device and this may be unacceptable to some owners.
As a third option, the manufacturer's trust anchors could be entirely As a third option, the manufacturer's trust anchors could be entirely
overwitten with local trust anchors. A factory default would never overwritten with local trust anchors. A factory default would never
restore those anchors. This option comes with a lot of power, but restore those anchors. This option comes with a lot of power, but
also a lot of responsability: if the new anchors are lost the also a lot of responsibility: if access to the private part of the
manufacturer may be unable to help. new anchors are lost the manufacturer may be unable to help.
8. IANA Considerations 8. IANA Considerations
This document requires the following IANA actions: This document requires the following IANA actions:
8.1. The IETF XML Registry 8.1. The IETF XML Registry
This document registers a URI in the "IETF XML Registry" [RFC3688]. This document registers a URI in the "IETF XML Registry" [RFC3688].
IANA has registered the following: IANA has registered the following:
skipping to change at page 69, line 31 skipping to change at page 70, line 51
The protocol described in this document has appeal in a number of The protocol described in this document has appeal in a number of
other non-ANIMA use cases. Such uses of the protocol will be other non-ANIMA use cases. Such uses of the protocol will be
deploying into other environments with different tradeoffs of deploying into other environments with different tradeoffs of
privacy, security, reliability and autonomy from manufacturers. As privacy, security, reliability and autonomy from manufacturers. As
such those use cases will need to provide their own applicability such those use cases will need to provide their own applicability
statements, and will need to address unique privacy and security statements, and will need to address unique privacy and security
considerations for the environments in which they are used. considerations for the environments in which they are used.
The autonomic control plane (ACP) that is bootstrapped by the BRSKI The autonomic control plane (ACP) that is bootstrapped by the BRSKI
protocol is typically used in medium to large Internet Service protocol is typically used in medium to large Internet Service
Provider organizations. Equivalent enterprises that has significant Provider organizations. Equivalent enterprises that have significant
layer-3 router connectivity also will find significant benefit, layer-3 router connectivity also will find significant benefit,
particularly if the Enterprise has many sites. (A network consisting particularly if the Enterprise has many sites. (A network consisting
of primarily layer-2 is not excluded, but the adjacencies that the of primarily layer-2 is not excluded, but the adjacencies that the
ACP will create and maintain will not reflect the topology until all ACP will create and maintain will not reflect the topology until all
devices participate in the ACP). devices participate in the ACP).
In the ACP, the Join Proxy is found to be proximal because In the ACP, the Join Proxy is found to be proximal because
communication between the pledge and the join proxy is exclusively on communication between the pledge and the join proxy is exclusively on
IPv6 Link-Local addresses. The proximity of the Join Proxy to the IPv6 Link-Local addresses. The proximity of the Join Proxy to the
Registrar is validated by the Registrar using ANI ACP IPv6 Unique Registrar is validated by the Registrar using ANI ACP IPv6 Unique
Local Addresses (ULA). ULAs are not routable over the Internet, so Local Addresses (ULA). ULAs are not routable over the Internet, so
as long as the Join Proxy is operating correctly the proximity as long as the Join Proxy is operating correctly the proximity
asssertion is satisfied. Other uses of BRSKI will need make similar asssertion is satisfied. Other uses of BRSKI will need make similar
analysis if they use proximity. analysis if they use proximity assertions.
As specified in the ANIMA charter, this work "..focuses on As specified in the ANIMA charter, this work "..focuses on
professionally-managed networks." Such a network has an operator and professionally-managed networks." Such a network has an operator and
can do things like install, configure and operate the Registrar can do things like install, configure and operate the Registrar
function. The operator makes purchasing decisions and is aware of function. The operator makes purchasing decisions and is aware of
what manufacturers it expects to see on its network. what manufacturers it expects to see on its network.
Such an operator is also capable of performing bootstrapping of a Such an operator is also capable of performing bootstrapping of a
device using a serial-console (craft console). The zero-touch device using a serial-console (craft console). The zero-touch
mechanism presented in this and the ACP document mechanism presented in this and the ACP document
skipping to change at page 70, line 25 skipping to change at page 71, line 44
Section 7.2. The manufacturer MUST provide at least one of the one- Section 7.2. The manufacturer MUST provide at least one of the one-
touch mechanisms described that permit enrollment to be proceed touch mechanisms described that permit enrollment to be proceed
without availability of any manufacturer server (such as the MASA). without availability of any manufacturer server (such as the MASA).
The BRSKI protocol is going into environments where there have The BRSKI protocol is going into environments where there have
already been quite a number of vendor proprietary management systems. already been quite a number of vendor proprietary management systems.
Those are not expected to go away quickly, but rather to leverage the Those are not expected to go away quickly, but rather to leverage the
secure credentials that are provisioned by BRSKI. The connectivity secure credentials that are provisioned by BRSKI. The connectivity
requirements of said management systems are provided by the ACP. requirements of said management systems are provided by the ACP.
9.1. Operational Requirements
This section collects operational requirements based upon the three
roles involved in BRSKI: The Manufacturer Authorized Signing
Authority (MASA), the (Domain) Owner and the Device. It should be
recognized that the manufacturer may be involved in two roles, as it
creates the software/firmware for the device, and also may be the
operator of the MASA.
The requirements in this section are presented using BCP14
([RFC2119], [RFC8174]) language. These do not represent new
normative statements, just a review of a few such things in one place
by role. They also apply specifically to the ANIMA ACP use case.
Other use cases likely have similar, but MAY different requirements.
9.1.1. MASA Operational Requirements
The manufacturer MUST arrange for an online service to be available
called the MASA. It MUST be available at the URL which is encoded in
the IDevID certificate extensions described in Section 2.3.2.
The online service MUST have access to a private key with which to
sign [RFC8366] format voucher artifacts. The public key,
certificate, or certificate chain MUST be built in to the device as
part of the firmware.
It is RECOMMENDED that the manufacturer arrange for this signing key
(or keys) to be escrowed according to typical software source code
escrow practices [softwareescrow].
The MASA accepts voucher requests from Domain Owners according to an
operational practice appropriate for the device. This can range from
any domain owner (first-come first-served, on a TOFU-like basis), to
full sales channel integration where Domain Owners need to be
positively identified by TLS Client Certicate pinned, or HTTP
Authentication process. The MASA creates signed voucher artifacts
according to a it's internally defined policies.
The MASA MUST operate an audit log for devices that is accessible.
The audit log is designed to be easily cacheable and the MASA MAY
find it useful to put this content on a CDN.
9.1.2. Domain Owner Operational Requirements
The domain owner MUST operate an EST ([RFC7030]) server with the
extensions described in this document. This is the JRC or Registrar.
This JRC/EST server MUST announce itself using GRASP within the ACP.
This EST server will typically reside with the Network Operations
Center for the organization.
The domain owner MAY operate an internal certificate authority (CA)
that is seperate from the EST server, or it MAY combine all
activities into a single device. The determination of the
architecture depends upon the scale and resiliency requirements of
the organization. Multiple JRC instances MAY be announced into the
ACP from multiple locations to achieve an appropriate level of
redundancy.
In order to recognize which devices and which manufacturers are
welcome on the domain owner's network, the domain owner SHOULD
maintain a white list of manufacturers. This MAY extend to
integration with purchasing departments to know the serial numbers of
devices.
The domain owner SHOULD use the resulting overlay ACP network to
manage devices, replacing legacy out-of-band mechanisms.
The domain owner SHOULD operate one or more EST servers which can be
used to renew the domain certificates (LDevIDs) which are deployed to
devices. These servers MAY be the same as the JRC, or MAY be a
distinct set of devices, as approriate for resiliency.
The organization MUST take appropriate precautions against loss of
access to the certificate authority private key. Hardware security
modules and/or secret splitting are appropriate.
9.1.3. Device Operational Requirements
Devices MUST come with built-in trust anchors that permit the device
to validate vouchers from the MASA.
Device MUST come with (unique, per-device) IDevID certificates that
include their serial numbers, and the MASA URL extension.
Devices are expected to find Join Proxies using GRASP, and then
connect to the JRC using the protocol described in this document.
Once a domain owner has been validated with the voucher, devices are
expected to enroll into the domain using EST. Devices are then
expected to form ACPs using IPsec over IPv6 Link-Local addresses as
described in [I-D.ietf-anima-autonomic-control-plane]
Once a device has been enrolled it SHOULD listen for the address of
the JRC using GRASP, and it SHOULD enable itself as a Join Proxy, and
announce itself on all links/interfaces using GRASP DULL.
Devices are expected to renew their certificates before they expire.
10. Privacy Considerations 10. Privacy Considerations
10.1. MASA audit log 10.1. MASA audit log
The MASA audit log includes the domainID for each domain a voucher The MASA audit log includes the domainID for each domain a voucher
has been issued to. This information is closely related to the has been issued to. This information is closely related to the
actual domain identity. A MASA may need additional defenses against actual domain identity. A MASA may need additional defenses against
Denial of Service attacks (Section 11.1), and this may involve Denial of Service attacks (Section 11.1), and this may involve
collecting additional (unspecified here) information. This could collecting additional (unspecified here) information. This could
provide sufficient information for the MASA service to build a provide sufficient information for the MASA service to build a
skipping to change at page 71, line 19 skipping to change at page 74, line 36
other. For the Pledge, this includes the serialNumber attribute, the other. For the Pledge, this includes the serialNumber attribute, the
MASA URL, and the identity that signed the IDevID certificate. MASA URL, and the identity that signed the IDevID certificate.
TLS 1.2 reveals the certificate identities to on-path observers, TLS 1.2 reveals the certificate identities to on-path observers,
including the Join Proxy. including the Join Proxy.
TLS 1.3 reveals the certificate identities only to the end parties, TLS 1.3 reveals the certificate identities only to the end parties,
but as the connection is provisional, an on-path attacker (MTIM) can but as the connection is provisional, an on-path attacker (MTIM) can
see the certificates. This includes not just malicious attackers, see the certificates. This includes not just malicious attackers,
but also Registrars that are visible to the Pledge, but which are not but also Registrars that are visible to the Pledge, but which are not
part of the the intended domain. part of the intended domain.
The certificate of the Registrar is rather arbtirary from the point The certificate of the Registrar is rather arbitrary from the point
of view of the BRSKI protocol. As no [RFC6125] validations are of view of the BRSKI protocol. As no [RFC6125] validations are
expected to be done, the contents could be easily pseudonymized. Any expected to be done, the contents could be easily pseudonymized. Any
device that can see a join proxy would be able to connect to the device that can see a join proxy would be able to connect to the
Registrar and learn the identity of the network in question. Even if Registrar and learn the identity of the network in question. Even if
the contents of the certificate are pseudonymized, it would be the contents of the certificate are pseudonymized, it would be
possible to coorelate different connections in different locations possible to correlate different connections in different locations
belong to the same entity. This is unlikely to present a significant belong to the same entity. This is unlikely to present a significant
privacy concern to ANIMA ACP uses of BRSKI, but may be a concern to privacy concern to ANIMA ACP uses of BRSKI, but may be a concern to
other users of BRSKI. other users of BRSKI.
The certificate of the Pledge could be revealed by a malicious Join The certificate of the Pledge could be revealed by a malicious Join
Proxy that performed a MITM attack on the provisional TLS connection. Proxy that performed a MITM attack on the provisional TLS connection.
Such an attacker would be able to reveal the identity of the Pledge Such an attacker would be able to reveal the identity of the Pledge
to third parties if it chose to so. to third parties if it chose to so.
Research into a mechanism to do multi-step, multi-party authenticated Research into a mechanism to do multi-step, multi-party authenticated
key agreement, incorporating some kind of zero-knowledge proof would key agreement, incorporating some kind of zero-knowledge proof would
be valuable. Such a mechanism would ideally avoid disclosing be valuable. Such a mechanism would ideally avoid disclosing
identities until pledge, registrar and MASA agree to the transaction. identities until pledge, registrar and MASA agree to the transaction.
Such a mechanism would need to discover the location of the MASA Such a mechanism would need to discover the location of the MASA
without knowing the identity of the pledge, or the identity of the without knowing the identity of the pledge, or the identity of the
MASA. This part of the problem may be unsolveable. MASA. This part of the problem may be unsolveable.
skipping to change at page 72, line 28 skipping to change at page 75, line 46
connection would occur) connection would occur)
The BRSKI call-home mechanism is mediated via the owner's Registrar, The BRSKI call-home mechanism is mediated via the owner's Registrar,
and the information that is transmitted is directly auditable by the and the information that is transmitted is directly auditable by the
device owner. This is in stark contrast to many "call-home" device owner. This is in stark contrast to many "call-home"
protocols where the device autonomously calls home and uses an protocols where the device autonomously calls home and uses an
undocumented protocol. undocumented protocol.
While the contents of the signed part of the pledge voucher request While the contents of the signed part of the pledge voucher request
can not be changed, they are not encrypted at the registrar. The can not be changed, they are not encrypted at the registrar. The
ability to audit the messages by the owner of the network a mechanism ability to audit the messages by the owner of the network is a
to defend against exfiltration of data by a nefarious pledge. Both mechanism to defend against exfiltration of data by a nefarious
are, to re-iterate, encrypted by TLS while in transit. pledge. Both are, to re-iterate, encrypted by TLS while in transit.
The BRSKI-MASA exchange reveals the following information to the The BRSKI-MASA exchange reveals the following information to the
manufacturer: manufacturer:
o the identity of the device being enrolled. This is revealed by o the identity of the device being enrolled. This is revealed by
transmission of a signed voucher-request containing the serial- transmission of a signed voucher-request containing the serial-
number. The manufacturer can usually link the serial number to a number. The manufacturer can usually link the serial number to a
device model. device model.
o an identity of the domain owner in the form of the domain trust o an identity of the domain owner in the form of the domain trust
skipping to change at page 73, line 18 skipping to change at page 76, line 37
private. private.
Based upon the above information, the manufacturer is able to track a Based upon the above information, the manufacturer is able to track a
specific device from pseudonymous domain identity to the next specific device from pseudonymous domain identity to the next
pseudonymous domain identity. If there is sales-channel integration, pseudonymous domain identity. If there is sales-channel integration,
then the identities are not pseudonymous. then the identities are not pseudonymous.
The manufacturer knows the IP address of the Registrar, but it can The manufacturer knows the IP address of the Registrar, but it can
not see the IP address of the device itself. The manufacturer can not see the IP address of the device itself. The manufacturer can
not track the device to a detailed physical or network location, only not track the device to a detailed physical or network location, only
to the the location of the Registrar itself. That is likely to be at to the location of the Registrar. That is likely to be at the
the Enterprise or ISPs headquarters. Enterprise or ISPs headquarters.
The above situation is to be distinguished from a residential/ The above situation is to be distinguished from a residential/
individual person who registers a device from a manufacturer. individual person who registers a device from a manufacturer.
Individuals do not tend to have multiple offices, and their registrar Individuals do not tend to have multiple offices, and their registrar
is likely on the same network as the device. A manufacturer that is likely on the same network as the device. A manufacturer that
sells switching/routing products to enterprises should hardly be sells switching/routing products to enterprises should hardly be
surprised if additional purchases switching/routing products are surprised if additional purchases switching/routing products are
purchased. Deviations from a historical trend or an establish made. Deviations from a historical trend or an establish baseline
baseline would, however, be notable. would, however, be notable.
The situation is not improved by the enterprise/ISP using The situation is not improved by the enterprise/ISP using
anonymization services such as ToR [Dingledine2004], as a TLS 1.2 anonymization services such as ToR [Dingledine2004], as a TLS 1.2
connection will reveal the ClientCertificate used, clearly connection will reveal the ClientCertificate used, clearly
identifying the enterprise/ISP involved. TLS 1.3 is better in this identifying the enterprise/ISP involved. TLS 1.3 is better in this
regard, but an active attacker can still discover the parties regard, but an active attacker can still discover the parties
involved by performing a Man-In-The-Middle-Attack on the first involved by performing a Man-In-The-Middle-Attack on the first
attempt (breaking/killing it with a TCP RST), and then letting attempt (breaking/killing it with a TCP RST), and then letting
subsequent connection pass through. subsequent connection pass through.
skipping to change at page 74, line 34 skipping to change at page 78, line 4
ownership simply occurs. ownership simply occurs.
3. A manufacturer could however decide not to issue a new voucher in 3. A manufacturer could however decide not to issue a new voucher in
response to a transfer of ownership. This is essentially the response to a transfer of ownership. This is essentially the
same as the stolen case, with the manufacturer having decided same as the stolen case, with the manufacturer having decided
that the sale was not legitimate. that the sale was not legitimate.
4. There is a fourth case, if the manufacturer is providing 4. There is a fourth case, if the manufacturer is providing
protection against stolen devices. The manufacturer then has a protection against stolen devices. The manufacturer then has a
responsibility to protect the legitimate owner against fraudulent responsibility to protect the legitimate owner against fraudulent
claims that the equipment was stolen. In the absense of such claims that the equipment was stolen. In the absence of such
manufacturer protection, such a claim would cause the manufacturer protection, such a claim would cause the
manufacturer to refuse to issue a new voucher. Should the device manufacturer to refuse to issue a new voucher. Should the device
go through a deep factory reset (for instance, replacement of a go through a deep factory reset (for instance, replacement of a
damaged main board component, the device would not bootstrap. damaged main board component, the device would not bootstrap.
5. Finally, there is a fifth case: the manufacturer has decided to 5. Finally, there is a fifth case: the manufacturer has decided to
end-of-line the device, or the owner has not paid a yearly end-of-line the device, or the owner has not paid a yearly
support amount, and the manufacturer refuses to issue new support amount, and the manufacturer refuses to issue new
vouchers at that point. This last case is not new to the vouchers at that point. This last case is not new to the
industry: many license systems are already deployed that have industry: many license systems are already deployed that have
skipping to change at page 75, line 49 skipping to change at page 79, line 21
set of rules (or laws or entitlements), but the domain registry is in set of rules (or laws or entitlements), but the domain registry is in
another one. Which rules apply is something will have to be worked another one. Which rules apply is something will have to be worked
out: the manufacturer could come to believe they are dealing with out: the manufacturer could come to believe they are dealing with
Grey market equipment, when it is simply dealing with a global Grey market equipment, when it is simply dealing with a global
enterprise. enterprise.
10.6. Some mitigations for meddling by manufacturers 10.6. Some mitigations for meddling by manufacturers
The most obvious mitigation is not to buy the product. Pick The most obvious mitigation is not to buy the product. Pick
manufacturers that are up-front about their policies, who do not manufacturers that are up-front about their policies, who do not
change them gratuitiously. change them gratuitously.
Section Section 7.4.3 describes some ways in which a manufacturer Section 7.4.3 describes some ways in which a manufacturer could
could provide a mechanism to manage the trust anchors and built-in provide a mechanism to manage the trust anchors and built-in
certificates (IDevID) as an extension. There are a variety of certificates (IDevID) as an extension. There are a variety of
mechanism, and some may take a substantial amount of work to get mechanism, and some may take a substantial amount of work to get
exactly correct. These mechanisms do not change the flow of the exactly correct. These mechanisms do not change the flow of the
protocol described here, but rather allow the starting trust protocol described here, but rather allow the starting trust
assumptions to be changed. This is an an area for future assumptions to be changed. This is an area for future
standardization work. standardization work.
Replacement of the voucher validation anchors (usually pointing to Replacement of the voucher validation anchors (usually pointing to
the original manufacturer's MASA) with those of the new owner permits the original manufacturer's MASA) with those of the new owner permits
the new owner to issue vouchers to subsequent owners. This would be the new owner to issue vouchers to subsequent owners. This would be
done by having the selling (old) owner to run a MASA. done by having the selling (old) owner to run a MASA.
The BRSKI protocol depends upon a trust anchor on the device and an The BRSKI protocol depends upon a trust anchor on the device and an
identity on the device. Management of these entities facilitates a identity on the device. Management of these entities facilitates a
few new operational modes without making any changes to the BRSKI few new operational modes without making any changes to the BRSKI
skipping to change at page 76, line 42 skipping to change at page 80, line 14
As discussed at the end of Section 5.8.1, new work could be done to As discussed at the end of Section 5.8.1, new work could be done to
use a distributed consensus technology for the audit log. This would use a distributed consensus technology for the audit log. This would
permit the audit log to continue to be useful, even when there is a permit the audit log to continue to be useful, even when there is a
chain of MASA due to changes of ownership. chain of MASA due to changes of ownership.
10.7. Death of a manufacturer 10.7. Death of a manufacturer
A common concern has been that a manufacturer could go out of A common concern has been that a manufacturer could go out of
business, leaving owners of devices unable to get new vouchers for business, leaving owners of devices unable to get new vouchers for
existing products. Said products might be previous deployed and need existing products. Said products might have been previously
to be re-initialized, purchased used, or just kept in a warehouse as deployed, but need to be re-initialized, they might have been
long-term spares. purchased used, or they might have kept in a warehouse as long-term
spares.
The MASA was named the Manufacturer *Authorized* Signing Authority to The MASA was named the Manufacturer *Authorized* Signing Authority to
emphasize that it need not be the manufacturer itself that performs emphasize that it need not be the manufacturer itself that performs
this. It is anticipated that specialist service providers will come this. It is anticipated that specialist service providers will come
to exist that deal with the creation of vouchers in much the same way to exist that deal with the creation of vouchers in much the same way
that many companies have outsourced email, advertising and janitorial that many companies have outsourced email, advertising and janitorial
services. services.
Further, it is expected that as part of any service agreement that Further, it is expected that as part of any service agreement that
the manufacturer would arrange to escrow appropriate private keys the manufacturer would arrange to escrow appropriate private keys
skipping to change at page 78, line 49 skipping to change at page 82, line 18
request. Supply chain integration ("know your customer") is an request. Supply chain integration ("know your customer") is an
additional step that MASA providers and device vendors can explore. additional step that MASA providers and device vendors can explore.
11.2. Availability of good random numbers 11.2. Availability of good random numbers
Although the nonce used by the Pledge in the voucher-request does not Although the nonce used by the Pledge in the voucher-request does not
require a strong cryptographic randomness, the use of TLS in all of require a strong cryptographic randomness, the use of TLS in all of
the protocols in this document does. the protocols in this document does.
In particular implementations should pay attention to the advance in In particular implementations should pay attention to the advance in
[RFC4086] section 3, particulary section 3.4. Devices which are [RFC4086] section 3, particularly section 3.4. Devices which are
reset to factory default in order to perform a second bootstrap with reset to factory default in order to perform a second bootstrap with
a new owner MUST NOT seed their random number generators in the same a new owner MUST NOT seed their random number generators in the same
way. way across bootstraps.
11.3. Freshness in Voucher-Requests 11.3. Freshness in Voucher-Requests
A concern has been raised that the pledge voucher-request should A concern has been raised that the pledge voucher-request should
contain some content (a nonce) provided by the registrar and/or MASA contain some content (a nonce) provided by the registrar and/or MASA
in order for those actors to verify that the pledge voucher-request in order for those actors to verify that the pledge voucher-request
is fresh. is fresh.
There are a number of operational problems with getting a nonce from There are a number of operational problems with getting a nonce from
the MASA to the pledge. It is somewhat easier to collect a random the MASA to the pledge. It is somewhat easier to collect a random
skipping to change at page 80, line 17 skipping to change at page 83, line 36
enabled state. This would require wiping the pledge of current enabled state. This would require wiping the pledge of current
configuration and triggering a re-bootstrapping of the pledge. This configuration and triggering a re-bootstrapping of the pledge. This
is no more likely than simply taking control of the pledge directly is no more likely than simply taking control of the pledge directly
but if this is a consideration the target network is RECOMMENDED to but if this is a consideration the target network is RECOMMENDED to
take the following steps: take the following steps:
o Ongoing network monitoring for unexpected bootstrapping attempts o Ongoing network monitoring for unexpected bootstrapping attempts
by pledges. by pledges.
o Retrieval and examination of MASA log information upon the o Retrieval and examination of MASA log information upon the
occurence of any such unexpected events. Rm will be listed in the occurrence of any such unexpected events. Rm will be listed in
logs along with nonce information for analysis. the logs along with nonce information for analysis.
11.4. Trusting manufacturers 11.4. Trusting manufacturers
The BRSKI extensions to EST permit a new pledge to be completely The BRSKI extensions to EST permit a new pledge to be completely
configured with domain specific trust anchors. The link from built- configured with domain specific trust anchors. The link from built-
in manufacturer-provided trust anchors to domain-specific trust in manufacturer-provided trust anchors to domain-specific trust
anchors is mediated by the signed voucher artifact. anchors is mediated by the signed voucher artifact.
If the manufacturer's IDevID signing key is not properly validated, If the manufacturer's IDevID signing key is not properly validated,
then there is a risk that the network will accept a pledge that then there is a risk that the network will accept a pledge that
skipping to change at page 82, line 20 skipping to change at page 85, line 38
2019 will have hardware and software capable of validating algorithms 2019 will have hardware and software capable of validating algorithms
common in 2019, and will have no defense against attacks (both common in 2019, and will have no defense against attacks (both
quantum and von-neuman brute force attacks) which have not yet been quantum and von-neuman brute force attacks) which have not yet been
invented. This concern is orthogonal to the concern about access to invented. This concern is orthogonal to the concern about access to
private keys, but this concern likely dominates and limits the private keys, but this concern likely dominates and limits the
lifespan of a device in a warehouse. If any update to firmware to lifespan of a device in a warehouse. If any update to firmware to
support new cryptographic mechanism were possible (while the device support new cryptographic mechanism were possible (while the device
was in a warehouse), updates to trust anchors would also be done at was in a warehouse), updates to trust anchors would also be done at
the same time. the same time.
The set of standard operating proceedures for maintaining high value The set of standard operating procedures for maintaining high value
private keys is well documented. For instance, the WebPKI provides a private keys is well documented. For instance, the WebPKI provides a
number of options for audits at {{cabforumaudit}}, and the DNSSEC number of options for audits at [cabforumaudit], and the DNSSEC root
root operations are well documented at {{dnssecroot}}. operations are well documented at [dnssecroot].
It is not clear if Manufacturers will take this level of precaution, It is not clear if Manufacturers will take this level of precaution,
or how strong the economic incentives are to maintain an appropriate or how strong the economic incentives are to maintain an appropriate
level of security. level of security.
This next section examines the risk due to a compromised MASA key. This next section examines the risk due to a compromised manufacturer
This is followed by examination of the risk of a compromised IDevID signing key. This is followed by examination of the risk due
manufacturer IDevID signing key. The third section sections below to a compromised MASA key. The third section sections below examines
examines the situation where MASA web server itself is under attacker the situation where MASA web server itself is under attacker control,
control, but that the MASA signing key itself is safe in a not- but that the MASA signing key itself is safe in a not-directly
directly connected hardware module. connected hardware module.
11.5.1. Compromise of Manufacturer IDevID signing keys 11.5.1. Compromise of Manufacturer IDevID signing keys
An attacker that has access to the key that the manufacturer uses to An attacker that has access to the key that the manufacturer uses to
sign IDevID certificates can create counterfeit devices. Such sign IDevID certificates can create counterfeit devices. Such
devices can claim to be from a particular manufacturer, but be devices can claim to be from a particular manufacturer, but be
entirely different devices: Trojan horses in effect. entirely different devices: Trojan horses in effect.
As the attacker controls the MASA URL in the certificate, the As the attacker controls the MASA URL in the certificate, the
registrar can be convinced to talk to the attackers' MASA. The registrar can be convinced to talk to the attackers' MASA. The
skipping to change at page 86, line 5 skipping to change at page 89, line 20
and Thomas Werner and Thomas Werner
Significant reviews were done by Jari Arko, Christian Huitema and Significant reviews were done by Jari Arko, Christian Huitema and
Russ Housley. Russ Housley.
Henk Birkholz contributed the CDDL for the audit log response. Henk Birkholz contributed the CDDL for the audit log response.
This document started it's life as a two-page idea from Steinthor This document started it's life as a two-page idea from Steinthor
Bjarnason. Bjarnason.
In addition, significant review comments were receives by many IESG In addition, significant review comments were received by many IESG
members, including Adam Roach, Alexey Melnikov, Alissa Cooper, members, including Adam Roach, Alexey Melnikov, Alissa Cooper,
Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund. Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund.
13. References 13. References
13.1. Normative References 13.1. Normative References
[cabforumaudit]
"Information for Auditors and Assessors", August 2019,
<https://cabforum.org/
information-for-auditors-and-assessors/>.
[dnssecroot]
"DNSSEC Practice Statement for the Root Zone ZSK
Operator", December 2017,
<https://www.iana.org/dnssec/dps/zsk-operator/
dps-zsk-operator-v2.0.pdf>.
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-20 (work in progress), July 2019. plane-20 (work in progress), July 2019.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/standard/802.1AR-
standard/802.1AR-2009.html>. 2009.html>.
[ITU.X690.1994]
International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/
top.htm>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
skipping to change at page 89, line 45 skipping to change at page 93, line 13
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
13.2. Informative References 13.2. Informative References
[brewski] "Urban Dictionary: Brewski", October 2019,
<https://www.urbandictionary.com/define.php?term=brewski>.
[cabforumaudit]
"Information for Auditors and Assessors", August 2019,
<https://cabforum.org/information-for-auditors-and-
assessors/>.
[Dingledine2004] [Dingledine2004]
Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the
second-generation onion router", 2004, second-generation onion router", 2004,
<https://spec.torproject.org/tor-spec>. <https://spec.torproject.org/tor-spec>.
[dnssecroot]
"DNSSEC Practice Statement for the Root Zone ZSK
Operator", December 2017,
<https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-
operator-v2.0.pdf>.
[docsisroot] [docsisroot]
"CableLabs Digital Certificate Issuance Service", February "CableLabs Digital Certificate Issuance Service", February
2018, <https://www.cablelabs.com/resources/ 2018, <https://www.cablelabs.com/resources/digital-
digital-certificate-issuance-service/>. certificate-issuance-service/>.
[I-D.ietf-ace-coap-est] [I-D.ietf-ace-coap-est]
Stok, P., Kampanakis, P., Richardson, M., and S. Raza, Stok, P., Kampanakis, P., Richardson, M., and S. Raza,
"EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap-
est-13 (work in progress), September 2019. est-15 (work in progress), October 2019.
[I-D.ietf-anima-constrained-voucher] [I-D.ietf-anima-constrained-voucher]
Richardson, M., Stok, P., and P. Kampanakis, "Constrained Richardson, M., Stok, P., and P. Kampanakis, "Constrained
Voucher Artifacts for Bootstrapping Protocols", draft- Voucher Artifacts for Bootstrapping Protocols", draft-
ietf-anima-constrained-voucher-05 (work in progress), July ietf-anima-constrained-voucher-05 (work in progress), July
2019. 2019.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
skipping to change at page 90, line 49 skipping to change at page 94, line 27
join router in ANIMA bootstrap", draft-richardson-anima- join router in ANIMA bootstrap", draft-richardson-anima-
state-for-joinrouter-02 (work in progress), January 2018. state-for-joinrouter-02 (work in progress), January 2018.
[imprinting] [imprinting]
"Wikipedia article: Imprinting", July 2015, "Wikipedia article: Imprinting", July 2015,
<https://en.wikipedia.org/wiki/Imprinting_(psychology)>. <https://en.wikipedia.org/wiki/Imprinting_(psychology)>.
[IoTstrangeThings] [IoTstrangeThings]
"IoT of toys stranger than fiction: Cybersecurity and data "IoT of toys stranger than fiction: Cybersecurity and data
privacy update (accessed 2018-12-02)", March 2017, privacy update (accessed 2018-12-02)", March 2017,
<https://www.welivesecurity.com/2017/03/03/ <https://www.welivesecurity.com/2017/03/03/internet-of-
internet-of-things-security-privacy-iot-update/>. things-security-privacy-iot-update/>.
[livingwithIoT] [livingwithIoT]
"What is it actually like to live in a house filled with "What is it actually like to live in a house filled with
IoT devices? (accessed 2018-12-02)", February 2018, IoT devices? (accessed 2018-12-02)", February 2018,
<https://www.siliconrepublic.com/machines/ <https://www.siliconrepublic.com/machines/iot-smart-
iot-smart-devices-reality>. devices-reality>.
[openssl] "OpenSSL X509 utility", September 2019, [openssl] "OpenSSL X509 utility", September 2019,
<https://www.openssl.org/docs/man1.1.1/man1/ <https://www.openssl.org/docs/man1.1.1/man1/openssl-
openssl-x509.html/>. x509.html/>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999, RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>. <https://www.rfc-editor.org/info/rfc2663>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/info/rfc5209>. <https://www.rfc-editor.org/info/rfc5209>.
skipping to change at page 92, line 30 skipping to change at page 96, line 10
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
[slowloris] [slowloris]
"Slowloris (computer security)", February 2019, "Slowloris (computer security)", February 2019,
<https://en.wikipedia.org/wiki/ <https://en.wikipedia.org/wiki/
Slowloris_(computer_security)/>. Slowloris_(computer_security)/>.
[softwareescrow]
"Wikipedia article: Software Escrow", October 2019,
<https://en.wikipedia.org/wiki/Source_code_escrow>.
[Stajano99theresurrecting] [Stajano99theresurrecting]
Stajano, F. and R. Anderson, "The resurrecting duckling: Stajano, F. and R. Anderson, "The resurrecting duckling:
security issues for ad-hoc wireless networks", 1999, security issues for ad-hoc wireless networks", 1999,
<https://www.cl.cam.ac.uk/~fms27/ <https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-
papers/1999-StajanoAnd-duckling.pdf>. duckling.pdf>.
[TR069] "TR-69: CPE WAN Management Protocol", February 2018, [TR069] "TR-69: CPE WAN Management Protocol", February 2018,
<https://www.broadband-forum.org/standards-and-software/ <https://www.broadband-forum.org/standards-and-software/
technical-specifications/tr-069-files-tools>. technical-specifications/tr-069-files-tools>.
[W3C.WD-capability-urls-20140218] [W3C.WD-capability-urls-20140218]
Tennison, J., "Good Practices for Capability URLs", World Tennison, J., "Good Practices for Capability URLs", World
Wide Web Consortium WD WD-capability-urls-20140218, Wide Web Consortium WD WD-capability-urls-20140218,
February 2014, February 2014,
<http://www.w3.org/TR/2014/WD-capability-urls-20140218>. <http://www.w3.org/TR/2014/WD-capability-urls-20140218>.
 End of changes. 153 change blocks. 
445 lines changed or deleted 641 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/