draft-ietf-anima-bootstrapping-keyinfra-21.txt   draft-ietf-anima-bootstrapping-keyinfra-22.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: December 15, 2019 Sandelman Expires: December 19, 2019 Sandelman
M. Behringer M. Behringer
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
K. Watsen K. Watsen
Watsen Networks Watsen Networks
June 13, 2019 June 17, 2019
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-21 draft-ietf-anima-bootstrapping-keyinfra-22
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 remote secure key infrastructure (BRSKI)
is created using manufacturer installed X.509 certificate, in is created using manufacturer installed X.509 certificate, in
combination with a manufacturer's authorizing service, both online combination with a manufacturer's authorizing service, both online
and offline. Bootstrapping a new device can occur using a routable and offline. Bootstrapping a new device can occur using a routable
address and a cloud service, or using only link-local connectivity, address and a cloud service, or using only link-local connectivity,
or on limited/disconnected networks. Support for lower security or on limited/disconnected networks. Support for lower security
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 December 15, 2019. This Internet-Draft will expire on December 19, 2019.
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 3, line 42 skipping to change at page 3, line 42
5.8. Registrar audit log request . . . . . . . . . . . . . . . 47 5.8. Registrar audit log request . . . . . . . . . . . . . . . 47
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 48 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 48
5.8.2. Registrar audit log verification . . . . . . . . . . 49 5.8.2. Registrar audit log verification . . . . . . . . . . 49
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 50 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 50
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 51 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 51
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51
5.9.3. EST Client Certificate Request . . . . . . . . . . . 52 5.9.3. EST Client Certificate Request . . . . . . . . . . . 52
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 53 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 53
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53
6. Reduced security operational modes . . . . . . . . . . . . . 54 6. Clarification of transfer-encoding . . . . . . . . . . . . . 54
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 54 7. Reduced security operational modes . . . . . . . . . . . . . 54
6.2. Pledge security reductions . . . . . . . . . . . . . . . 55 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 54
6.3. Registrar security reductions . . . . . . . . . . . . . . 55 7.2. Pledge security reductions . . . . . . . . . . . . . . . 55
6.4. MASA security reductions . . . . . . . . . . . . . . . . 56 7.3. Registrar security reductions . . . . . . . . . . . . . . 56
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 7.4. MASA security reductions . . . . . . . . . . . . . . . . 57
7.1. Well-known EST registration . . . . . . . . . . . . . . . 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 57 8.1. Well-known EST registration . . . . . . . . . . . . . . . 58
7.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 58 8.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 58
7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 58 8.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 58
7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 58 8.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 58
8. Applicability to the Autonomic 8.5. MUD File Extension for the MASA . . . . . . . . . . . . . 59
9. Applicability to the Autonomic
Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 59 Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 59
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60
9.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 60 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 60
9.2. What BRSKI-MASA reveals to the manufacturer . . . . . . . 60 10.2. What BRSKI-MASA reveals to the manufacturer . . . . . . 61
9.3. Manufacturers and Used or Stolen Equipment . . . . . . . 62 10.3. Manufacturers and Used or Stolen Equipment . . . . . . . 62
9.4. Manufacturers and Grey market equipment . . . . . . . . . 63 10.4. Manufacturers and Grey market equipment . . . . . . . . 63
9.5. Some mitigations for meddling by manufacturers . . . . . 64 10.5. Some mitigations for meddling by manufacturers . . . . . 64
10. Security Considerations . . . . . . . . . . . . . . . . . . . 65 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65
10.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 66 11.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 66
10.2. Freshness in Voucher-Requests . . . . . . . . . . . . . 66 11.2. Freshness in Voucher-Requests . . . . . . . . . . . . . 67
10.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 68 11.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 68
10.4. Manufacturer Maintainance of trust anchors . . . . . . . 69 11.4. Manufacturer Maintainance of trust anchors . . . . . . . 69
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
12.1. Normative References . . . . . . . . . . . . . . . . . . 70 13.1. Normative References . . . . . . . . . . . . . . . . . . 70
12.2. Informative References . . . . . . . . . . . . . . . . . 72 13.2. Informative References . . . . . . . . . . . . . . . . . 73
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 76 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 76
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 76 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 76
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 76 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 76
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 76 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 77
Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 77 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 77
Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 79 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 80
D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 79 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 80
D.1.1. MASA key pair for voucher signatures . . . . . . . . 79 D.1.1. MASA key pair for voucher signatures . . . . . . . . 80
D.1.2. Manufacturer key pair for IDevID signatures . . . . . 79 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 80
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 80 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 81
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 82 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 83
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 83 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 84
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 83 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 84
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 87 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 88
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 92 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97
1. Introduction 1. Introduction
BRSKI provides a solution for secure zero-touch (automated) bootstrap BRSKI provides a solution for secure zero-touch (automated) bootstrap
of new (unconfigured) devices that are called pledges in this of new (unconfigured) devices that are called pledges in this
document. document.
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]. Other users of the BRSKI [I-D.ietf-anima-autonomic-control-plane]. Other users of the BRSKI
protocol will need to provide separate applicability statements that protocol will need to provide separate applicability statements that
include privacy and security considerations appropriate to that include privacy and security considerations appropriate to that
deployment. Section Section 8 explains the details applicability for deployment. Section Section 9 explains the details applicability for
this the ACP usage. this the ACP usage.
This document describes how pledges discover (or be discovered by) an This document describes how pledges discover (or be discovered by) an
element of the network domain to which the pledge belongs to perform element of the network domain to which the pledge belongs to perform
the bootstrap. This element (device) is called the registrar. the bootstrap. This element (device) is called the registrar.
Before any other operation, pledge and registrar need to establish Before any other operation, pledge and registrar need to establish
mutual trust: mutual trust:
1. Registrar authenticating the pledge: "Who is this device? What 1. Registrar authenticating the pledge: "Who is this device? What
is its identity?" is its identity?"
skipping to change at page 38, line 35 skipping to change at page 38, line 35
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 Section 2.8 connection and uses the MASA URL obtained as described in Section 2.8
for [RFC6125] authentication of the MASA. for [RFC6125] authentication of the MASA.
The primary method of registrar "authentication" by the MASA is The primary method of registrar "authentication" by the MASA is
detailed in Section 5.5. As detailed in Section 10 the MASA might detailed in Section 5.5. As detailed in Section 11 the MASA might
find it necessary to request additional registrar authentication. find it necessary to request additional registrar authentication.
The MASA and the registrars SHOULD be prepared to support TLS client The MASA and the registrars SHOULD be prepared to support TLS client
certificate authentication and/or HTTP Basic or Digest authentication certificate authentication and/or HTTP Basic or Digest authentication
as described in [RFC7030] for EST clients. This connection MAY also as described in [RFC7030] for EST clients. This connection MAY also
have no client authentication at all (Section 6.4) have no client authentication at all (Section 7.4)
The authentication of the BRSKI-MASA connection does not affect the The authentication of the BRSKI-MASA connection does not affect 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. to the audit log.
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 REST connection with a web service and that there are a
number of authentication models being explored within the industry. number 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
skipping to change at page 45, line 27 skipping to change at page 45, line 27
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 manufacter installed trust anchor(s) is out-of-scope of this the manufacter 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 that the voucher nonce field is accurate and
matches the nonce the pledge submitted to this registrar, or that the matches the nonce the pledge submitted to this registrar, or that the
voucher is nonceless (see Section 6.2). voucher is nonceless (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.
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
The 'pinned-domain-cert' element of the voucher contains the domain The 'pinned-domain-cert' element of the voucher contains the domain
CA's public key. The pledge MUST use the 'pinned-domain-cert' trust CA's public key. The pledge MUST use the 'pinned-domain-cert' trust
skipping to change at page 47, line 22 skipping to change at page 47, line 22
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. The client ignores any response. Within the an HTTP 404 error. The client ignores any response. Within the
server logs the server SHOULD capture this telemetry information. server logs the server SHOULD capture this telemetry information.
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.
Additional standard JSON fields in this POST MAY be added, see Additional standard JSON fields in this POST MAY be added, see
Section 7.3. Section 8.3.
5.8. Registrar audit log request 5.8. Registrar audit log request
After receiving the pledge status telemetry Section 5.7, the After receiving the pledge status telemetry Section 5.7, the
registrar SHOULD request the MASA audit log from the MASA service. registrar SHOULD request the MASA audit log from the MASA service.
This is done with an HTTP GET using the operation path value of This is done with an HTTP GET using the operation path value of
"/.well-known/est/requestauditlog". "/.well-known/est/requestauditlog".
The registrar SHOULD HTTP POST the same registrar voucher-request as The registrar SHOULD HTTP POST the same registrar voucher-request as
skipping to change at page 54, line 5 skipping to change at page 54, line 5
This document describes extensions to EST for the purposes of This document describes extensions to EST for the purposes of
bootstrapping of remote key infrastructures. Bootstrapping is bootstrapping of remote key infrastructures. Bootstrapping is
relevant for CoAP enrollment discussions as well. The defintion of relevant for CoAP enrollment discussions as well. The defintion of
EST and BRSKI over CoAP is not discussed within this document beyond EST and BRSKI over CoAP is not discussed within this document beyond
ensuring proxy support for CoAP operations. Instead it is ensuring proxy support for CoAP operations. Instead it is
anticipated that a definition of CoAP mappings will occur in anticipated that a definition of CoAP mappings will occur in
subsequent documents such as [I-D.ietf-ace-coap-est] and that CoAP subsequent documents such as [I-D.ietf-ace-coap-est] and that CoAP
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. Reduced security operational modes 6. Clarification of transfer-encoding
[RFC7030] defines it's endpoints to include a "Content-Transfer-
Encoding" heading, and the payloads to be [RFC4648] Base64 encoded
DER.
When used within BRSKI, the original RFC7030 EST endpoints remain
Base64 encoded, but the new BRSKI end points which send and receive
binary artifacts (specifically, ../voucherrequest) are binary. That
is, no encoding is used.
In the BRSKI context, the EST "Content-Transfer-Encoding" header if
present, SHOULD be ignored. This header does not need to included.
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. The following
sections detail specific ways that the pledge, registrar and MASA can sections detail specific ways that the pledge, registrar and MASA can
be configured to run in a less secure mode for the indicated reasons. be configured to run in a less secure mode for the indicated reasons.
This section is considered non-normative: use suggested methods MUST This section is considered non-normative: use suggested methods MUST
be detailed in specific profiles of BRSKI. This is the subject for be detailed in specific profiles of BRSKI. This is the subject for
future work. future work.
6.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 |
| | | | | | | (Internet) | | | | | | | | (Internet) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
skipping to change at page 55, line 5 skipping to change at page 55, line 21
log information to registrars. The MASA does not know which log information to registrars. The MASA does not know which
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.
Current text provides only for a trusted manufacturer. Current text provides only for a trusted manufacturer.
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.
6.2. Pledge security reductions 7.2. Pledge security reductions
The pledge can choose to accept vouchers using less secure methods. The pledge can choose to accept vouchers using less secure methods.
These methods enable offline and emergency (touch based) deployment These methods enable offline and emergency (touch based) deployment
use cases: use cases:
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.
skipping to change at page 55, line 40 skipping to change at page 56, line 7
can always be deployed even when autonomic methods fail. This can always be deployed even when autonomic methods fail. This
allows for unsecured imprint. allows for unsecured imprint.
It is RECOMMENDED that "trust on first use" or any method of skipping It is RECOMMENDED that "trust on first use" or any method of skipping
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 [RFC5209] available if hardware assisted Network Endpoint Assessment [RFC5209]
is supported. This recommendation ensures that domain network is supported. This recommendation ensures that domain network
monitoring can detect innappropriate use of offline or emergency monitoring can detect innappropriate use of offline or emergency
deployment procedures when voucher-based bootstrapping is not used. deployment procedures when voucher-based bootstrapping is not used.
6.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 These methods are acceptable when low security models are needed, as
the security decisions are being made by the local administrator, but the security decisions are being made by the local administrator, but
they MUST NOT be the default behavior: they MUST NOT be the default behavior:
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.
skipping to change at page 56, line 40 skipping to change at page 57, line 7
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 permanent
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.
6.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 bound to the specific device identities. In which deployments unless bound to the specific device identities. In which
case these modes can be provided as additional features for specific case these modes can be provided as additional features for specific
customers. The MASA service can choose to run in less secure modes customers. The MASA service can choose to run in less secure modes
by: by:
1. Not enforcing that a nonce is in the voucher. This results in 1. Not enforcing that a nonce is in the voucher. This results in
distribution of a voucher that never expires and in effect makes distribution of a voucher that never expires and in effect makes
the Domain an always trusted entity to the pledge during any the Domain an always trusted entity to the pledge during any
skipping to change at page 57, line 29 skipping to change at page 57, line 45
track ownership during shipping and supply chain and allows for a track ownership during shipping and supply chain and allows for a
very low overhead MASA service. A registrar uses the audit log very low overhead MASA service. A registrar uses the audit log
information as a defense in depth strategy to ensure that this information as a defense in depth strategy to ensure that this
does not occur unexpectedly (for example when purchasing new 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- information is reported.) The MASA SHOULD verify the 'prior-
signed-voucher-request' information for pledges that support that signed-voucher-request' information for pledges that support that
functionality. This provides a proof-of-proximity check that functionality. This provides a proof-of-proximity check that
reduces the need for ownership verification. reduces the need for ownership verification.
7. IANA Considerations 8. IANA Considerations
This document requires the following IANA actions: This document requires the following IANA actions:
7.1. Well-known EST registration 8.1. Well-known EST registration
This document extends the definitions of "est" (so far defined via This document extends the definitions of "est" (so far defined via
RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
well-known-uris.xhtml" registry as follows: well-known-uris.xhtml" registry as follows:
o add /.well-known/est/requestvoucher (see Section 5.5 ) o add /.well-known/est/requestvoucher (see Section 5.5 )
o add /.well-known/est/requestauditlog (see Section 5.7) o add /.well-known/est/requestauditlog (see Section 5.7)
7.2. PKIX Registry 8.2. PKIX Registry
IANA is requested to register the following: IANA is requested to register the following:
This document requests a number for id-mod-MASAURLExtn2016(TBD) from This document requests a number for id-mod-MASAURLExtn2016(TBD) from
the pkix(7) id-mod(0) Registry. the pkix(7) id-mod(0) Registry.
This document has received an early allocation from the id-pe This document has received an early allocation from the id-pe
registry (SMI Security for PKIX Certificate Extension) for id-pe- registry (SMI Security for PKIX Certificate Extension) for id-pe-
masa-url with the value 32, resulting in an OID of masa-url with the value 32, resulting in an OID of
1.3.6.1.5.5.7.1.32. 1.3.6.1.5.5.7.1.32.
7.3. Pledge BRSKI Status Telemetry 8.3. Pledge BRSKI Status Telemetry
IANA is requested to create a new Registry entitled: "BRSKI IANA is requested to create a new Registry entitled: "BRSKI
Parameters", and within that Registry to create a table called: Parameters", and within that Registry to create a table called:
"Pledge BRSKI Status Telemetry Attributes". New items can be added "Pledge BRSKI Status Telemetry Attributes". New items can be added
using the Specification Required. The following items are to be in using the Specification Required. The following items are to be in
the initial registration, with this document (Section 5.7) as the the initial registration, with this document (Section 5.7) as the
reference: reference:
o version o version
o Status o Status
o Reason o Reason
o reason-context o reason-context
7.4. DNS Service Names 8.4. DNS Service Names
IANA is requested to register the following Service Names: IANA is requested to register the following Service Names:
Service Name: _brski-proxy Service Name: _brski-proxy
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>. Assignee: IESG <iesg@ietf.org>.
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Description: The Bootstrapping Remote Secure Key Description: The Bootstrapping Remote Secure Key
Infrastructures Proxy Infrastructures Proxy
Reference: [This document] Reference: [This document]
Service Name: _brski-registrar Service Name: _brski-registrar
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>. Assignee: IESG <iesg@ietf.org>.
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Description: The Bootstrapping Remote Secure Key Description: The Bootstrapping Remote Secure Key
Infrastructures Registrar Infrastructures Registrar
Reference: [This document] Reference: [This document]
7.5. MUD File Extension for the MASA 8.5. MUD File Extension for the MASA
The IANA is requested to list the name "masa" in the MUD extensions The IANA is requested to list the name "masa" in the MUD extensions
registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in
Appendix C. Appendix C.
8. Applicability to the Autonomic Control Plane 9. Applicability to the Autonomic Control Plane
This document provides a solution to the requirements for secure This document provides a solution to the requirements for secure
bootstrap set out in Using an Autonomic Control Plane for Stable bootstrap set out in Using an Autonomic Control Plane for Stable
Connectivity of Network Operations, Administration, and Maintenance Connectivity of Network Operations, Administration, and Maintenance
[RFC8368], A Reference Model for Autonomic Networking [RFC8368], A Reference Model for Autonomic Networking
[I-D.ietf-anima-reference-model] and specifically the An Autonomic [I-D.ietf-anima-reference-model] and specifically the An Autonomic
Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section
3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and 3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and
Network). Network).
skipping to change at page 60, line 5 skipping to change at page 60, line 25
on airplanes to configure devices in person. There is a recognition on airplanes to configure devices in person. There is a recognition
as the technology evolves that not every situation may work out, and as the technology evolves that not every situation may work out, and
occasionally a human still still have to visit. occasionally a human still still have to visit.
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. Privacy Considerations 10. Privacy Considerations
9.1. MASA audit log 10.1. MASA audit log
The MASA audit log includes a hash of the domainID for each Registrar The MASA audit log includes a hash of the domainID for each Registrar
a voucher has been issued to. This information is closely related to a voucher has been issued to. This information is closely related to
the actual domain identity, especially when paired with the anti-DDoS the actual domain identity, especially when paired with the anti-DDoS
authentication information the MASA might collect. This could authentication information the MASA might collect. This could
provide sufficient information for the MASA service to build a provide sufficient information for the MASA service to build a
detailed understanding the devices that have been provisioned within detailed understanding the devices that have been provisioned within
a domain. a domain.
There are a number of design choices that mitigate this risk. The There are a number of design choices that mitigate this risk. The
skipping to change at page 60, line 30 skipping to change at page 61, line 5
Additionally the domainID captures only the unauthenticated subject Additionally the domainID captures only the unauthenticated subject
key identifier of the domain. A privacy sensitive domain could key identifier of the domain. A privacy sensitive domain could
theoretically generate a new domainID for each device being deployed. theoretically generate a new domainID for each device being deployed.
Similarly a privacy sensitive domain would likely purchase devices Similarly a privacy sensitive domain would likely purchase devices
that support proximity assertions from a manufacturer that does not that support proximity assertions from a manufacturer that does not
require sales channel integrations. This would result in a require sales channel integrations. This would result in a
significant level of privacy while maintaining the security significant level of privacy while maintaining the security
characteristics provided by Registrar based audit log inspection. characteristics provided by Registrar based audit log inspection.
9.2. What BRSKI-MASA reveals to the manufacturer 10.2. What BRSKI-MASA reveals to the manufacturer
The so-called "call-home" mechanism that occurs as part of the BRSKI- The so-called "call-home" mechanism that occurs as part of the BRSKI-
MASA connection standardizes what has been deemed by some as a MASA connection standardizes what has been deemed by some as a
sinister mechanism for corporate oversight of individuals. sinister mechanism for corporate oversight of individuals.
([livingwithIoT] and [IoTstrangeThings] for a small sample). ([livingwithIoT] and [IoTstrangeThings] for a small sample).
As the Autonomic Control Plane (ACP) usage of BRSKI is not targetted As the Autonomic Control Plane (ACP) usage of BRSKI is not targetted
at individual usage of IoT devices, but rather at the Enterprise and at individual usage of IoT devices, but rather at the Enterprise and
ISP creation of networks in a zero-touch fashion, the "call-home" ISP creation of networks in a zero-touch fashion, the "call-home"
represents a different kind of concern. represents a different kind of concern.
skipping to change at page 62, line 21 skipping to change at page 62, line 45
point of view as the same set of services (and the same set of point of view as the same set of services (and the same set of
Distributed Denial of Service mitigations) may be used. Distributed Denial of Service mitigations) may be used.
Unfortunately, as the BRSKI-MASA connections include TLS Unfortunately, as the BRSKI-MASA connections include TLS
ClientCertificate exchanges, this may easily be observed in TLS 1.2, ClientCertificate exchanges, this may easily be observed in TLS 1.2,
and a traffic analysis may reveal it even in TLS 1.3. This does not and a traffic analysis may reveal it even in TLS 1.3. This does not
make such a plan irrelevant. There may be other organizational make such a plan irrelevant. There may be other organizational
reasons to keep the marketing site (which is often subject to reasons to keep the marketing site (which is often subject to
frequent redesigs, outsourcing, etc.) seperate from the MASA, which frequent redesigs, outsourcing, etc.) seperate from the MASA, which
may need to operate reliably for decades. may need to operate reliably for decades.
9.3. Manufacturers and Used or Stolen Equipment 10.3. Manufacturers and Used or Stolen Equipment
As explained above, the manufacturer receives information each time As explained above, the manufacturer receives information each time
that a device which is in factory-default mode does a zero-touch that a device which is in factory-default mode does a zero-touch
bootstrap, and attempts to enroll into a domain owner's registrar. bootstrap, and attempts to enroll into a domain owner's registrar.
The manufacturer is therefore in a position to decline to issue a The manufacturer is therefore in a position to decline to issue a
voucher if it detects that the new owner is not the same as the voucher if it detects that the new owner is not the same as the
previous owner. previous owner.
1. This can be seen as a feature if the equipment is believed to 1. This can be seen as a feature if the equipment is believed to
skipping to change at page 63, line 22 skipping to change at page 63, line 48
industry: many license systems are already deployed that have industry: many license systems are already deployed that have
significantly worse effect. significantly worse effect.
This section has outlined five situations in which a manufacturer This section has outlined five situations in which a manufacturer
could use the voucher system to enforce what are clearly license could use the voucher system to enforce what are clearly license
terms. A manufacturer that attempted to enforce license terms via terms. A manufacturer that attempted to enforce license terms via
vouchers would find it rather ineffective as the terms would only be vouchers would find it rather ineffective as the terms would only be
enforced when the device is enrolled, and this is not (to repeat), a enforced when the device is enrolled, and this is not (to repeat), a
daily or even monthly occurrance. daily or even monthly occurrance.
9.4. Manufacturers and Grey market equipment 10.4. Manufacturers and Grey market equipment
Manufacturers of devices often sell different products into different Manufacturers of devices often sell different products into different
regional markets. Which product is available in which market can be regional markets. Which product is available in which market can be
driven by price differentials, support issues (some markets may driven by price differentials, support issues (some markets may
require manuals and tech-support to be done in the local language), require manuals and tech-support to be done in the local language),
government export regulation (such as whether strong crypto is government export regulation (such as whether strong crypto is
permitted to be exported, or permitted to be used in a particular permitted to be exported, or permitted to be used in a particular
market). When an domain owner obtains a device from a different market). When an domain owner obtains a device from a different
market (they can be new) and transfers it to a different location, market (they can be new) and transfers it to a different location,
this is called a Grey Market. this is called a Grey Market.
skipping to change at page 64, line 17 skipping to change at page 64, line 39
differentiation by reducing the cost of doing it. differentiation by reducing the cost of doing it.
An issue that manufacturers will need to deal with in the above An issue that manufacturers will need to deal with in the above
automated process is when a device is shipped to one country with one automated process is when a device is shipped to one country with one
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.
9.5. Some mitigations for meddling by manufacturers 10.5. 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 gratutiously. change them gratutiously.
A manufacturer could provide a mechanism to manage the trust anchors A manufacturer could provide a mechanism to manage the trust anchors
and built-in certificates (IDevID) as an extension. This is a and built-in certificates (IDevID) as an extension. This is a
substantial amount of work, and may be an area for future substantial amount of work, and may be an area for future
standardization work. standardization work.
skipping to change at page 65, line 15 skipping to change at page 65, line 38
Some manufacturers may wish to consider replacement of the IDevID as Some manufacturers may wish to consider replacement of the IDevID as
an indication that the device's warantee is terminated. For others, an indication that the device's warantee is terminated. For others,
the privacy requiments of some deployments might consider this a the privacy requiments of some deployments might consider this a
standard operating practice. standard operating practice.
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. Security Considerations 11. Security Considerations
This document details a protocol for bootstrapping that balances This document details a protocol for bootstrapping that balances
operational concerns against security concerns. As detailed in the operational concerns against security concerns. As detailed in the
introduction, and touched on again in Section 6, the protocol allows introduction, and touched on again in Section 7, the protocol allows
for reduced security modes. These attempt to deliver additional for reduced security modes. These attempt to deliver additional
control to the local administrator and owner in cases where less control to the local administrator and owner in cases where less
security provides operational benefits. This section goes into more security provides operational benefits. This section goes into more
detail about a variety of specific considerations. detail about a variety of specific considerations.
To facilitate logging and administrative oversight, in addition to To facilitate logging and administrative oversight, in addition to
triggering Registration verification of MASA logs, the pledge reports triggering Registration verification of MASA logs, the pledge reports
on voucher parsing status to the registrar. In the case of a on voucher parsing status to the registrar. In the case of a
failure, this information is informative to a potentially malicious failure, this information is informative to a potentially malicious
registrar. This is mandated anyway because of the operational registrar. This is mandated anyway because of the operational
benefits of an informed administrator in cases where the failure is benefits of an informed administrator in cases where the failure is
indicative of a problem. The registrar is RECOMMENDED to verify MASA indicative of a problem. The registrar is RECOMMENDED to verify MASA
logs if voucher status telemetry is not received. logs if voucher status telemetry is not received.
To facilitate truely limited clients EST RFC7030 section 3.3.2 To facilitate truely limited clients EST RFC7030 section 3.3.2
requirements that the client MUST support a client authentication requirements that the client MUST support a client authentication
model have been reduced in Section 6 to a statement that the model have been reduced in Section 7 to a statement that the
registrar "MAY" choose to accept devices that fail cryptographic registrar "MAY" choose to accept devices that fail cryptographic
authentication. This reflects current (poor) practices in shipping authentication. This reflects current (poor) practices in shipping
devices without a cryptographic identity that are NOT RECOMMENDED. devices without a cryptographic identity that are NOT RECOMMENDED.
During the provisional period of the connection the pledge MUST treat During the provisional period of the connection the pledge MUST treat
all HTTP header and content data as untrusted data. HTTP libraries all HTTP header and content data as untrusted data. HTTP libraries
are regularly exposed to non-secured HTTP traffic: mature libraries are regularly exposed to non-secured HTTP traffic: mature libraries
should not have any problems. should not have any problems.
Pledges might chose to engage in protocol operations with multiple Pledges might chose to engage in protocol operations with multiple
discovered registrars in parallel. As noted above they will only do discovered registrars in parallel. As noted above they will only do
so with distinct nonce values, but the end result could be multiple so with distinct nonce values, but the end result could be multiple
vouchers issued from the MASA if all registrars attempt to claim the vouchers issued from the MASA if all registrars attempt to claim the
device. This is not a failure and the pledge choses whichever device. This is not a failure and the pledge choses whichever
voucher to accept based on internal logic. The registrars verifying voucher to accept based on internal logic. The registrars verifying
log information will see multiple entries and take this into account log information will see multiple entries and take this into account
for their analytics purposes. for their analytics purposes.
10.1. DoS against MASA 11.1. DoS against MASA
There are uses cases where the MASA could be unavailable or There are uses cases where the MASA could be unavailable or
uncooperative to the Registrar. They include active DoS attacks, uncooperative to the Registrar. They include active DoS attacks,
planned and unplanned network partitions, changes to MASA policy, or planned and unplanned network partitions, changes to MASA policy, or
other instances where MASA policy rejects a claim. These introduce other instances where MASA policy rejects a claim. These introduce
an operational risk to the Registrar owner in that MASA behavior an operational risk to the Registrar owner in that MASA behavior
might limit the ability to bootstrap a pledge device. For example might limit the ability to bootstrap a pledge device. For example
this might be an issue during disaster recovery. This risk can be this might be an issue during disaster recovery. This risk can be
mitigated by Registrars that request and maintain long term copies of mitigated by Registrars that request and maintain long term copies of
"nonceless" vouchers. In that way they are guaranteed to be able to "nonceless" vouchers. In that way they are guaranteed to be able to
skipping to change at page 66, line 45 skipping to change at page 67, line 20
of a valid manufacturer customer, even without validating ownership of a valid manufacturer customer, even without validating ownership
of specific pledge devices, helps to mitigate this. Pledge of specific pledge devices, helps to mitigate this. Pledge
signatures on the pledge voucher-request, as forwarded by the signatures on the pledge voucher-request, as forwarded by the
registrar in the prior-signed-voucher-request field of the registrar registrar in the prior-signed-voucher-request field of the registrar
voucher-request, significantly reduce this risk by ensuring the MASA voucher-request, significantly reduce this risk by ensuring the MASA
can confirm proximity between the pledge and the registrar making the can confirm proximity between the pledge and the registrar making the
request. This mechanism is optional to allow for constrained request. This mechanism is optional to allow for constrained
devices. Supply chain integration ("know your customer") is an devices. 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.
10.2. Freshness in Voucher-Requests 11.2. 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
value from the registrar, but as the registrar is not yet vouched value from the registrar, but as the registrar is not yet vouched
for, such a registrar nonce has little value. There are privacy and for, such a registrar nonce has little value. There are privacy and
skipping to change at page 68, line 12 skipping to change at page 68, line 37
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 Retreival and examination of MASA log information upon the o Retreival and examination of MASA log information upon the
occurance of any such unexpected events. Rm will be listed in the occurance of any such unexpected events. Rm will be listed in the
logs along with nonce information for analysis. logs along with nonce information for analysis.
10.3. Trusting manufacturers 11.3. 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
should not be a member of the network. As the address of the should not be a member of the network. As the address of the
manufacturer's MASA is provided in the IDevID using the extension manufacturer's MASA is provided in the IDevID using the extension
skipping to change at page 69, line 13 skipping to change at page 69, line 38
device category (e.g, a light bulb, or a cable-modem) are signed device category (e.g, a light bulb, or a cable-modem) are signed
by an certificate authority specifically for this. This is done by an certificate authority specifically for this. This is done
by CableLabs today. It is used for authentication and by CableLabs today. It is used for authentication and
authorization as part of TR-79: [docsisroot] and [TR069]. authorization as part of TR-79: [docsisroot] and [TR069].
The existing WebPKI provides a reasonable anchor between manufacturer The existing WebPKI provides a reasonable anchor between manufacturer
name and public key. It authenticates the key. It does not provide name and public key. It authenticates the key. It does not provide
a reasonable authorization for the manufacturer, so it is not a reasonable authorization for the manufacturer, so it is not
directly useable on it's own. directly useable on it's own.
10.4. Manufacturer Maintainance of trust anchors 11.4. Manufacturer Maintainance of trust anchors
BRSKI depends upon the manufacturer building in trust anchors to the BRSKI depends upon the manufacturer building in trust anchors to the
pledge device. The voucher artifact which is signed by the MASA will pledge device. The voucher artifact which is signed by the MASA will
be validated by the pledge using that anchor. This implies that the be validated by the pledge using that anchor. This implies that the
manufacturer needs to maintain access to a signing key that the manufacturer needs to maintain access to a signing key that the
pledge can validate. pledge can validate.
The manufacturer will need to maintain the ability to make signatures The manufacturer will need to maintain the ability to make signatures
that can be validated for the lifetime that the device could be that can be validated for the lifetime that the device could be
onboarded. Whether this onboarding lifetime is less than the device onboarded. Whether this onboarding lifetime is less than the device
skipping to change at page 70, line 10 skipping to change at page 70, line 35
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.
11. Acknowledgements 12. Acknowledgements
We would like to thank the various reviewers for their input, in We would like to thank the various reviewers for their input, in
particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu
Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg, Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg,
Peter van der Stok, and Thomas Werner Peter van der Stok, 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.
12. References 13. References
12.1. Normative References 13.1. Normative References
[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-19 (work in progress), March 2019. plane-19 (work in progress), March 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.
skipping to change at page 71, line 15 skipping to change at page 71, line 39
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, (LDAP): Schema for User Applications", RFC 4519,
DOI 10.17487/RFC4519, June 2006, DOI 10.17487/RFC4519, June 2006,
<https://www.rfc-editor.org/info/rfc4519>. <https://www.rfc-editor.org/info/rfc4519>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
skipping to change at page 72, line 48 skipping to change at page 73, line 28
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)", Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018, RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/info/rfc8368>. <https://www.rfc-editor.org/info/rfc8368>.
12.2. Informative References 13.2. Informative References
[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>.
[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-certificate-issuance-service/>. digital-certificate-issuance-service/>.
skipping to change at page 81, line 12 skipping to change at page 82, line 12
c3o= c3o=
-----END CERTIFICATE----- -----END CERTIFICATE-----
The registrar public certificate as decoded by openssl's x509 The registrar public certificate as decoded by openssl's x509
utility. Note that the registrar certificate is marked with the utility. Note that the registrar certificate is marked with the
cmcRA extension. cmcRA extension.
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 3 (0x3) Serial Number: 3 (0x3)
Signature Algorithm: ecdsa-with-SHA384 Signature Algorithm: ecdsa-with-SHA384
Issuer: DC=ca, DC=sandelman, CN=Unstrung Fountain CA Issuer: DC = ca, DC = sandelman, CN = Unstrung Fount
ain CA
Validity Validity
Not Before: Sep 5 01:12:45 2017 GMT Not Before: Sep 5 01:12:45 2017 GMT
Not After : Sep 5 01:12:45 2019 GMT Not After : Sep 5 01:12:45 2019 GMT
Subject: DC=ca, DC=sandelman, CN=localhost Subject: DC = ca, DC = sandelman, CN = localhost
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7
8:17: 8:17:
34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5
3:3e: 3:3e:
03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e
9:ba: 9:ba:
13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2
f:96: f:96:
e9:9d:e2:bc:b2 e9:9d:e2:bc:b2
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Basic Constraints: X509v3 Basic Constraints:
CA:FALSE CA:FALSE
Signature Algorithm: ecdsa-with-SHA384 Signature Algorithm: ecdsa-with-SHA384
30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78: 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78:
5b: 5b:
9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e: 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e:
b6: b6:
9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21: 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21:
02: 02:
 End of changes. 46 change blocks. 
80 lines changed or deleted 101 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/