draft-ietf-anima-bootstrapping-keyinfra-06.txt   draft-ietf-anima-bootstrapping-keyinfra-07.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: November 24, 2017 SSW Expires: January 4, 2018 SSW
M. Behringer M. Behringer
S. Bjarnason S. Bjarnason
Cisco Cisco
K. Watsen K. Watsen
Juniper Networks Juniper Networks
May 23, 2017 July 3, 2017
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-06 draft-ietf-anima-bootstrapping-keyinfra-07
Abstract Abstract
This document specifies automated bootstrapping of a remote secure This document specifies automated bootstrapping of a remote secure
key infrastructure (BRSKI) using vendor installed X.509 certificate, key infrastructure (BRSKI) using vendor installed X.509 certificate,
in combination with a vendor's authorizing service, both online the in combination with a vendor's authorizing service, both online and
Internet, and offline. Bootstrapping a new device can occur using a offline. Bootstrapping a new device can occur using a routable
routable address and a cloud service, or using only link-local address and a cloud service, or using only link-local connectivity,
connectivity, or on limited/disconnected networks. Support for lower or on limited/disconnected networks. Support for lower security
security models, including devices with minimal identity, is models, including devices with minimal identity, is described for
described for legacy reasons but not encouraged. Bootstrapping is legacy reasons but not encouraged. Bootstrapping is complete when
complete when the cryptographic identity of the new key the cryptographic identity of the new key infrastructure is
infrastructure is successfully deployed to the device but the successfully deployed to the device but the established secure
established secure connection can be used to deploy a locally issued connection can be used to deploy a locally issued certificate to the
certificate to the device as well. 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 November 24, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Other Bootstrapping Approaches . . . . . . . . . . . . . 4 1.1. Other Bootstrapping Approaches . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 7 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 7
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 9 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 9
2.1. Secure Imprinting using Vouchers . . . . . . . . . . . . 10 2.1. Secure Imprinting using Vouchers . . . . . . . . . . . . 10
2.2. Initial Device Identifier . . . . . . . . . . . . . . . . 10 2.2. Initial Device Identifier . . . . . . . . . . . . . . . . 10
2.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Lack of realtime clock . . . . . . . . . . . . . . . . . 13 2.4. Lack of realtime clock . . . . . . . . . . . . . . . . . 14
2.5. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 14 2.5. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 15
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 14 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 17 3.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 18
3.1.2. Registrar Discovery Protocol Details . . . . . . . . 17 3.1.2. Registrar Discovery Protocol Details . . . . . . . . 18
3.2. Request Voucher from the Registrar . . . . . . . . . . . 18 3.2. Request Voucher from the Registrar . . . . . . . . . . . 19
3.3. Request Voucher from MASA . . . . . . . . . . . . . . . . 20 3.3. Request Voucher from MASA . . . . . . . . . . . . . . . . 20
3.4. Voucher Response . . . . . . . . . . . . . . . . . . . . 21 3.4. Voucher Response . . . . . . . . . . . . . . . . . . . . 23
3.4.1. Completing authentication of Provisional TLS 3.4.1. Completing authentication of Provisional TLS
connection . . . . . . . . . . . . . . . . . . . . . 22 connection . . . . . . . . . . . . . . . . . . . . . 24
3.5. Voucher Status Telemetry . . . . . . . . . . . . . . . . 23 3.5. Voucher Status Telemetry . . . . . . . . . . . . . . . . 25
3.6. MASA authorization log Request . . . . . . . . . . . . . 24 3.6. MASA authorization log Request . . . . . . . . . . . . . 26
3.7. MASA authorization log Response . . . . . . . . . . . . . 24 3.7. MASA authorization log Response . . . . . . . . . . . . . 26
3.8. EST Integration for PKI bootstrapping . . . . . . . . . . 26 3.8. EST Integration for PKI bootstrapping . . . . . . . . . . 27
3.8.1. EST Distribution of CA Certificates . . . . . . . . . 26 3.8.1. EST Distribution of CA Certificates . . . . . . . . . 28
3.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 27 3.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 28
3.8.3. EST Client Certificate Request . . . . . . . . . . . 27 3.8.3. EST Client Certificate Request . . . . . . . . . . . 29
3.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 27 3.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 29
3.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 29 3.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 30
4. Reduced security operational modes . . . . . . . . . . . . . 29 4. Reduced security operational modes . . . . . . . . . . . . . 30
4.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 29 4.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 30
4.2. New Entity security reductions . . . . . . . . . . . . . 30 4.2. Pledge security reductions . . . . . . . . . . . . . . . 31
4.3. Registrar security reductions . . . . . . . . . . . . . . 30 4.3. Registrar security reductions . . . . . . . . . . . . . . 32
4.4. MASA security reductions . . . . . . . . . . . . . . . . 31 4.4. MASA security reductions . . . . . . . . . . . . . . . . 33
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
5.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 32 5.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 34
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Normative References . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . 36
8.2. Informative References . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 37 Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 39
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 37 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 39
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 37 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 39
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 37 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 39
Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 38 Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 40
C.1. Multiple Join networks on the Join Proxy side . . . . . . 39 C.1. Multiple Join networks on the Join Proxy side . . . . . . 41
C.2. Automatic configuration of tunnels on Registrar . . . . . 39 C.2. Automatic configuration of tunnels on Registrar . . . . . 41
C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 39 C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 42
C.4. Use of connected sockets; or IP_PKTINFO for CoAP on C.4. Use of connected sockets; or IP_PKTINFO for CoAP on
Registrar . . . . . . . . . . . . . . . . . . . . . . . . 40 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 42
C.5. Use of socket extension rather than virtual interface . . 40 C.5. Use of socket extension rather than virtual interface . . 42
Appendix D. To be deprecated: Consolidation remnants . . . . . . 40 Appendix D. To be deprecated: Consolidation remnants . . . . . . 43
D.1. Functional Overview . . . . . . . . . . . . . . . . . . . 41 D.1. Functional Overview . . . . . . . . . . . . . . . . . . . 43
D.1.1. Behavior of a Pledge . . . . . . . . . . . . . . . . 44 D.1.1. Behavior of a Pledge . . . . . . . . . . . . . . . . 46
D.1.2. Behavior of a Join Proxy . . . . . . . . . . . . . . 50 D.1.2. Behavior of a Join Proxy . . . . . . . . . . . . . . 52
D.1.3. Behavior of the Registrar . . . . . . . . . . . . . . 51 D.1.3. Behavior of the Registrar . . . . . . . . . . . . . . 53
D.1.4. Behavior of the MASA Service . . . . . . . . . . . . 55 D.1.4. Behavior of the MASA Service . . . . . . . . . . . . 57
D.1.5. Leveraging the new key infrastructure / next steps . 56 D.1.5. Leveraging the new key infrastructure / next steps . 58
D.1.6. Interactions with Network Access Control . . . . . . 56 D.1.6. Interactions with Network Access Control . . . . . . 58
D.2. Domain Operator Activities . . . . . . . . . . . . . . . 56 D.2. Domain Operator Activities . . . . . . . . . . . . . . . 58
D.2.1. Instantiating the Domain Certification Authority . . 57 D.2.1. Instantiating the Domain Certification Authority . . 59
D.2.2. Instantiating the Registrar . . . . . . . . . . . . . 57 D.2.2. Instantiating the Registrar . . . . . . . . . . . . . 59
D.2.3. Accepting New Entities . . . . . . . . . . . . . . . 57 D.2.3. Accepting New Entities . . . . . . . . . . . . . . . 59
D.2.4. Automatic Enrollment of Devices . . . . . . . . . . . 58 D.2.4. Automatic Enrollment of Devices . . . . . . . . . . . 60
D.2.5. Secure Network Operations . . . . . . . . . . . . . . 58 D.2.5. Secure Network Operations . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction 1. Introduction
BRSKI provides a foundation to securely answer the following BRSKI provides a foundation to securely answer the following
questions between an element of the network domain called the questions between an element of the network domain called the
"Registrar" and an unconfigured and untouched device called a "Registrar" and an unconfigured and untouched device called a
"Pledge": "Pledge":
o Registrar authenticating the Pledge: "Who is this device? What is o Registrar authenticating the Pledge: "Who is this device? What is
its identity?" its identity?"
skipping to change at page 5, line 29 skipping to change at page 5, line 29
Pledge. This creates serveral problems and limitations: Pledge. This creates serveral problems and limitations:
o the pledge requires realtime connectivity to the vendor service, o the pledge requires realtime connectivity to the vendor service,
o the domain identity is exposed to the vendor service (this is a o the domain identity is exposed to the vendor service (this is a
privacy concern), privacy concern),
o the vendor is responsible for making the authorization decisions o the vendor is responsible for making the authorization decisions
(this is a liability concern), (this is a liability concern),
BRSKI addresses these issues by defining "voucher" and automation BRSKI addresses these issues by defining extensions to the EST
extensions to the EST protocol. protocol for the automated distribution of vouchers.
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 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The following terms are defined for clarity: The following terms are defined for clarity:
skipping to change at page 8, line 36 skipping to change at page 8, line 36
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
non-energy constrained, but challenged network (such as 802.15.4). non-energy constrained, but challenged network (such as 802.15.4).
The certificate contents, and the process by which the four questions The certificate contents, and the process by which the four questions
above are resolved do apply to constained devices. It is simply the above are resolved do apply to constrained devices. It is simply the
actual on-the-wire imprint protocol which could be inappropriate. actual on-the-wire imprint protocol which could be inappropriate.
This document presumes that network access control has either already This document presumes that network access control has either already
occurred, is not required, or is integrated by the proxy and occurred, is not required, or is integrated by the proxy and
registrar in such a way that the device itself does not need to be registrar in such a way that the device itself does not need to be
aware of the details. Although the use of an X.509 Initial Device aware of the details. Although the use of an X.509 Initial Device
Identity is consistant with IEEE 802.1AR [IDevID], and allows for Identity is consistant with IEEE 802.1AR [IDevID], and allows for
alignment with 802.1X network access control methods, its use here is alignment with 802.1X network access control methods, its use here is
for Pledge authentication rather than network access control. for Pledge authentication rather than network access control.
Integrating this protocol with network access control, perhaps as an Integrating this protocol with network access control, perhaps as an
skipping to change at page 9, line 31 skipping to change at page 9, line 31
| .............. ^ | .............. ^
V | V |
+-------+ ............................................|... +-------+ ............................................|...
| | . | . | | . | .
| | . +------------+ +-----------+ | . | | . +------------+ +-----------+ | .
| | . | | | | | . | | . | | | | | .
|Pledge | . | Circuit | | Domain <-------+ . |Pledge | . | Circuit | | Domain <-------+ .
| | . | Proxy | | Registrar | . | | . | Proxy | | Registrar | .
| <--------> <-------> | . | <--------> <-------> | .
| | . | | | | . | | . | | | | .
| | . +------------+ +-----+-----+ . |X.509 | . +------------+ +-----+-----+ .
|IDevID | . | . |IDevID | . | .
| | . +-----------------+----------+ . | | . +-----------------+----------+ .
| | . | Key Infrastructure | . | | . | Key Infrastructure | .
| | . | (e.g. PKI Certificate | . | | . | (e.g. PKI Certificate | .
+-------+ . | Authority) | . +-------+ . | Authority) | .
. +----------------------------+ . . +----------------------------+ .
. . . .
................................................ ................................................
"Domain" components "Domain" components
skipping to change at page 10, line 33 skipping to change at page 10, line 33
lowest security levels the MASA server can indiscriminately issue lowest security levels the MASA server can indiscriminately issue
vouchers. At the highest security levels issuance of vouchers can be vouchers. At the highest security levels issuance of vouchers can be
integrated with complex sales channel integrations that are beyond integrated with complex sales channel integrations that are beyond
the scope of this document. This provides the flexibility for a the scope of this document. This provides the flexibility for a
number of use cases via a single common protocol mechanism on the number of use cases via a single common protocol mechanism on the
Pledge and Registrar devices that are to be widely deployed in the Pledge and Registrar devices that are to be widely deployed in the
field. The MASA vendor services have the flexibility to leverage field. The MASA vendor services have the flexibility to leverage
either the currently defined claim mechanisms or to experiment with either the currently defined claim mechanisms or to experiment with
higher or lower security levels. higher or lower security levels.
Vouchers provide a signed but non-encrypted communication channel
between the Pledge, the MASA, and the Registrar. The Registrar
maintains control over the transport and policy decisions allowing
the local security policy of the domain network to be enforced.
2.2. Initial Device Identifier 2.2. Initial Device Identifier
Pledge authentication is via an X.509 certificate installed during Pledge authentication is via an X.509 certificate installed during
the manufacturing process. This Initial Device Identifier provides a the manufacturing process. This Initial Device Identifier provides a
basis for authenticating the Pledge during subsequent protocol basis for authenticating the Pledge during subsequent protocol
exchanges and informing the Registrar of the MASA URI. There is no exchanges and informing the Registrar of the MASA URI. There is no
requirement for a common root PKI hierarchy. Each device vendor can requirement for a common root PKI hierarchy. Each device vendor can
generate their own root certificate. generate their own root certificate.
The following previously defined fields are in the X.509 IDevID The following previously defined fields are in the X.509 IDevID
certificate: certificate:
o The subject field's DN encoding MUST include the "serialNumber" o The subject field's DN encoding MUST include the "serialNumber"
attribute with the device's unique serial number. attribute with the device's unique serial number.
o The subject-alt field's encoding SHOULD include a non-critical o The subject-alt field's encoding SHOULD include a non-critical
version of the RFC4108 defined HardwareModuleName. version of the RFC4108 defined HardwareModuleName.
In order to build the voucher "serial-number" field these IDevID
fields need to be converted into a serial-number of "type string".
The following methods is used depending on the first available IDevID
certificate field (attempted in this order):
o An RFC4514 String Representation of the Distinguished Name
"serialNumber" attribute.
o The HardwareModuleName hwSerialNum OCTET STRING base64 encoded.
o The RFC4514 String Representation of the Distinguished Name
"common name" attribute.
The following newly defined field SHOULD be in the X.509 IDevID The following newly defined field SHOULD be in the X.509 IDevID
certificate: An X.509 non-critical certificate extension that certificate: An X.509 non-critical certificate extension that
contains a single Uniform Resource Identifier (URI) that points to an contains a single Uniform Resource Identifier (URI) that points to an
on-line Manufacturer Authorized Signing Authority. The URI is on-line Manufacturer Authorized Signing Authority. The URI is
represented as described in Section 7.4 of [RFC5280]. represented as described in Section 7.4 of [RFC5280].
Any Internationalized Resource Identifiers (IRIs) MUST be mapped to Any Internationalized Resource Identifiers (IRIs) MUST be mapped to
URIs as specified in Section 3.1 of [RFC3987] before they are placed URIs as specified in Section 3.1 of [RFC3987] before they are placed
in the certificate extension. The URI provides the authority in the certificate extension. The URI provides the authority
information. The BRSKI .well-known tree is described in Section 3 information. The BRSKI .well-known tree is described in Section 3
skipping to change at page 16, line 32 skipping to change at page 17, line 21
The result of discovery is a logical communication with a Registrar, The result of discovery is a logical communication with a Registrar,
through a Proxy. The Proxy is transparent to the Pledge but is through a Proxy. The Proxy is transparent to the Pledge but is
always assumed to exist. always assumed to exist.
To discover the Registrar the Pledge performs the following actions: To discover the Registrar the Pledge performs the following actions:
a. MUST: Obtains a local address using IPv6 methods as described in a. MUST: Obtains a local address using IPv6 methods as described in
[RFC4862] IPv6 Stateless Address AutoConfiguration. [RFC7217] is [RFC4862] IPv6 Stateless Address AutoConfiguration. [RFC7217] is
encouraged. Pledges will generally prefer use of IPv6 Link-Local encouraged. Pledges will generally prefer use of IPv6 Link-Local
addresses, and discovery of Proxy will be by Link-Local addresses, and discovery of Proxy will be by Link-Local
mechanisms. [[EDNOTE: In some environments, a routable public mechanisms. IPv4 methods are described in Appendix A
address may be obtained, should it be? Should it be used?]] IPv4
methods are described in Appendix A
b. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) b. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp])
announcements of the objective: "ACP+Proxy". See section announcements of the objective: "ACP+Proxy". See section
Section 3.1.1 for the details of the the objective. The Pledge Section 3.1.1 for the details of the the objective. The Pledge
may listen concurrently for other sources of information, see may 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 3. Section 3.
skipping to change at page 18, line 45 skipping to change at page 19, line 30
TCP traffic. TCP traffic.
3.2. Request Voucher from the Registrar 3.2. Request 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
"/requestvoucher". "/requestvoucher".
The request is itself a voucher [I-D.ietf-anima-voucher]. The Pledge The request media types are:
populates the voucher fields as follows:
assertion: The voucher request MUST contain an assertion of application/voucherrequest The request is a "YANG-defined JSON
"proximity". [[EDNOTE: this is a placeholder as this commit is document that has been signed using a PKCS#7 structure" as
not the correct place to expand this list. Using proximity and described in [I-D.ietf-anima-voucher] using the JSON encoded
channel binding: if both the Pledge and the Registrar sign the described in [RFC7951]. Signing the request is RECOMMENDED if the
channel binding statement then these provide vital proximity Pledge has sufficient processing to perform the crypto operations.
information to the MASA. To be expanded on in a future commit.]] Doing so allows the Registrar to forward the Pledge's signed
'proximity' assertion to the MASA as discussed in the security
considerations.
application/unsignedvoucherrequest The request is the "YANG-defined
JSON document" but has not been signed. It is the inner JSON
structure protected only by the TLS client authentication. This
reduces the cryptographic requirements on the Pledge.
For simplicity the term 'voucher request' is used to refer to either
of these media types. Registrar impementations SHOULD anticipate
future media types but of course will simply fail the request if
those types are not yet known.
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. This provides additional information to the populate this field. This provides additional information to the
MASA. MASA.
nonce: The voucher request MUST contain a cryptographically strong nonce: The voucher request MUST contain a cryptographically strong
random or pseudo-random number nonce. Doing so ensures random or pseudo-random number nonce. Doing so ensures
Section 2.4 functionality. The nonce MUST NOT be reused for Section 2.4 functionality. The nonce MUST NOT be reused for
multiple bootstrapping attempts. multiple bootstrapping attempts.
All other fields MAY be ommitted in a voucher request. [[EDNOTE: An assertion: The voucher request MAY contain an assertion of
issue has been created for the voucher document to ensure normative "proximity".
language supports this]]
Signing the request is RECOMMENDED if the Pledge has sufficient pinned-domain-cert: In a Pledge voucher request this is the
processing to perform the crypto operations. Doing so allows the Registrar certificate as extracted from the TLS handshake (for
Registrar and MASA to confirm the "proximity" assertion of the example the first certificate in the TLS 'certificate_list'
Pledge. sequence (see [RFC5246]). This MUST be populated in a Pledge's
voucher request if the "proximity" assertion is populated.
Request media type: application/voucherrequest All other fields MAY be ommitted in the voucher request.
An example JWS payload of the voucher request: An example JSON payload of a voucher request from a Pledge:
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:00.000Z", "created-on": "2017-01-01T00:00:00.000Z",
"assertion": "proximity" "assertion": "proximity",
"pinned-domain-cert": "<base64 encoded certificate>"
} }
} }
[[EDNOTE: The move to JWT allows for relatively simple signing
operations. One possibility here is to carry the original signed JWT
as an optional part of the payload sent to the MASA (e.g. "original
request"). this would be a BRSKI addition to the voucher?]]
The Registrar validates the client identity as described in EST The Registrar validates the client identity as described in EST
[RFC7030] section 3.3.2. The registrar performs authorization as [RFC7030] section 3.3.2. If the request is signed the Registrar
detailed in Section 3.3.2. If authorization is successful the confirms the 'proximity' asserion and associated 'pinned-domain-cert'
Registrar obtains an Voucher from the MASA service (see Section 3.3). are correct. The registrar performs authorization as detailed in
[[EDNOTE: UNRESOLVED. See Appendix D "Pledge Authorization"]]. If
these validations fail the Registrar SHOULD respond with an
appropriate HTTP error code.
The received voucher request is forwarded to the Pledge. If authorization is successful the Registrar obtains a voucher from
the MASA service (see Section 3.3) and returns that MASA signed
voucher to the pledge as described in Section 3.4.
3.3. Request Voucher from MASA 3.3. Request Voucher from MASA
A Registrar requests a Voucher from the MASA service using a REST when a Registrar recieves a voucher request from a Pledge it in turn
interface. For simplicity this is defined as an optional EST message requests a voucher from the MASA service. For simplicity this is
between a Registrar and an EST server running on the MASA service defined as an optional EST message between a Registrar and an EST
although the Registrar is not required to make use of any other EST server running on the MASA service although the Registrar is not
functionality when communicating with the MASA service. (The MASA required to make use of any other EST functionality when
service MUST properly reject any EST functionality requests it does communicating with the MASA service. (The MASA service MUST properly
not wish to service; a requirement that holds for any REST reject any EST functionality requests it does not wish to service; a
interface). requirement that holds for any REST interface).
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
"/requestvoucher". "/requestvoucher".
Request media type: application/voucherrequest+cms The request media type is:
The request format is a JSON object optionally containing the nonce application/voucherrequest The request is a "YANG-defined JSON
value (as obtained from the bootstrap request) and the X.509 IDevID document that has been signed using a PKCS#7 structure" as
extracted serial number (the full certificate is not needed and no described in [I-D.ietf-anima-voucher] using the JSON encoded
proof-of-possession information for the device identity is included). described in [RFC7951]. The Registrar MUST sign the request. The
The AuthorityKeyIdentifier value from the certificate is included to entire Registrar certificate chain, up to and including the Domain
ensure a statistically unique identity. The Pledge's serial number CA, MUST be included in the PKCS#7 structure.
is extracted from the X.509 IDevID. See Section 2.2.
For simplicity the term 'voucher request' is used. MASA
impementations SHOULD anticipate future media types but of course
will simply fail the request if those types are not yet known.
The Registrar populates the voucher request fields as follows:
created-on: Registrars are RECOMMENDED to populate this field. This
provides additional information to the MASA.
nonce: The optional nonce value from the Pledge request if desired
(see below).
serial-number: The serial number of the Pledge the Registrar would
like a voucher for.
idevid-issuer: The idevid-issuer value from the pledge certificate
is included to ensure a statistically unique identity. The
Pledge's serial number is extracted from the X.509 IDevID. See
Section 2.2.
prior-signed-voucher: If the Pledge provided a signed voucher
request then it SHOULD be included in the voucher request built by
the Registrar.
All other fields MAY be ommitted in the voucher request.
An example JSON payload of a voucher request from a Registrar:
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:00.000Z", "created-on": "2017-01-01T00:00:00.000Z",
"assertion": "proximity" "assertion": "proximity"
"device-identifier-aki": "[[EDNOTE:authority key identifier field "idevid-issuer": "<base64 encoded Authority Key Identifier>"
from the IDevID. Voucher draft text that device-identifier is "A "serial-number": "JADA123456789"
unique identifier (e.g., serial number) within the scope of the "prior-signed-voucher": "<base64 encode prior voucher request>"
MASA" is insufficient because it prevents vendors from sharing
a MASA]]"
"device-identifier": "JADA123456789"
} }
} }
A Registrar MAY exclude the nonce from the request. Doing so allows A Registrar MAY exclude the nonce from the voucher request it submits
the Registrar to request a Voucher when the Pledge is not online, or to the MASA. Doing so allows the Registrar to request a Voucher when
when the target bootstrapping environment is not on the same network the Pledge is offline, or when the Registrar is expected to be
as the MASA server (this requires the Registrar to learn the offline when the Pledge is being deployed. These use cases require
appropriate DevIDSerialNumber field from the physical device labeling the Registrar to learn the appropriate IDevID SerialNumber field from
or from the sales channel -- how this occurs is out-of-scope of this the physical device labeling or from the sales channel (out-of-scope
document). If a nonce is not provided the MASA server MUST of this document). If a nonce is not provided the MASA server MUST
authenticate the Registrar as described in EST [RFC7030] section authenticate the Registrar as described in EST [RFC7030] section
3.3.2 to reduce the risk of DDoS attacks. The MASA performs 3.3.2 to reduce the risk of DDoS attacks and to provide an
authorization as detailed in Appendix D.1.3.2. authenticated identity as an input to sales channel integration and
authorizations (also out-of-scope of this document).
As described in [I-D.ietf-anima-voucher] vouchers are normally short The MASA verifies that the voucher request is internally consistent
lived to avoid revocation issues. If the request is for a previous but does not authenticate the domain identity information since the
(expired) voucher using the same Registrar (as determined by domain is not know to the MASA server in advance. The MASA
Registrar's' domainID) and the MASA has not been informed that the validation checks before issuing a voucher are as follows:
claim is invalid - the request for a renewed voucher SHOULD be
automatically authorized. If authorization is successful the MASA
responds with a [I-D.ietf-anima-voucher] voucher. The MASA SHOULD
check for revocation of the Registrar certificate. The maximum
lifetime of the voucher issued SHOULD NOT exceed the lifetime of the
Registrar's revocation validation (for example if the Registrar
revocation status is indicated in a CRL that is valid for two weeks
then that is an appropriate lifetime for the voucher).
The voucher request is signed by the Registrar as indicated in Renew for expired voucher: As described in [I-D.ietf-anima-voucher]
[I-D.ietf-anima-voucher] voucher. The entire certificate chain, up vouchers are normally short lived to avoid revocation issues. If
to and including the Domain CA, MUST be included. The MASA service the request is for a previous (expired) voucher using the same
checks the internal consistency of the voucher request but does not Registrar (as determined by the Registrar pinned-domain-cert) and
authenticate the domain identity information since the domain is not the MASA has not been informed that the claim is invalid then the
know to the MASA server in advance. The MASA server MUST verify that request for a renewed voucher SHOULD be automatically authorized.
the voucher request is signed by a Registrar certificate (by checking
for the cmc-idRA field) that was issued by the self signed root
certificate included in the request. [[ EDNOTE: can we simplify the
above sentence? ]] This ensures that the Registrar making the claim
is an authorized Registrar of the unauthenticated domain.
The root certificate is extracted and used to populate the Voucher. Voucher signature consistency: The MASA MUST verify that the voucher
request is signed by a Registrar. This is confirmed by verifying
that the id-kp-cmcRA extended key usage extension field (as
detailed in EST RFC7030 section 3.6.1) exists in the certificate
of the entity that signed the voucher request. This verification
is only a consistency check that the unauthenticated domain CA
intended this to be a Registrar. Performing this check provides
value to domain PKI by assuring the domain administrator that the
MASA service will only respect claims from authorized Registration
Authorities of the domain. (The requirement for the Registrar to
include the Domain CA certificate in the signature structure was
stated above).
Registrar revocation consistency: The MASA SHOULD check for
revocation of the Registrar certificate. The maximum lifetime of
the voucher issued SHOULD NOT exceed the lifetime of the
Registrar's revocation validation (for example if the Registrar
revocation status is indicated in a CRL that is valid for two
weeks then that is an appropriate lifetime for the voucher).
Because the Registar certificate authority is unknown to the MASA
in advance this is only an extended consistency check and is not
required. The maximum lifetime of the voucher issued SHOULD NOT
exceed the lifetime of the Registrar's revocation validation (for
example if the Registrar revocation status is indicated in a CRL
that is valid for two weeks then that is an appropriate lifetime
for the voucher).
Pledge proximity assertion: The MASA server MAY verify that the
Registrar signed voucher includes the 'prior-signed-voucher' field
populated with a Pledge signed voucher that includes a pinned-
domain-cert that is consistent with the Registrar certificate
chain. The MASA server is aware of which Pledge's support signing
of their voucher requests and can use this information to confirm
proximity of the Pledge with the Registrar.
The root certificate is extracted from the signature method and used
to populate the "pinned-domain-cert" of the Voucher being issued.
The domain ID (e.g. hash of the public key of the domain) is The domain ID (e.g. hash of the public key of the domain) is
extracted from the root certificate and is used to update the audit extracted from the root certificate and is used to update the audit
log. log.
3.4. Voucher Response 3.4. Voucher Response
The voucher response to requests from the device and requests from a The voucher response to requests from the Pledge and requests from a
Registrar are in the same format. A Registrar either caches prior Registrar are in the same format. A Registrar either caches prior
MASA responses or dynamically requests a new Voucher based on local MASA responses or dynamically requests a new Voucher based on local
policy. policy.
If the the join operation is successful, the server response MUST If the the join operation is successful, the server response MUST
contain an HTTP 200 response code. The server MUST answer with a contain an HTTP 200 response code. The server MUST answer with a
suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs.
The response data from the MASA server MUST be a plaintext human- The response data from the MASA server MUST be a plaintext human-
readable (ASCII, english) error message containing explanatory readable (ASCII, english) error message containing explanatory
information describing why the request was rejected. information describing why the request was rejected.
Response media type: application/voucher+cms Response media type: application/voucher+cms
The syntactic details of vouchers are described in detail in The syntactic details of vouchers are described in detail in
[I-D.ietf-anima-voucher]. For example, the voucher consists of: [I-D.ietf-anima-voucher]. For example, the voucher consists of:
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"assertion": "logging" "assertion": "logging"
"trusted-ca-certificate": "<base64 encoded certificate>" "pinned-domain-cert": "<base64 encoded certificate>"
"device-identifier": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
The Pledge verifies the signed voucher using the manufacturer The Pledge verifies the signed voucher using the manufacturer
installed trust anchor associated with the vendor's selected installed trust anchor associated with the vendor's selected
Manufacturer Authorized Signing Authority. Manufacturer Authorized Signing Authority.
The 'trusted-ca-certificate' element of the voucher contains the The 'pinned-domain-cert' element of the voucher contains the domain
domain CA's public key. This is useful for bootstrapping a public CA's public key. The Pledge MUST use the 'pinned-domain-cert' trust
key infrastructure but to support bootstrapping other key anchor to immediately complete authentication of the provisional TLS
infrastructures additional domain identity types might be defined in
the future.
The pledge's EST clients MUST be prepared to ignore additional fields
they do not recognize.
the pledge MUST be prepared to parse and fail gracefully from an
Voucher response that does not contain a 'trusted-ca-certificate'
field at all.
The Pledge MUST use the 'trusted-ca-certificate' trust anchor to
immediately complete authentication of the provisional TLS
connection. connection.
The Pledge MUST be prepared to parse and fail gracefully from an
Voucher response that does not contain a 'pinned-domain-cert' field.
The Pledge MUST be prepared to ignore additional fields it does not
recognize.
3.4.1. Completing authentication of Provisional TLS connection 3.4.1. Completing authentication of Provisional TLS connection
If a Registrar's credentials can not be verified using the trusted- If a Registrar's credentials can not be verified using the pinned-
ca-certificate trust anchor from the voucher then the TLS connection domain-cert trust anchor from the voucher then the TLS connection is
is immediately discarded and the Pledge abandons attempts to immediately discarded and the Pledge abandons attempts to bootstrap
bootstrap with this discovered registrar. The pledge SHOULD send with this discovered registrar. The pledge SHOULD send voucher
voucher status telemetry (described below) before closing the TLS status telemetry (described below) before closing the TLS connection.
connection. The pledge MUST attempt to enroll using any other The pledge MUST attempt to enroll using any other proxies it has
proxies it has found. It SHOULD return to the same proxy again after found. It SHOULD return to the same proxy again after attempting
attempting with other proxies. Attempts should be attempted in the with other proxies. Attempts should be attempted in the exponential
exponential backoff described earlier. Attempts SHOULD be repeated backoff described earlier. Attempts SHOULD be repeated as failure
as failure may be the result of a temporary inconsistently (an may be the result of a temporary inconsistently (an inconsistently
inconsistently rolled Registrar key, or some other mis- rolled Registrar key, or some other mis-configuration). The
configuration). The inconsistently could also be the result an inconsistently could also be the result an active MITM attack on the
active MITM attack on the EST connection. EST connection.
To ensure that the trusted-ca-certificate provide chain is able to The Registrar MUST use a certificate that chains to the pinned-
verify, the Registrar MUST use a certificate that chains to the domain-cert as its TLS server certificate.
trusted-ca-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.4. Beyond validity period information is as described in Section 2.4. Once the
that once PKIX path validation is successful the TLS connection is no PKIX path validation is successful the TLS connection is no longer
longer provisional. provisional.
The trusted-ca-certificate is installed as an Explicit Trust Anchor The pinned-domain-cert is installed as an Explicit Trust Anchor for
for future operations. It can therefore can be used to authenticate future operations. It can therefore can be used to authenticate any
any dynamically discovered EST server that contain the id-kp-cmcRA dynamically discovered EST server that contain the id-kp-cmcRA
extended key usage extension as detailed in EST RFC7030 section extended key usage extension as detailed in EST RFC7030 section
3.6.1; but to reduce system complexity the Pledge SHOULD avoid 3.6.1; but to reduce system complexity the Pledge SHOULD avoid
additional discovery operations. Instead the Pledge SHOULD additional discovery operations. Instead the Pledge SHOULD
communicate directly with the Registrar as the EST server for future communicate directly with the Registrar as the EST server. The '
key management operations. The 'trusted-ca-certificate' is not a pinned-domain-cert' is not a complete distribution of the EST section
complete distribution of the EST section 4.1.3 CA Certificate 4.1.3 CA Certificate Response which is an additional justification
Response which is an additional justification for the recommendation for the recommendation to proceed with EST key management operations.
to proceed with EST key management operations. Once a full CA Certificate Response is obtained it is more
authoritative for the domain than the limited 'pinned-domain-cert'
response.'
3.5. Voucher Status Telemetry 3.5. Voucher Status Telemetry
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 client SHOULD To indicate Pledge status regarding the Voucher the client SHOULD
post a status message. post a status message.
skipping to change at page 23, line 48 skipping to change at page 25, line 41
known URI /voucher_status. The Status field indicates if the Voucher known URI /voucher_status. The Status field indicates if the Voucher
was acceptable. If it was not acceptable the Reason string indicates was acceptable. If it was not acceptable the Reason string indicates
why. In the failure case this message is being sent to an why. In the failure case this message is being sent to an
unauthenticated, potentially malicious Registrar and therefore the unauthenticated, potentially malicious Registrar and therefore the
Reason string SHOULD NOT provide information beneficial to an Reason string SHOULD NOT provide information beneficial to an
attacker. The operational benefit of this telemetry information is attacker. The operational benefit of this telemetry information is
balanced against the operational costs of not recording that an balanced against the operational costs of not recording that an
Voucher was ignored by a client the registar expected to continue Voucher was ignored by a client the registar expected to continue
joining the domain. joining the domain.
[[EDNOTE: the server can know which pledge failed by the previous
voucher, I think. Is this worth noting?]]
{ {
"version":"1", "version":"1",
"Status":FALSE /* TRUE=Success, FALSE=Fail" "Status":FALSE /* TRUE=Success, FALSE=Fail"
"Reason":"Informative human readable message" "Reason":"Informative human readable message"
} }
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.
3.6. MASA authorization log Request 3.6. MASA authorization log Request
A registrar requests the MASA authorization log from the MASA service A registrar requests the MASA authorization log from the MASA service
using this EST extension. If a device had previously registered with using this EST extension. If a device had previously registered with
another domain, a Registrar of that domain would show in the log. another domain, a Registrar of that domain would show in the log.
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
"/requestauditlog". "/requestauditlog".
The client MUST HTTP POSTs the same Voucher Request as for requesting The registrar MUST HTTP POSTs the same Voucher Request as when
a Voucher. It is posted to the /requestauditlog URI instead. The requesting a Voucher. It is posted to the /requestauditlog URI
IDevIDAuthorityKeyIdentifier and DevIDSerialNumber informs the MASA instead. The "idevid-issuer" and "serial-number" informs the MASA
server which log is requested so the appropriate log can be prepared server which log is requested so the appropriate log can be prepared
for the response. Using the same media type and message minimizes for the response. Using the same media type and message minimizes
cryptographic and message operations although it results in cryptographic and message operations although it results in
additional network traffic. The relying MASA server implementation additional network traffic. The relying MASA server implementation
MAY leverage internal state to associate this request with the MAY leverage internal state to associate this request with the
original, and by now already validated, voucher request so as to original, and by now already validated, voucher request so as to
avoid an extra crypto validation. avoid an extra crypto validation.
Request media type: application/voucherrequest+cms Request media type: application/voucherrequest+cms
skipping to change at page 25, line 35 skipping to change at page 27, line 13
MAY be condensed into the single most recent nonceless entry. MAY be condensed into the single most recent nonceless entry.
A Registrar SHOULD use this log information to make an informed A Registrar SHOULD use this log information to make an informed
decision regarding the continued bootstrapping of the Pledge. For decision regarding the continued bootstrapping of the Pledge. For
example if the log includes unexpected domainIDs this is indicative example if the log includes unexpected domainIDs this is indicative
of problematic imprints by the Pledge. If the log includes nonce- of problematic imprints by the Pledge. If the log includes nonce-
less entries this is indicative of the permanent ability for the less entries this is indicative of the permanent ability for the
indicated domain to trigger a reset of the device and take over indicated domain to trigger a reset of the device and take over
management of it. Equipment that is purchased pre-owned can be management of it. Equipment that is purchased pre-owned can be
expected to have an extensive history. A Registrar MAY request logs expected to have an extensive history. A Registrar MAY request logs
at future times [[EDNOTE: we need to ensure MASA server is not at future times. A Registrar MAY be configured to ignore the history
slammed with too many requests]]. A Registrar MAY be configured to of the device but it is RECOMMENDED that this only be configured if
ignore the history of the device but it is RECOMMENDED that this only hardware assisted NEA [RFC5209] is supported.
be configured if hardware assisted NEA [RFC5209] is supported.
Log entries containing the Domain's ID can be compared against local Log entries containing the Domain's ID can be compared against local
history logs in search of discrepancies. history logs in search of discrepancies.
This document specifies a simple log format as provided by the MASA This document specifies a simple log format as provided by the MASA
service to the registar. This format could be improved by service to the registar. This format could be improved by
distributed consensus technologies that integrate vouchers with a distributed consensus technologies that integrate vouchers with a
technologies such as block-chain or hash trees or the like. Doing so technologies such as block-chain or hash trees or the like. Doing so
is out of the scope of this document but are anticipated improvements is out of the scope of this document but are anticipated improvements
for future work. As such, the Registrar client SHOULD anticipate new for future work. As such, the Registrar client SHOULD anticipate new
kinds of responses, and SHOULD provide operator controls to indicate kinds of responses, and SHOULD provide operator controls to indicate
how to process unknown responses. how to process unknown responses.
3.8. EST Integration for PKI bootstrapping 3.8. EST Integration for PKI bootstrapping
This section describes EST extensions necessary to enable fully This section describes EST extensions necessary to enable fully
automated bootstrapping. Although the Voucher request/response automated bootstrapping. Although the Voucher request/response
structure members IDevIDAuthorityKeyIdentifier and DevIDSerialNumber structure members "idevid-issuer" and "pinned-domain-cert" are
are specific to PKI bootstrapping these are the only PKI specific specific to PKI bootstrapping these are the only PKI specific aspects
aspects of the extensions and future work might replace them with of the extensions and future voucher definitions might replace them
non-PKI structures. with non-PKI fields.
Once the Voucher is received, as specified in this document, the Once the Voucher is received, as specified in this document, the
client has sufficient information to leverage the existing client has sufficient information to leverage the existing
communication channel with a Registrar to continue an EST RFC7030 communication channel with a Registrar to continue an EST RFC7030
enrollment. The Pledge SHOULD use the existing current TLS enrollment. The voucher provides an automated mechanism for the
connection to proceed with EST enrollment, thus reducing the total "Bootstrap Distribution of CA Certificates" described in [RFC7030]
amount of cryptographic and round trip operations required during section 4.1.1 wherein the Pledge "MUST [...]. engage a human user to
bootstrapping (enrollment picks up after EST RFC7030 "Bootstrap authorize the CA certificate using out-of-band" information".
Distribution of CA Certificates" and the client continues with EST Instead the Pledge now can automate this process using the voucher
enrollment operations including "CA Certificates Request", "CSR provided "pinned-domain-cert".
Attributes" and "Client Certificate Request" or "Server-Side Key
Generation"). The Pledge SHOULD use the existing current TLS connection to proceed
with EST enrollment, thus reducing the total amount of cryptographic
and round trip operations required during bootstrapping. After
voucher verification the Pledge continues with EST enrollment
operations including "CA Certificates Request", "CSR Attributes" and
"Client Certificate Request" or "Server-Side Key Generation" etc.
The Pledge is RECOMMENDED to implement the following EST automation The Pledge is RECOMMENDED to implement the following EST automation
extensions. They supplement the RFC7030 EST to better support extensions. They supplement the RFC7030 EST to better support
automated devices that do not have an end user. automated devices that do not have an end user.
[[EDNOTE:might be best to discuss in CSR attributes?]]For the
purposes of creating the ANIMA Autonomic Control Plane, the contents
of the new certificate MUST be carefully specified.
[I-D.ietf-anima-autonomic-control-plane] section 5.1.1 contains
details. The Registrar MUST provide the the correct ACP information
to populate the subjectAltName / rfc822Name field in the "CSR
Attributes" step.
3.8.1. EST Distribution of CA Certificates 3.8.1. EST Distribution of CA Certificates
The Pledge MUST request the full EST Distribution of CA Certificates The Pledge MUST request the full EST Distribution of CA Certificates
message. See RFC7030, section 4.1. 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 domainCAcert (see Section 3.4 for a certificates beyond the domainCAcert (see Section 3.4 for a
discussion of the limitations). Although these restrictions are discussion of the limitations). Although these restrictions are
acceptable for a Registrar integrated with initial bootstrapping they acceptable for a Registrar integrated with initial bootstrapping they
are not appropriate for ongoing PKIX end entity certificate are not appropriate for ongoing PKIX end entity certificate
skipping to change at page 27, line 16 skipping to change at page 28, line 34
Automated bootstrapping occurs without local administrative Automated bootstrapping occurs without local administrative
configuration of the Pledge. In some deployments its plausible that configuration of the Pledge. In some deployments its plausible that
the Pledge generates a certificate request containing only identity the Pledge generates a certificate request containing only identity
information known to the Pledge (essentially the X.509 IDevID information known to the Pledge (essentially the X.509 IDevID
information) and ultimately receives a certificate containing domain information) and ultimately receives a certificate containing domain
specific identity information. Conceptually the CA has complete specific identity information. Conceptually the CA has complete
control over all fields issued in the end entity certificate. control over all fields issued in the end entity certificate.
Realistically this is operationally difficult with the current status Realistically this is operationally difficult with the current status
of PKI certificate authority deployments where the CSR is submitted of PKI certificate authority deployments where the CSR is submitted
to the CA via a number of non-standard protocols. to the CA via a number of non-standard protocols. Even with all
standardized protocols used, it could operationally be problematic to
expect that service specific certificate fields can be created by a
CA that is likely operated by a group that has no insight into
different network services/protocols used. For example, the CA could
even be outsourced.
To alleviate operational difficulty the Pledge MUST request the EST To alleviate these operational difficulties, the Pledge MUST request
"CSR Attributes" from the EST server. This allows the local the EST "CSR Attributes" from the EST server and the EST server needs
infrastructure to inform the Pledge of the proper fields to include to be able to reply with the attributes necessary for use of the
in the generated CSR. certificate in its intended protocols/services. This approach allows
for minimal CA integrations and instead the local infrastructure (EST
server) informs the Pledge of the proper fields to include in the
generated CSR. This approach is beneficial to automated boostrapping
in the widest number of environments.
[[EDNOTE: The following is specific to anima purposes and should be If the hardwareModuleName in the X.509 IDevID is populated then it
moved to an appropriate anima document so as to keep bootstrapping as SHOULD by default be propagated to the LDevID along with the
generic as possible: What we want are a 'domain name' stored in [TBD] hwSerialNum. The EST server SHOULD support local policy concerning
and an 'ACP IPv6 address' stored in the iPAddress field as specified this functionality.
in RFC5208 s4.2.1.6. ref ACP draft where certificate verification
[TBD]. These should go into the subjectaltname in the [TBD] In networks using the BRSKI enrolled certificate to authenticate the
fields.]]. If the hardwareModuleName in the X.509 IDevID is ACP (Autonomic Control Plane), the EST attributes MUST include the
populated then it SHOULD by default be propagated to the LDevID along "ACP information" field. See
with the hwSerialNum. The registar SHOULD support local policy [I-D.ietf-anima-autonomic-control-plane] for more details.
concerning this functionality. [[EDNOTE: extensive use of EST CSR
Attributes might need an new OID definition]].]]
The Registar MUST also confirm the resulting CSR is formatted as The Registar MUST also confirm the resulting CSR is formatted as
indicated before forwarding the request to a CA. If the Registar is indicated before forwarding the request to a CA. If the Registar is
communicating with the CA using a protocol like full CMC which communicating with the CA using a protocol like full CMC which
provides mechanisms to override the CSR attributes, then these provides mechanisms to override the CSR attributes, then these
mechanisms MAY be used even if the client ignores CSR Attribute mechanisms MAY be used even if the client ignores CSR Attribute
guidance. guidance.
3.8.3. EST Client Certificate Request 3.8.3. EST Client Certificate Request
skipping to change at page 29, line 7 skipping to change at page 30, line 27
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.
This allows for clients that wish to minimize their crypto operations This allows for clients that wish to minimize their crypto operations
to simply POST this response without renegotiating the TLS session - to simply POST this response without renegotiating the TLS session -
at the cost of the server not being able to accurately verify that at the cost of the server not being able to accurately verify that
enrollment was truly successful. enrollment was truly successful.
3.8.5. EST over CoAP 3.8.5. EST over CoAP
[[EDNOTE: In order to support smaller devices the above section on This document describes extensions to EST for the purposes of
Proxy behavior introduces mandatory to implement support for CoAP bootstrapping of remote key infrastructures. Bootstrapping is
support by the Proxy. This implies similar support by the Pledge and relevant for CoAP enrollment discussions as well. The defintion of
Registrar and means that the EST protocol operation encapsulation EST and BRSKI over CoAP is not discussed within this document beyond
into CoAP needs to be described. EST is HTTP based and "CoaP is ensuring proxy support for CoAP operations. Instead it is
designed to easily interface with HTTP for integration" [RFC7252]. anticipated that a definition of CoAP mappings will occur in
Use of CoAP implies Datagram TLS (DTLS) wherever this document subsequent documents such as [I-D.vanderstok-ace-coap-est] and that
describes TLS handshake specifics. A complexity is that the large CoAP mappings for BRSKI will be discussed either there or in future
message sizes necessary for bootstrapping will require support for work.
[draft-ietf-core-block].]]
4. Reduced security operational modes 4. 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.
4.1. Trust Model 4.1. Trust Model
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| New | | Circuit | | Domain | | Vendor | | Pledge | | Circuit | | Domain | | Vendor |
| Entity | | Proxy | | Registrar | | Service | | | | Proxy | | Registrar | | Service |
| | | | | | | (Internet | | | | | | | | (Internet |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
Figure 10 Figure 10
Pledge: The Pledge could be compromised and providing an attack Pledge: The Pledge could be compromised and providing an attack
vector for malware. The entity is trusted to only imprint using vector for malware. The entity is trusted to only imprint using
secure methods described in this document. Additional endpoint secure methods described in this document. Additional endpoint
assessment techniques are RECOMMENDED but are out-of-scope of this assessment techniques are RECOMMENDED but are out-of-scope of this
document. document.
skipping to change at page 30, line 11 skipping to change at page 31, line 37
accurately log all claim attempts and to provide authoritative log accurately log all claim attempts and to provide authoritative log
information to Registrars. The MASA does not know which devices information to Registrars. The MASA does not know which devices
are associated with which domains. These claims could be 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 vendor. Current text provides only for a trusted vendor.
Vendor Service, Ownership Validation: This form of vendor service is Vendor Service, Ownership Validation: This form of vendor service is
trusted to accurately know which device is owned by which domain. trusted to accurately know which device is owned by which domain.
4.2. New Entity security reductions 4.2. Pledge security reductions
The Pledge MAY support "trust on first use" on physical interfaces The Pledge can choose to accept vouchers using less secure methods.
but MUST NOT support "trust on first use" on network interfaces. These methods enable offline and emergency (touch based) deployment
This is because "trust on first use" permanently degrades the use cases:
security for all other use cases.
The Pledge MAY have an operational mode where it skips Voucher 1. The Pledge MUST accept nonceless vouchers. This allows for
validation one time. For example if a physical button is depressed offline use cases. Logging and validity periods address the
during the bootstrapping operation. This can be useful if the vendor inherent security considerations of supporting these use cases.
service is unavailable. This behavior SHOULD be available via local
configuration or physical presence methods to ensure new entities can
always be deployed even when autonomic methods fail. This allows for
unsecured imprint.
It is RECOMMENDED that this only be available if hardware assisted 2. The Pledge MAY support "trust on first use" for physical
NEA [RFC5209] is supported. interfaces such as a local console port or physical user
interface but MUST NOT support "trust on first use" on network
interfaces. This is because "trust on first use" permanently
degrades the security for all use cases.
3. The Pledge MAY have an operational mode where it skips Voucher
validation one time. For example if a physical button is
depressed during the bootstrapping operation. This can be useful
if the vendor service is unavailable. This behavior SHOULD be
available via local configuration or physical presence methods to
ensure new entities can always be deployed even when autonomic
methods fail. This allows for unsecured imprint.
It is RECOMMENDED that "trust on first use" or skipping voucher
validation only be available if hardware assisted Network Endpoint
Assessment [RFC5209] is supported. This recommendation ensures that
domain network monitoring can detect innappropriate use of offline or
emergency deployment procedures.
4.3. Registrar security reductions 4.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.
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
an X.509 IDevID credential MAY form the Section 3.2 request using an X.509 IDevID credential MAY form the Section 3.2 request using
the Section 3.3 format to ensure the Pledge's serial number the Section 3.3 format to ensure the Pledge's serial number
information is provided to the Registar (this includes the information is provided to the Registar (this includes the IDevID
IDevIDAuthorityKeyIdentifier value which would be statically AuthorityKeyIdentifier value which would be statically configured
configured on the Pledge). The Pledge MAY refuse to provide a on the Pledge). The Pledge MAY refuse to provide a TLS client
TLS client certificate (as one is not available). The Pledge certificate (as one is not available). The Pledge SHOULD support
SHOULD support HTTP-based or certificate-less TLS authentication HTTP-based or certificate-less TLS authentication as described in
as described in EST RFC7030 section 3.3.2. A Registrar MUST NOT EST RFC7030 section 3.3.2. A Registrar MUST NOT accept
accept unauthenticated New Entities unless it has been configured unauthenticated New Entities unless it has been configured to do
to do so by an administrator that has verified that only expected so by an administrator that has verified that only expected new
new entities can communicate with a Registrar (presumably via a entities can communicate with a Registrar (presumably via a
physically secured perimeter). physically secured perimeter).
3. A Registrar MAY request nonce-less Vouchers from the MASA service 3. A Registrar MAY request nonce-less Vouchers from the MASA service
(by not including a nonce in the request). These Vouchers can (by not including a nonce in the request). These Vouchers can
then be transmitted to the Registrar and stored until they are then be transmitted to the Registrar and stored until they are
needed during bootstrapping operations. This is for use cases needed during bootstrapping operations. This is for use cases
where target network is protected by an air gap and therefore can where target network is protected by an air gap and therefore can
not contact the MASA service during Pledge deployment. not contact the MASA service during Pledge deployment.
4. A registrar MAY ignore unrecognized nonce-less log entries. This 4. A registrar MAY ignore unrecognized nonce-less log entries. This
skipping to change at page 32, line 7 skipping to change at page 33, line 45
voucher validity period is RECOMMENDED. voucher validity period is RECOMMENDED.
2. Not verifying ownership before responding with an Voucher. This 2. Not verifying ownership before responding with an Voucher. This
is expected to be a common operational model because doing so is expected to be a common operational model because doing so
relieves the vendor providing MASA services from having to track relieves the vendor providing MASA services from having to track
ownership during shipping and supply chain and allows for a very ownership during shipping and supply chain and allows for a very
low overhead MASA service. A Registrar uses the audit log 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). information is reported). The MASA should verify the 'prior-
signed-voucher' information for Pledge's that support that
functionality. This provides a proof-of-proximity check that
reduces the need for ownership verification.
5. IANA Considerations 5. IANA Considerations
5.1. PKIX Registry 5.1. PKIX Registry
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. [[EDNOTE: fix names]] the pkix(7) id-mod(0) Registry. [[EDNOTE: fix names]]
This document requests a number from the id-pe registry for id-pe- This document requests a number from the id-pe registry for id-pe-
masa-url. XXX masa-url. XXX
skipping to change at page 32, line 41 skipping to change at page 34, line 37
The issuance of nonceless vouchers themselves create a security The issuance of nonceless vouchers themselves create a security
concern. If the Registrar of a previous domain can intercept concern. If the Registrar of a previous domain can intercept
protocol communications then it can use a previously issued nonceless protocol communications then it can use a previously issued nonceless
voucher to establish management control of a pledge device even after voucher to establish management control of a pledge device even after
having sold it. This risk is mitigated by recording the issuance of having sold it. This risk is mitigated by recording the issuance of
such vouchers in the MASA audit log that is verified by the such vouchers in the MASA audit log that is verified by the
subsequent Registrar. This reduces the resale value of the equipment subsequent Registrar. This reduces the resale value of the equipment
because future owners will detect the lowered security inherent in because future owners will detect the lowered security inherent in
the existence of a nonceless voucher that would be trusted by their the existence of a nonceless voucher that would be trusted by their
Pledge. This accurately reflects a balance between partition Pledge. This reflects a balance between partition resistant recovery
resistant recovery and security of future bootstrapping. Registrars and security of future bootstrapping. Registrars take the Pledge's
take the Pledge's audit history into account when applying policy to audit history into account when applying policy to new devices.
new devices.
The MASA server is exposed to DoS attacks wherein attackers claim an The MASA server is exposed to DoS attacks wherein attackers claim an
unbounded number of devices. Ensuring a Registrar is representative unbounded number of devices. Ensuring a Registrar is representative
of a valid vendor customer, even without validating ownership of of a valid vendor customer, even without validating ownership of
specific Pledge devices, helps to mitigate this. Inserting a specific Pledge devices, helps to mitigate this. Pledge signatures
cryptographic proof-of-possession step to the protocol operations is on the initial voucher request, as forwarded by the Registrar in the
a possible area of future work. One method that would not introduce prior-signed-voucher field, significantly reduce this risk by
additional round-trips would be for the Registrar to share the ensuring the MASA can confirm proximity between the Pledge and the
Pledge-Registrar TLS handshake with the MASA service when requesting Registrar making the request. This mechanism is optional to allow
a voucher. Doing so would allow the MASA service to verify that the for constrained devices.
Registrar's Server Certificate was signed by the Pledge's Certificate
Verify message (which covers the entire handshake). [[EDNOTE:
Security Considerations should not offer up new protocol ideas
without a reason for having not done it...]]
It is possible for an attacker to request a voucher from the MASA It is possible for an attacker to request a voucher from the MASA
service directly after the real Registrar obtains an audit log. If service directly after the real Registrar obtains an audit log. If
the attacker could also force the bootstrapping protocol to reset the attacker could also force the bootstrapping protocol to reset
there is a theoretical opportunity for the attacker to use their there is a theoretical opportunity for the attacker to use their
voucher to take control of the Pledge but then proceed to enroll with voucher to take control of the Pledge but then proceed to enroll with
the target domain. Possible prevention mechanisms include: the target domain. Possible prevention mechanisms include:
o Per device rate limits on the MASA service ensure such timing o Per device rate limits on the MASA service ensure such timing
attacks are difficult. attacks are difficult.
skipping to change at page 33, line 34 skipping to change at page 35, line 24
To facilitate logging and administrative oversight the Pledge reports To facilitate logging and administrative oversight the Pledge reports
on Voucher parsing status to the Registrar. In the case of a failure on Voucher parsing status to the Registrar. In the case of a failure
this information is informative to a potentially malicious Registar this information is informative to a potentially malicious Registar
but this is RECOMMENDED anyway because of the operational benefits of but this is RECOMMENDED anyway because of the operational benefits of
an informed administrator in cases where the failure is indicative of an informed administrator in cases where the failure is indicative of
a problem. a problem.
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 4 to a statement that clients only model have been reduced in Section 4 to a statement that the
"SHOULD" support such a model. This reflects current (poor) Registrar "MAY" choose to accept devices that fail cryptographic
practices that are NOT RECOMMENDED. authentication. This reflects current (poor) practices in shipping
devices without a cryptographic identity that are NOT RECOMMENDED.
During the provisional period of the connection all HTTP header and During the provisional period of the connection all HTTP header and
content data MUST treated as untrusted data. HTTP libraries are content data MUST treated as untrusted data. HTTP libraries are
regularly exposed to non-secured HTTP traffic: mature libraries regularly exposed to non-secured HTTP traffic: mature libraries
should not have any problems. should not have any problems.
Pledge's might chose to engage in protocol operations with multiple Pledge's 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 multple so with distinct nonce values, but the end result could be multple
voucher's issued from the MASA if all registrars attempt to claim the voucher's issued from the MASA if all registrars attempt to claim the
skipping to change at page 34, line 23 skipping to change at page 36, line 17
8.1. Normative References 8.1. Normative References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
Control Plane", draft-ietf-anima-autonomic-control- Control Plane", draft-ietf-anima-autonomic-control-
plane-06 (work in progress), March 2017. plane-06 (work in progress), March 2017.
[I-D.ietf-anima-voucher] [I-D.ietf-anima-voucher]
Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"Voucher Profile for Bootstrapping Protocols", draft-ietf- "Voucher Profile for Bootstrapping Protocols", draft-ietf-
anima-voucher-02 (work in progress), March 2017. anima-voucher-04 (work in progress), July 2017.
[IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", [I-D.vanderstok-ace-coap-est]
Kumar, S., Stok, P., Kampanakis, P., Furuhed, M., and S.
Raza, "EST over secure CoAP (EST-coaps)", draft-
vanderstok-ace-coap-est-02 (work in progress), June 2017.
[IDevID] IEEE Standard, "IEEE 802.1AR Secure Device Identifier",
December 2009, <http://standards.ieee.org/findstds/ December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for "Advanced Sockets Application Program Interface (API) for
skipping to change at page 35, line 5 skipping to change at page 37, line 5
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005, DOI 10.17487/RFC3927, May 2005,
<http://www.rfc-editor.org/info/rfc3927>. <http://www.rfc-editor.org/info/rfc3927>.
[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,
<http://www.rfc-editor.org/info/rfc4862>. <http://www.rfc-editor.org/info/rfc4862>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
Security: An Unauthenticated Mode of IPsec", RFC 5386, Security: An Unauthenticated Mode of IPsec", RFC 5386,
DOI 10.17487/RFC5386, November 2008, DOI 10.17487/RFC5386, November 2008,
<http://www.rfc-editor.org/info/rfc5386>. <http://www.rfc-editor.org/info/rfc5386>.
skipping to change at page 35, line 42 skipping to change at page 37, line 47
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<http://www.rfc-editor.org/info/rfc7030>. <http://www.rfc-editor.org/info/rfc7030>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>. <http://www.rfc-editor.org/info/rfc7228>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<http://www.rfc-editor.org/info/rfc7951>.
8.2. Informative References 8.2. Informative References
[I-D.behringer-homenet-trust-bootstrap] [I-D.behringer-homenet-trust-bootstrap]
Behringer, M., Pritikin, M., and S. Bjarnason, Behringer, M., Pritikin, M., and S. Bjarnason,
"Bootstrapping Trust on a Homenet", draft-behringer- "Bootstrapping Trust on a Homenet", draft-behringer-
homenet-trust-bootstrap-02 (work in progress), February homenet-trust-bootstrap-02 (work in progress), February
2014. 2014.
[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-12 (work in progress), May 2017. grasp-13 (work in progress), June 2017.
[I-D.ietf-netconf-zerotouch] [I-D.ietf-netconf-zerotouch]
Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch
for NETCONF or RESTCONF based Management", draft-ietf- Provisioning for NETCONF or RESTCONF based Management",
netconf-zerotouch-13 (work in progress), March 2017. draft-ietf-netconf-zerotouch-14 (work in progress), June
2017.
[I-D.lear-mud-framework] [I-D.lear-mud-framework]
Lear, E., "Manufacturer Usage Description Framework", Lear, E., "Manufacturer Usage Description Framework",
draft-lear-mud-framework-00 (work in progress), January draft-lear-mud-framework-00 (work in progress), January
2016. 2016.
[I-D.richardson-anima-state-for-joinrouter] [I-D.richardson-anima-state-for-joinrouter]
Richardson, M., "Considerations for stateful vs stateless Richardson, M., "Considerations for stateful vs stateless
join router in ANIMA bootstrap", draft-richardson-anima- join router in ANIMA bootstrap", draft-richardson-anima-
state-for-joinrouter-01 (work in progress), July 2016. state-for-joinrouter-01 (work in progress), July 2016.
[imprinting] [imprinting]
Wikipedia, , "Wikipedia article: Imprinting", July 2015, Wikipedia, "Wikipedia article: Imprinting", July 2015,
<https://en.wikipedia.org/wiki/Imprinting_(psychology)>. <https://en.wikipedia.org/wiki/Imprinting_(psychology)>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>. December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
skipping to change at page 45, line 6 skipping to change at page 47, line 6
D.1.1. Behavior of a Pledge D.1.1. Behavior of a Pledge
A pledge that has not yet been bootstrapped attempts to find a local A pledge that has not yet been bootstrapped attempts to find a local
domain and join it. A pledge [[RESOLVED:MUST NOT]] automatically domain and join it. A pledge [[RESOLVED:MUST NOT]] automatically
initiate bootstrapping if it has already been configured or is in the initiate bootstrapping if it has already been configured or is in the
process of being configured. process of being configured.
States of a pledge are as follows: States of a pledge are as follows:
+--------------+ +--------------+
| Start | | Factory |
| | | default |
+------+-------+ +------+-------+
| |
+------v-------+ +------v-------+
| Discover | | Discover |
+------------> | +------------> |
| +------+-------+ | +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | Identity | | | Identity |
^------------+ | ^------------+ |
skipping to change at page 45, line 36 skipping to change at page 47, line 36
| | Imprint | Optional | | Imprint | Optional
^------------+ <--+Manual input (Appendix C) ^------------+ <--+Manual input (Appendix C)
| Bad Vendor +------+-------+ | Bad Vendor +------+-------+
| response | | response |
| +------v-------+ | +------v-------+
| | Enroll | | | Enroll |
^------------+ | ^------------+ |
| Enroll +------+-------+ | Enroll +------+-------+
| Failure | | Failure |
| +------v-------+ | +------v-------+
| | Being | | | Enrolled |
^------------+ Managed | ^------------+ |
Factory +--------------+ Factory +--------------+
reset reset
Figure 3 Figure 3
State descriptions for the pledge are as follows: State descriptions for the pledge are as follows:
1. Discover a communication channel to a Registrar. 1. Discover a communication channel to a Registrar.
2. Identify itself. This is done by presenting an X.509 IDevID 2. Identify itself. This is done by presenting an X.509 IDevID
skipping to change at page 54, line 5 skipping to change at page 56, line 5
registered with another domain, a Registrar of that domain would show registered with another domain, a Registrar of that domain would show
in the log. in the log.
[[RESOLVED: est integration section used 'SHOULD']]The authorization [[RESOLVED: est integration section used 'SHOULD']]The authorization
performed during BRSKI MAY be used for EST enrollment requests by performed during BRSKI MAY be used for EST enrollment requests by
proceeding with EST enrollment using the authenticated and authorized proceeding with EST enrollment using the authenticated and authorized
TLS connection. This minimizes the number of cryptographic and TLS connection. This minimizes the number of cryptographic and
protocol operations necessary to complete bootstrapping of the local protocol operations necessary to complete bootstrapping of the local
key infrastructure. key infrastructure.
D.1.3.3. Claiming the New Entity D.1.3.3. Claiming the Pledge
Claiming an entity establishes an audit log at the MASA server and Claiming an pledge establishes an audit log at the MASA server and
provides a Registrar with proof, in the form of the Voucher, that the provides a Registrar with proof, in the form of the Voucher, that the
log entry has been inserted. As indicated in Appendix D.1.1.4 a log entry has been inserted. As indicated in Appendix D.1.1.4 a
Pledge will only proceed with bootstrapping if a Voucher has been Pledge will only proceed with bootstrapping if a Voucher has been
received. The Pledge therefore enforces that bootstrapping only received. The Pledge therefore enforces that bootstrapping only
occurs if the claim has been logged. There is no requirement for the occurs if the claim has been logged. There is no requirement for the
vendor to definitively know that the device is owned by the vendor to definitively know that the device is owned by the
Registrar. Registrar.
The Registrar obtains the MASA URI via static configuration or by The Registrar obtains the MASA URI via static configuration or by
extracting it from the X.509 IDevID credential. See Section 2.2. extracting it from the X.509 IDevID credential. See Section 2.2.
During initial bootstrapping the Pledge provides a nonce specific to During initial bootstrapping the Pledge provides a nonce specific to
the particular bootstrapping attempt. [[RESOLVED: to resolve this I the particular bootstrapping attempt. [[RESOLVED: to resolve this I
updated many points where vouchers are referenced]]The Registrar updated many points where vouchers are referenced]]The Registrar
SHOULD include this nonce when claiming the Pledge from the MASA SHOULD include this nonce when claiming the Pledge from the MASA
service. Claims from an unauthenticated Registrar are only serviced service. Claims from an unauthenticated Registrar are only serviced
by the MASA resource if a nonce is provided. by the MASA resource if a nonce is provided.
The Registrar can claim a Pledge that is not online by forming the The Registrar can claim a Pledge that is offline by forming the
request using the entities unique identifier and not including a request using the entities unique identifier and not including a
nonce in the claim request. Vouchers obtained in this way do not nonce in the claim request. Vouchers obtained in this way do not
have a lifetime and they provide a permanent method for the domain to have a lifetime and they provide a permanent method for the domain to
claim the device. Evidence of such a claim is provided in the audit claim the device. Evidence of such a claim is provided in the audit
log entries available to any future Registrar. Such claims reduce log entries available to any future Registrar. Such claims reduce
the ability for future domains to secure bootstrapping and therefore the ability for future domains to secure bootstrapping and therefore
the Registrar MUST be authenticated by the MASA service although no the Registrar MUST be authenticated by the MASA service although no
requirement is implied that the MASA associates this authentication requirement is implied that the MASA associates this authentication
with ownership. with ownership.
 End of changes. 76 change blocks. 
316 lines changed or deleted 413 lines changed or added

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