draft-ietf-anima-bootstrapping-keyinfra-08.txt   draft-ietf-anima-bootstrapping-keyinfra-09.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: April 15, 2018 SSW Expires: May 3, 2018 SSW
M. Behringer M. Behringer
Cisco Cisco
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
K. Watsen K. Watsen
Juniper Networks Juniper Networks
October 12, 2017 October 30, 2017
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-08 draft-ietf-anima-bootstrapping-keyinfra-09
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 and in combination with a vendor's authorizing service, both online and
offline. Bootstrapping a new device can occur using a routable offline. Bootstrapping a new device can occur using a routable
address and a cloud service, or using only link-local connectivity, address and a cloud service, or using only link-local connectivity,
or on limited/disconnected networks. Support for lower security or on limited/disconnected networks. Support for lower security
models, including devices with minimal identity, is described for models, including devices with minimal identity, is described for
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 15, 2018. This Internet-Draft will expire on May 3, 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Other Bootstrapping Approaches . . . . . . . . . . . . . 4 1.1. Other Bootstrapping Approaches . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 8 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 8
1.4. Leveraging the new key infrastructure / next steps . . . 9 1.4. Leveraging the new key infrastructure / next steps . . . 9
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 9 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 9
2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 11 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 11
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 12 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 12
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 13 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 13
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1. Architectural component: Pledge . . . . . . . . . . . 16 2.4.1. Architectural component: Pledge . . . . . . . . . . . 16
2.4.2. Architectural component: Circuit Proxy . . . . . . . 16 2.4.2. Architectural component: Circuit Proxy . . . . . . . 16
2.4.3. Architectural component: Domain Registrar . . . . . . 16 2.4.3. Architectural component: Domain Registrar . . . . . . 16
2.4.4. Architectural component: Vendor Service . . . . . . . 16 2.4.4. Architectural component: Vendor Service . . . . . . . 16
2.5. Lack of realtime clock . . . . . . . . . . . . . . . . . 16 2.5. Lack of realtime clock . . . . . . . . . . . . . . . . . 16
2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 17 2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 17
2.7. Determining the MASA to contact . . . . . . . . . . . . . 17 2.7. Determining the MASA to contact . . . . . . . . . . . . . 17
3. Voucher Request artifact . . . . . . . . . . . . . . . . . . 18 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 18
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 18 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21
4. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 23 4. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 24 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 24
4.1.1. Proxy Grasp announcements . . . . . . . . . . . . . . 25 4.1.1. Proxy Grasp announcements . . . . . . . . . . . . . . 25
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 26 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 26
4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 26 4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 26
4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 26 4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 26
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 27 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 28
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 29 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 30
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 30 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 30
5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 31 5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 31
5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 31 5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 32
5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 34 5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 35
5.5.1. Completing authentication of Provisional TLS 5.5.1. Completing authentication of Provisional TLS
connection . . . . . . . . . . . . . . . . . . . . . 35 connection . . . . . . . . . . . . . . . . . . . . . 36
5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 36 5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 37
5.7. MASA authorization log Request . . . . . . . . . . . . . 37 5.7. MASA authorization log Request . . . . . . . . . . . . . 38
5.7.1. MASA authorization log Response . . . . . . . . . . . 38 5.7.1. MASA authorization log Response . . . . . . . . . . . 39
5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 39 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 40
5.8.1. EST Distribution of CA Certificates . . . . . . . . . 39 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 40
5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 40 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 40
5.8.3. EST Client Certificate Request . . . . . . . . . . . 41 5.8.3. EST Client Certificate Request . . . . . . . . . . . 41
5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 41 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 41
5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 42 5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 43
6. Reduced security operational modes . . . . . . . . . . . . . 42 6. Reduced security operational modes . . . . . . . . . . . . . 43
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 42 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 43
6.2. Pledge security reductions . . . . . . . . . . . . . . . 43 6.2. Pledge security reductions . . . . . . . . . . . . . . . 44
6.3. Registrar security reductions . . . . . . . . . . . . . . 44 6.3. Registrar security reductions . . . . . . . . . . . . . . 44
6.4. MASA security reductions . . . . . . . . . . . . . . . . 44 6.4. MASA security reductions . . . . . . . . . . . . . . . . 45
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
7.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 45 7.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 46
7.2. MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.2. Voucher Status Telemetry . . . . . . . . . . . . . . . . 46
7.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 47
8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47
8.1. Freshness in Voucher Requests . . . . . . . . . . . . . . 49 8.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 48
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.1. Normative References . . . . . . . . . . . . . . . . . . 50 10.1. Normative References . . . . . . . . . . . . . . . . . . 50
10.2. Informative References . . . . . . . . . . . . . . . . . 52 10.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 53 Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 54
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 53 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 54
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 54 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 54
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 54 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 54
Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 55 Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 55
C.1. Multiple Join networks on the Join Proxy side . . . . . . 55 C.1. Multiple Join networks on the Join Proxy side . . . . . . 55
C.2. Automatic configuration of tunnels on Registrar . . . . . 56 C.2. Automatic configuration of tunnels on Registrar . . . . . 56
C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 56 C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 56
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 . . . . . . . . . . . . . . . . . . . . . . . . 56 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 57
C.5. Use of socket extension rather than virtual interface . . 57 C.5. Use of socket extension rather than virtual interface . . 57
Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 57 Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Appendix E. Example Vouchers . . . . . . . . . . . . . . . . . . 59
E.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 59
E.1.1. MASA key pair for voucher signatures . . . . . . . . 59
E.1.2. Manufacturer key pair for IDevID signatures . . . . . 59
E.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 60
E.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 62
E.2. Example process . . . . . . . . . . . . . . . . . . . . . 64
E.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 64
E.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 66
E.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
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 4, line 26 skipping to change at page 4, line 35
This document details protocols and messages to the endpoints to This document details protocols and messages to the endpoints to
answer the above questions. The Registrar actions derive from Pledge answer the above questions. The Registrar actions derive from Pledge
identity, third party cloud service communications, and local access identity, third party cloud service communications, and local access
control lists. The Pledge actions derive from a cryptographically control lists. The Pledge actions derive from a cryptographically
protected "voucher" message delivered through the Registrar but protected "voucher" message delivered through the Registrar but
originating at a Manufacturer Authorized Signing Authority. originating at a Manufacturer Authorized Signing Authority.
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]. This document details automated protocol [I-D.ietf-anima-voucher]. This document details automated protocol
mechanisms to obtain vouchers, including the definition of a mechanisms to obtain vouchers, including the definition of a
necessary 'voucher request' message that is a minor extension to the 'voucher-request' message that is a minor extension to the voucher
voucher format (see Section 3). format (see Section 3).
BRSKI results in the Pledge storing an X.509 root certificate BRSKI results in the Pledge storing an X.509 root certificate
sufficient for verifying the Registrar identity. In the process a sufficient for verifying the Registrar identity. In the process a
TLS connection is established which can be directly used for TLS connection is established which can be directly used for
Enrollment over Secure Transport (EST). In effect BRSKI provides an Enrollment over Secure Transport (EST). In effect BRSKI provides an
automated mechanism for the "Bootstrap Distribution of CA automated mechanism for the "Bootstrap Distribution of CA
Certificates" described in [RFC7030] Section 4.1.1 wherein the Pledge Certificates" described in [RFC7030] Section 4.1.1 wherein the Pledge
"MUST [...]. engage a human user to authorize the CA certificate "MUST [...]. engage a human user to authorize the CA certificate
using out-of-band" information". With BRSKI the Pledge now can using out-of-band" information". With BRSKI the Pledge now can
automate this process using the voucher. Integration with a complete automate this process using the voucher. Integration with a complete
skipping to change at page 6, line 7 skipping to change at page 6, line 17
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:
DomainID: The domain identity is the 160-bit SHA-1 hash of the BIT domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT
STRING of the subjectPublicKey of the domain trust anchor that is STRING of the subjectPublicKey of the root certificate for the
stored by the Domain CA. This is consistent with the registrars in the domain. This is consistent with the subject key
Certification Authority subject key identifier (Section 4.2.1.2 identifier (Section 4.2.1.2 [RFC5280]).
[RFC5280]) of the Domain CA's self signed root certificate. (A
string value bound to the Domain CA's self signed root certificate
subject and issuer fields is often colloquially used as a
humanized identity value but during protocol discussions the more
exact term as defined here is used).
drop ship: The physical distribution of equipment containing the drop ship: The physical distribution of equipment containing the
"factory default" configuration to a final destination. In zero- "factory default" configuration to a final destination. In zero-
touch scenarios there is no staging or pre-configuration during touch scenarios there is no staging or pre-configuration during
drop-ship. drop-ship.
imprint: The process where a device obtains the cryptographic key imprint: The process where a device obtains the cryptographic key
material to identify and trust future interactions with a network. material to identify and trust future interactions with a network.
This term is taken from Konrad Lorenz's work in biology with new This term is taken from Konrad Lorenz's work in biology with new
ducklings: during a critical period, the duckling would assume ducklings: during a critical period, the duckling would assume
skipping to change at page 13, line 7 skipping to change at page 13, line 7
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 Vouchers provide a signed but non-encrypted communication channel
between the Pledge, the MASA, and the Registrar. The Registrar between the Pledge, the MASA, and the Registrar. The Registrar
maintains control over the transport and policy decisions allowing maintains control over the transport and policy decisions allowing
the local security policy of the domain network to be enforced. the local security policy of the domain network to be enforced.
2.3. Initial Device Identifier 2.3. Initial Device Identifier
Pledge authentication and voucher request signing is via an X.509 Pledge authentication and Pledge voucher-request signing is via an
certificate installed during the manufacturing process. This Initial X.509 certificate installed during the manufacturing process. This
Device Identifier provides a basis for authenticating the Pledge Initial Device Identifier provides a basis for authenticating the
during subsequent protocol exchanges and informing the Registrar of Pledge during subsequent protocol exchanges and informing the
the MASA URI. There is no requirement for a common root PKI Registrar of the MASA URI. There is no requirement for a common root
hierarchy. Each device vendor can generate their own root PKI hierarchy. Each device vendor can generate their own root
certificate. 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.
skipping to change at page 17, line 19 skipping to change at page 17, line 19
GeneralizedTime value of 99991231235959Z" [RFC7030] so the GeneralizedTime value of 99991231235959Z" [RFC7030] so the
Registrar MUST support such lifetimes and SHOULD support ignoring Registrar MUST support such lifetimes and SHOULD support ignoring
Pledge lifetimes if they did not follow the RFC5280 Pledge lifetimes if they did not follow the RFC5280
recommendations. recommendations.
o The Pledge authenticates the voucher presented to it. During this o The Pledge authenticates the voucher presented to it. During this
authentication the Pledge ignores certificate lifetimes (by authentication the Pledge ignores certificate lifetimes (by
necessity because it does not have a realtime clock). necessity because it does not have a realtime clock).
o If the voucher contains a nonce then the Pledge MUST confirm the o If the voucher contains a nonce then the Pledge MUST confirm the
nonce matches the original voucher request. This ensures the nonce matches the original Pledge voucher-request. This ensures
voucher is fresh. See / (Section 5.2). the voucher is fresh. See / (Section 5.2).
o Once the voucher is accepted the validity period of the pinned- o Once the voucher is accepted the validity period of the pinned-
domain-cert in the voucher now serves as a valid time window. Any domain-cert in the voucher now serves as a valid time window. Any
subsequent certificate validity periods checked during RFC5280 subsequent certificate validity periods checked during RFC5280
path validation MUST occur within this window. path validation MUST occur within this window.
o When accepting an enrollment certificate the validity period o When accepting an enrollment certificate the validity period
within the new certificate is assumed to be valid by the Pledge. within the new certificate is assumed to be valid by the Pledge.
The Pledge is now willing to use this credential for client The Pledge is now willing to use this credential for client
authentication. authentication.
skipping to change at page 18, line 20 skipping to change at page 18, line 20
It can be operationally difficult to ensure the necessary X.509 It can be operationally difficult to ensure the necessary X.509
extensions are in the Pledge's' IDevID due to the difficulty of extensions are in the Pledge's' IDevID due to the difficulty of
aligning current Pledge manufacturing with software releases and aligning current Pledge manufacturing with software releases and
development. As a final fallback the Registrar MAY be manually development. As a final fallback the Registrar MAY be manually
configured or distributed with a MASA URL for each vendor. Note that configured or distributed with a MASA URL for each vendor. Note that
the Registrar can only select the configured MASA URL based on the the Registrar can only select the configured MASA URL based on the
trust anchor -- so vendors can only leverage this approach if they trust anchor -- so vendors can only leverage this approach if they
ensure a single MASA URL works for all Pledge's associated with each ensure a single MASA URL works for all Pledge's associated with each
trust anchor. trust anchor.
3. Voucher Request artifact 3. Voucher-Request artifact
The voucher request is how an entity requests a voucher. The Pledge The Pledge voucher-request is how a Pledge requests a voucher. The
forms a voucher request and submits it to the Registrar. The Pledge forms a voucher-request and submits it to the Registrar. The
Registrar in turn submits a voucher request to the MASA server. A Registrar in turn submits a voucher-request to the MASA server. To
voucher request is a voucher structure with an additional "prior- help differentiate this document refers to "Pledge voucher-request"
signed-voucher-request" "leaf to support forwarding the Pledge's and "Registrar voucher-request" when indicating the source is
initial voucher request. beneficial. The "proximity-registrar-cert" leaf is used in Pledge
voucher-requests. The "prior-signed-voucher-request" is used in
Registrar voucher-requests that include a Pledge voucher-request.
Unless otherwise signaled (outside the voucher artifact), the signing Unless otherwise signaled (outside the voucher-request artifact), the
structure is as defined for vouchers, see [I-D.ietf-anima-voucher]. signing structure is as defined for vouchers, see
[I-D.ietf-anima-voucher].
3.1. Tree Diagram 3.1. Tree Diagram
The following tree diagram illustrates a high-level view of a voucher The following tree diagram illustrates a high-level view of a
request document. The notation used in this diagram is described in voucher-request document. The notation used in this diagram is
[I-D.ietf-anima-voucher]. Each node in the diagram is fully described in [I-D.ietf-anima-voucher]. Each node in the diagram is
described by the YANG module in Section 3.3. Please review the YANG fully described by the YANG module in Section 3.3. Please review the
module for a detailed description of the voucher request format. YANG module for a detailed description of the voucher-request format.
module: ietf-voucher-request module: ietf-voucher-request
groupings:
voucher-request-grouping grouping voucher-request-grouping
+---- voucher +---- voucher
+---- created-on? yang:date-and-time +---- created-on? yang:date-and-time
+---- expires-on? yang:date-and-time +---- expires-on? yang:date-and-time
+---- assertion enumeration +---- assertion enumeration
+---- serial-number string +---- serial-number string
+---- idevid-issuer? binary +---- idevid-issuer? binary
+---- pinned-domain-cert? binary +---- pinned-domain-cert? binary
+---- domain-cert-revocation-checks? boolean +---- domain-cert-revocation-checks? boolean
+---- nonce? binary +---- nonce? binary
+---- last-renewal-date? yang:date-and-time +---- last-renewal-date? yang:date-and-time
+---- prior-signed-voucher-request? binary +---- prior-signed-voucher-request? binary
+---- proximity-registrar-cert? binary +---- proximity-registrar-cert? binary
3.2. Examples 3.2. Examples
This section provides voucher examples for illustration purposes. This section provides voucher examples for illustration purposes.
That these examples conform to the encoding rules defined in That these examples conform to the encoding rules defined in
[RFC7951]. [RFC7951].
Example (1) The following example illustrates a Pledge generated Example (1) The following example illustrates a Pledge voucher-
voucher-request. The assertion leaf is indicated as request. The assertion leaf is indicated as 'proximity'
'proximity' and the Registrar's TLS server certificate and the Registrar's TLS server certificate is included
is included in the 'pinned-domain-cert' leaf. See in the 'proximity-registrar-cert' leaf. See
Section 5.2. Section 5.2.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request: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",
"proximity-registrar-cert": "base64encodedvalue==" "proximity-registrar-cert": "base64encodedvalue=="
} }
} }
Example (2) The following example illustrates a Registrar generated Example (2) The following example illustrates a Registrar voucher-
voucher-request. The 'prior-signed-voucher-request' request. The 'prior-signed-voucher-request' leaf is
leaf is populated with the Pledge's voucher request populated with the Pledge's voucher-request (such as the
(such as the prior example). See Section 5.4. prior example). See Section 5.4.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"assertion": "proximity", "assertion": "proximity",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
"prior-signed-voucher": "base64encodedvalue==" "prior-signed-voucher": "base64encodedvalue=="
} }
} }
Example (3) The following example illustrates a Registrar generated Example (3) The following example illustrates a Registrar voucher-
voucher-request. The 'prior-signed-voucher-request' request. The 'prior-signed-voucher-request' leaf is not
leaf is not populated with the Pledge's voucher request populated with the Pledge's voucher-request nor is the
nor is the nonce leaf. This form might be used by a nonce leaf. This form might be used by a Registrar
Registrar requesting a voucher when the Pledge is requesting a voucher when the Pledge is offline or when
offline or when the Registrar expects to be offline the Registrar expects to be offline during deployment.
during deployment. See Section 5.4. See Section 5.4.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"assertion": "TBD", "assertion": "TBD",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
Example (4) The following example illustrates a Registrar generated Example (4) The following example illustrates a Registrar voucher-
voucher-request. The 'prior-signed-voucher-request' request. The 'prior-signed-voucher-request' leaf is not
leaf is not populated with the Pledge's voucher request populated with the Pledge voucher-request because the
because the Pledge did not sign it's own request. This Pledge did not sign it's own request. This form might
form might be used when more constrained Pledges are be used when more constrained Pledges are being
being deployed. The nonce is populated from the deployed. The nonce is populated from the Pledge's
Pledge's request. See Section 5.4. request. See Section 5.4.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"assertion": "proximity", "assertion": "proximity",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
3.3. YANG Module 3.3. YANG Module
Following is a YANG [RFC7950] module formally extending the Following is a YANG [RFC7950] module formally extending the
[I-D.ietf-anima-voucher] voucher into the voucher request. [I-D.ietf-anima-voucher] voucher into a voucher-request.
<CODE BEGINS> file "ietf-voucher-request@2017-10-13.yang" <CODE BEGINS> file "ietf-voucher-request@2017-10-30.yang"
module ietf-voucher-request { module ietf-voucher-request {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-voucher-request"; "urn:ietf:params:xml:ns:yang:ietf-voucher-request";
prefix "vch"; prefix "vch";
import ietf-restconf { import ietf-restconf {
prefix rc; prefix rc;
description description
skipping to change at page 22, line 18 skipping to change at page 22, line 18
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices."; itself for full legal notices.";
revision "2017-10-13" { revision "2017-10-30" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Voucher Profile for Bootstrapping Protocols"; "RFC XXXX: Voucher Profile for Bootstrapping Protocols";
} }
// Top-level statement // Top-level statement
rc:yang-data voucher-request-artifact { rc:yang-data voucher-request-artifact {
uses voucher-request-grouping; uses voucher-request-grouping;
} }
skipping to change at page 26, line 33 skipping to change at page 26, line 33
Pledge to a Registrar. Pledge to a Registrar.
When the Proxy provides a circuit proxy to a Registrar the Registrar When the Proxy provides a circuit proxy to a Registrar the Registrar
MUST accept HTTPS connections. MUST accept HTTPS connections.
4.4. Proxy discovery of Registrar 4.4. Proxy discovery of Registrar
The Registrar SHOULD announce itself so that proxies can find it and The Registrar SHOULD announce itself so that proxies can find it and
determine what kind of connections can be terminated. determine what kind of connections can be terminated.
When the Registrar joins an Autonomic Control Plane The registrar announces itself using GRASP M_FLOOD messages. The
([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP M_FLOOD is formatted as follows:
([I-D.ietf-anima-grasp]) M_NEG_SYN message.
The registrar responds to discovery messages from the proxy (or GRASP
caches between them) as follows: (XXX changed from M_DISCOVERY)
objective = ["AN_registrar", F_DISC, 255 ] [M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000,
discovery-message = [M_NEG_SYN, session-id, initiator, objective] ["AN_join_registrar", 4, 255, "EST-TLS"],
[O_IPv6_LOCATOR,
h'fda379a6f6ee0000200000064000001', TCP, 80
Figure 6: Registrar Discovery Figure 6: Registrar Discovery
The response from the registrar (or cache) will be a M_RESPONSE with The formal CDDL definition is:
the following parameters:
response-message = [M_RESPONSE, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
(+locator-option // divert-option), ?objective)] +[objective, (locator-option / [])]]
initiator = ACP address of Registrar
locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] objective = ["AN_join_registrar", objective-flags, loop-count,
locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] objective-value]
locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
initiator = ACP address to contact Registrar
objective-flags = sync-only ; as in GRASP spec
sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 255 ; mandatory maximum
objective-value = text ; name of the (list of) of supported
; protocols: "EST-TLS" for RFC7030.
Figure 7: AN_join_registrar CDDL
The M_FLOOD message MUST be sent periodically. The period is subject
to network administrator policy (EST server configuration). It must
be so low that the aggregate amount of periodic M_FLOODs from all EST
servers causes negligible traffic across the ACP.
The locators are to be interpreted as follows:
locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443]
locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
Figure 7: Registrar Response Figure 7: Registrar Response
The set of locators is to be interpreted as follows. A protocol of 6 The set of locators is to be interpreted as follows. A protocol of 6
indicates that TCP proxying on the indicated port is desired. A indicates that TCP proxying on the indicated port is desired. A
protocol of 17 indicates that UDP proxying on the indicated port is protocol of 17 indicates that UDP proxying on the indicated port is
desired. In each case, the traffic SHOULD be proxied to the same desired. In each case, the traffic SHOULD be proxied to the same
port at the ULA address provided. port at the ULA address provided.
A protocol of 41 indicates that packets may be IPIP proxy'ed. In the A protocol of 41 indicates that packets may be IPIP proxy'ed. In the
case of that IPIP proxying is used, then the provided link-local case of that IPIP proxying is used, then the provided link-local
address MUST be advertised on the local link using proxy neighbour address MUST be advertised on the local link using proxy neighbour
discovery. The Join Proxy MAY limit forwarded traffic to the discovery. The Join Proxy MAY limit forwarded traffic to the
protocol (6 and 17) and port numbers indicated by locator1 and protocol (6 and 17) and port numbers indicated by locator1 and
locator2. The address to which the IPIP traffic should be sent is locator2. The address to which the IPIP traffic should be sent is
the initiator address (an ACP address of the Registrar), not the the initiator address (an ACP address of the Registrar), not the
address given in the locator. address given in the locator.
Registrars MUST accept TCP / UDP traffic on the ports given at the Registrars MUST accept TCP / UDP traffic on the ports given at the
ACP address of the Registrar. If the Registrar supports IPIP ACP address of the Registrar. If the Registrar supports IPIP
tunnelling, it MUST also accept traffic encapsulated with IPIP. ntunnelling, it MUST also accept traffic encapsulated with IPIP.
Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated.
Registrars MAY accept DTLS/CoAP/EST traffic on the UDP in addition to Registrars MAY accept DTLS/CoAP/EST traffic on the UDP in addition to
TCP traffic. TCP traffic.
5. Protocol Details 5. Protocol Details
The Pledge MUST initiate BRSKI after boot if it is unconfigured. The The Pledge MUST initiate BRSKI after boot if it is unconfigured. The
Pledge MUST NOT automatically initiate BRSKI if it has been Pledge MUST NOT automatically initiate BRSKI if it has been
configured or is in the process of being configured. configured or is in the process of being configured.
skipping to change at page 30, line 6 skipping to change at page 30, line 25
are between the Pledge and the Registrar regardless of proxy are between the Pledge and the Registrar regardless of proxy
operations. operations.
Establishment of the BRSKI-EST TLS connection is as specified in EST Establishment of the BRSKI-EST TLS connection is as specified in EST
[RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates"
[RFC7030] wherein the client is authenticated with the IDevID [RFC7030] wherein the client is authenticated with the IDevID
certificate, and the EST server (the Registrar) is provisionally certificate, and the EST server (the Registrar) is provisionally
authenticated with a unverified server certificate. authenticated with a unverified server certificate.
The Pledge maintains a security paranoia concerning the provisional The Pledge maintains a security paranoia concerning the provisional
state, and all data recieved, until a voucher is received and state, and all data received, until a voucher is received and
verified as specified in Section 5.5.1 verified as specified in Section 5.5.1
5.2. Pledge Requests Voucher from the Registrar 5.2. Pledge Requests Voucher from the Registrar
When the Pledge bootstraps it makes a request for a Voucher from a When the Pledge bootstraps it makes a request for a Voucher from a
Registrar. Registrar.
This is done with an HTTPS POST using the operation path value of This is done with an HTTPS POST using the operation path value of
"/requestvoucher". "/.well-known/est/requestvoucher".
The request media types are: The request media types are:
application/pkcs7-mime; smime-type=voucher-request The request is a application/pkcs7-mime; smime-type=voucher-request The request is a
"YANG-defined JSON document that has been signed using a PKCS#7 "YANG-defined JSON document that has been signed using a PKCS#7
structure" as described in Section 3 using the JSON encoding structure" as described in Section 3 using the JSON encoding
described in [RFC7951]. The Pledge SHOULD sign the request using described in [RFC7951]. The Pledge SHOULD sign the request using
the Section 2.3 credential. the Section 2.3 credential.
application/json The request is the "YANG-defined JSON document" as application/json The request is the "YANG-defined JSON document" as
described in Section 3 with exception that it is not within a described in Section 3 with exception that it is not within a
PKCS#7 structure. It is protected only by the TLS client PKCS#7 structure. It is protected only by the TLS client
authentication. This reduces the cryptographic requirements on authentication. This reduces the cryptographic requirements on
the Pledge. the Pledge.
For simplicity the term 'voucher request' is used to refer to either For simplicity the term 'voucher-request' is used to refer to either
of these media types. Registrar impementations SHOULD anticipate of these media types. Registrar impementations SHOULD anticipate
future media types but of course will simply fail the request if future media types but of course will simply fail the request if
those types are not yet known. those types are not yet known.
The Pledge populates the voucher request fields as follows: The Pledge populates the voucher-request fields as follows:
created-on: Pledges that have a realtime clock are RECOMMENDED to created-on: Pledges that have a realtime clock are RECOMMENDED to
populate this field. 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 Pledge voucher-request MUST contain a cryptographically
random or pseudo-random number nonce. Doing so ensures strong random or pseudo-random number nonce. Doing so ensures
Section 2.5 functionality. The nonce MUST NOT be reused for Section 2.5 functionality. The nonce MUST NOT be reused for
bootstrapping attempts. bootstrapping attempts.
assertion: The voucher request MAY contain an assertion of assertion: The Pledge voucher-request MAY contain an assertion of
"proximity". "proximity".
proximity-registrar-cert: In a Pledge voucher request this is the proximity-registrar-cert: In a Pledge voucher-request this is the
first certificate in the TLS server 'certificate_list' sequence first certificate in the TLS server 'certificate_list' sequence
(see [RFC5246]) presented by the Registrar to the Pledge. This (see [RFC5246]) presented by the Registrar to the Pledge. This
MUST be populated in a Pledge's voucher request if the "proximity" MUST be populated in a Pledge voucher-request if the "proximity"
assertion is populated. assertion is populated.
All other fields MAY be omitted in the voucher request. All other fields MAY be omitted in the Pledge voucher-request.
An example JSON payload of a voucher request from a Pledge is in An example JSON payload of a Pledge voucher-request is in Section 3.2
Section 3.2 Example 1. Example 1.
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. If the request is signed the Registrar [RFC7030] section 3.3.2. If the request is signed the Registrar
confirms the 'proximity' asserion and associated 'proximity- confirms the 'proximity' asserion and associated 'proximity-
registrar-cert' are correct. The registrar performs authorization as registrar-cert' are correct. The registrar performs authorization as
detailed in [[EDNOTE: UNRESOLVED. See Appendix D "Pledge detailed in [[EDNOTE: UNRESOLVED. See Appendix D "Pledge
Authorization"]]. If these validations fail the Registrar SHOULD Authorization"]]. If these validations fail the Registrar SHOULD
respond with an appropriate HTTP error code. respond with an appropriate HTTP error code.
If authorization is successful the Registrar obtains a voucher from If authorization is successful the Registrar obtains a voucher from
skipping to change at page 31, line 45 skipping to change at page 32, line 19
authentication and HTTP Basic or Digest authentication as described authentication and HTTP Basic or Digest authentication as described
in RFC7030 for EST clients. Implementors are advised that contacting in RFC7030 for EST clients. Implementors are advised that contacting
the MASA is to establish a secured REST connection with a web service the MASA is to establish a secured REST connection with a web service
and that there are a number of authentication models being explored and that there are a number of authentication models being explored
within the industry. Registrars are RECOMMENDED to fail gracefully within the industry. Registrars are RECOMMENDED to fail gracefully
and generate useful administrative notifications or logs in the and generate useful administrative notifications or logs in the
advent of unexpected HTTP 401 (Unauthorized) responses from the MASA. advent of unexpected HTTP 401 (Unauthorized) responses from the MASA.
5.4. Registrar Requests Voucher from MASA 5.4. Registrar Requests Voucher from MASA
When a Registrar receives a voucher request from a Pledge it in turn When a Registrar receives a Pledge voucher-request it in turn submits
requests a voucher from the MASA service. For simplicity this is a Registrar voucher-request to the MASA service. For simplicity this
defined as an optional EST message between a Registrar and an EST is defined as an optional EST message between a Registrar and an EST
server running on the MASA service although the Registrar is not server running on the MASA service although the Registrar is not
required to make use of any other EST functionality when required to make use of any other EST functionality when
communicating with the MASA service. (The MASA service MUST properly communicating with the MASA service. (The MASA service MUST properly
reject any EST functionality requests it does not wish to service; a reject any EST functionality requests it does not wish to service; a
requirement that holds for any REST 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". "/.well-known/est/requestvoucher".
The request media type is: The request media type is:
application/pkcs7-mime; smime-type=voucher-request The request is a application/pkcs7-mime; smime-type=voucher-request The voucher-
"YANG-defined JSON document that has been signed using a PKCS#7 request is a "YANG-defined JSON document that has been signed
structure" as described in [I-D.ietf-anima-voucher] using the JSON using a PKCS#7 structure" as described in [I-D.ietf-anima-voucher]
encoding described in [RFC7951]. The Registrar MUST sign the using the JSON encoding described in [RFC7951]. The Registrar
request. The entire Registrar certificate chain, up to and MUST sign the Registrar voucher-request. The entire Registrar
including the Domain CA, MUST be included in the PKCS#7 structure. certificate chain, up to and including the Domain CA, MUST be
included in the PKCS#7 structure.
For simplicity the term 'voucher request' is used. MASA MASA impementations SHOULD anticipate future media types but of
impementations SHOULD anticipate future media types but of course course will simply fail the request if those types are not yet known.
will simply fail the request if those types are not yet known.
The Registrar populates the voucher request fields as follows: The Registrar populates the voucher-request fields as follows:
created-on: Registrars are RECOMMENDED to populate this field. This created-on: Registrars are RECOMMENDED to populate this field. This
provides additional information to the MASA. provides additional information to the MASA.
nonce: The optional nonce value from the Pledge request if desired nonce: The optional nonce value from the Pledge request if desired
(see below). (see below).
serial-number: The serial number of the Pledge the Registrar would serial-number: The serial number of the Pledge the Registrar would
like a voucher for. like a voucher for.
idevid-issuer: The idevid-issuer value from the pledge certificate idevid-issuer: The idevid-issuer value from the pledge certificate
is included to ensure a statistically unique identity. The is included to ensure a statistically unique identity. The
Pledge's serial number is extracted from the X.509 IDevID. See Pledge's serial number is extracted from the X.509 IDevID. See
Section 2.3. Section 2.3.
prior-signed-voucher: If the Pledge provided a signed voucher prior-signed-voucher: If a signed Pledge voucher-request was
request then it SHOULD be included in the voucher request built by received then it SHOULD be included in the Registrar voucher-
the Registrar. (NOTE: this is the Pledge's complete voucher request. (NOTE: what is included is the complete Pledge voucher-
request, inclusive of the 'assertion', 'proximity-registrar-cert', request, inclusive of the 'assertion', 'proximity-registrar-cert',
etc wrapped by the pledge's original PKCS#7 signature). etc wrapped by the pledge's original signature).
A Registrar MAY exclude the nonce from the voucher request it submits A nonceless Registrar voucher-request MAY be submitted to the MASA.
to the MASA. Doing so allows the Registrar to request a Voucher when Doing so allows the Registrar to request a Voucher when the Pledge is
the Pledge is offline, or when the Registrar is expected to be offline, or when the Registrar is expected to be offline when the
offline when the Pledge is being deployed. These use cases require Pledge is being deployed. These use cases require the Registrar to
the Registrar to learn the appropriate IDevID SerialNumber field from learn the appropriate IDevID SerialNumber field from the physical
the physical device labeling or from the sales channel (out-of-scope device labeling or from the sales channel (out-of-scope of this
of this document). If a nonce is not provided the MASA server MUST document). If a nonceless voucher-reqeust is submitted the MASA
authenticate the Registrar as described in EST [RFC7030] section server MUST authenticate the Registrar as described in either EST
3.3.2 to reduce the risk of DDoS attacks and to provide an [RFC7030] section 3.2, section 3.3, or by validating the Registrar's
authenticated identity as an input to sales channel integration and certificate used to sign the Registrar voucher-request. Any of these
authorizations (also out-of-scope of this document). methods reduce the risk of DDoS attacks and provide an authenticated
identity as an input to sales channel integration and authorizations
(the actual sale-channel integration is also out-of-scope of this
document).
All other fields MAY be omitted in the voucher request. All other fields MAY be omitted in the Registrar voucher-request.
Example JSON payloads of voucher requests from a Registrar are in Example JSON payloads of Registrar voucher-requests are in
Section 3.2 Example 2 through 4. Section 3.2 Example 2 through 4.
The MASA verifies that the voucher request is internally consistent The MASA verifies that the Registrar voucher-request is internally
but does not authenticate the registrar certificate since the consistent but does not necessarily authenticate the Registrar
registrar is not know to the MASA server in advance. The MASA certificate since the registrar is not know to the MASA server in
validation checks before issuing a voucher are as follows: advance. The MASA validation checks before issuing a voucher are as
follows:
Renew for expired voucher: As described in [I-D.ietf-anima-voucher] Renew for expired voucher: As described in [I-D.ietf-anima-voucher]
vouchers are normally short lived to avoid revocation issues. If vouchers are normally short lived to avoid revocation issues. If
the request is for a previous (expired) voucher using the same the request is for a previous (expired) voucher using the same
Registrar (as determined by the Registrar pinned-domain-cert) and Registrar (as determined by the Registrar pinned-domain-cert) and
the MASA has not been informed that the claim is invalid then the the MASA has not been informed that the claim is invalid then the
request for a renewed voucher SHOULD be automatically authorized. request for a renewed voucher SHOULD be automatically authorized.
Voucher signature consistency: The MASA MUST verify that the voucher Voucher signature consistency: The MASA MUST verify that the
request is signed by a Registrar. This is confirmed by verifying Registrar voucher-request is signed by a Registrar. This is
that the id-kp-cmcRA extended key usage extension field (as confirmed by verifying that the id-kp-cmcRA extended key usage
detailed in EST RFC7030 section 3.6.1) exists in the certificate extension field (as detailed in EST RFC7030 section 3.6.1) exists
of the entity that signed the voucher request. This verification in the certificate of the entity that signed the Registrar
is only a consistency check that the unauthenticated domain CA voucher-request. This verification is only a consistency check
intended this to be a Registrar. Performing this check provides that the unauthenticated domain CA intended this to be a
value to domain PKI by assuring the domain administrator that the Registrar. Performing this check provides value to domain PKI by
MASA service will only respect claims from authorized Registration assuring the domain administrator that the MASA service will only
Authorities of the domain. (The requirement for the Registrar to respect claims from authorized Registration Authorities of the
include the Domain CA certificate in the signature structure was domain. (The requirement for the Registrar to include the Domain
stated above). CA certificate in the signature structure was stated above).
Registrar revocation consistency: The MASA SHOULD check for Registrar revocation consistency: The MASA SHOULD check for
revocation of the Registrar certificate. The maximum lifetime of revocation of the Registrar certificate. The maximum lifetime of
the voucher issued SHOULD NOT exceed the lifetime of the the voucher issued SHOULD NOT exceed the lifetime of the
Registrar's revocation validation (for example if the Registrar Registrar's revocation validation (for example if the Registrar
revocation status is indicated in a CRL that is valid for two revocation status is indicated in a CRL that is valid for two
weeks then that is an appropriate lifetime for the voucher). weeks then that is an appropriate lifetime for the voucher).
Because the Registar certificate authority is unknown to the MASA Because the Registar certificate authority is unknown to the MASA
in advance this is only an extended consistency check and is not in advance this is only an extended consistency check and is not
required. The maximum lifetime of the voucher issued SHOULD NOT required. The maximum lifetime of the voucher issued SHOULD NOT
exceed the lifetime of the Registrar's revocation validation (for exceed the lifetime of the Registrar's revocation validation (for
example if the Registrar revocation status is indicated in a CRL example if the Registrar revocation status is indicated in a CRL
that is valid for two weeks then that is an appropriate lifetime that is valid for two weeks then that is an appropriate lifetime
for the voucher). for the voucher).
Pledge proximity assertion: The MASA server MAY verify that the Pledge proximity assertion: The MASA server MAY verify that the
Registrar signed voucher includes the 'prior-signed-voucher' field Registrar voucher-request includes the 'prior-signed-voucher'
populated with a Pledge signed voucher that includes a 'proximity- field populated with a Pledge voucher-request that includes a
registrar-cert' that is consistent with the certificate the 'proximity-registrar-cert' that is consistent with the certificate
Registrar used to sign the voucher request. The MASA server is used to sign the Registrar voucher-request. The MASA server is
aware of which Pledge's support signing of their voucher requests aware of which Pledge's support signing of their voucher requests
and can use this information to confirm proximity of the Pledge and can use this information to confirm proximity of the Pledge
with the Registrar. with the Registrar.
The Registrar certificate chain root certificate is extracted from Registar (certificate) authentication: This only occurs if the
the signature method and used to populate the "pinned-domain-cert" of Registrar voucher-request is nonceless. As noted above the
the Voucher being issued. The domain ID (e.g. hash of the public key details concerning necessary sales-channel integration for the
of the domain) is extracted from the root certificate and is used to MASA to authenticate a Registrar certificate is out-of-scope.
update the audit log.
The Registrar's certificate chain is extracted from the signature
method and the root certificate is used to populate the "pinned-
domain-cert" of the Voucher being issued. The domainID (e.g. hash of
the root public key) is determined from the pinned-domain-cert and is
used to update the audit log.
5.5. Voucher Response 5.5. Voucher Response
The voucher response to requests from the Pledge 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 join operation is successful, the server response MUST contain If the join operation is successful, the server response MUST contain
an HTTP 200 response code. The server MUST answer with a suitable an HTTP 200 response code. The server MUST answer with a suitable
4xx or 5xx HTTP [RFC2616] error code when a problem occurs. The 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. The
response data from the MASA server MUST be a plaintext human-readable response data from the MASA server MUST be a plaintext human-readable
(ASCII, english) error message containing explanatory information (ASCII, english) error message containing explanatory information
describing why the request was rejected. describing why the request was rejected.
A 403 (Forbidden) response is appropriate if the voucher request is A 403 (Forbidden) response is appropriate if the voucher-request is
not signed correctly, stale, or if the pledge has another outstanding not signed correctly, stale, or if the pledge has another outstanding
voucher which can not be overridden. voucher which can not be overridden.
A 404 (Not Found) response is appropriate when the request is for a A 404 (Not Found) response is appropriate when the request is for a
device which is not known to the MASA. device which is not known to the MASA.
A 406 (Not Acceptable) response is appropriate if a voucher of the A 406 (Not Acceptable) response is appropriate if a voucher of the
desired type, or using the desired algorithms (as indicated by the desired type, or using the desired algorithms (as indicated by the
Accept: headers, and algorithms used in the signature) can not be Accept: headers, and algorithms used in the signature) can not be
issued, such as because the MASA knows the pledge can not process issued, such as because the MASA knows the pledge can not process
skipping to change at page 37, line 33 skipping to change at page 38, line 14
5.7. MASA authorization log Request 5.7. MASA authorization log Request
After receiving the voucher status telemetry Section 5.6, the After receiving the voucher status telemetry Section 5.6, the
Registrar SHOULD request the MASA authorization log from the MASA Registrar SHOULD request the MASA authorization log from the MASA
service using this EST extension. If a device had previously service using this EST extension. If a device had previously
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.
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". "/.well-known/est/requestauditlog".
The registrar MUST HTTP POSTs the same Voucher Request as when The Registrar MUST HTTP POSTs the same Registrar voucher-request as
requesting a Voucher. It is posted to the /requestauditlog URI it did when requesting a Voucher. It is posted to the
instead. The "idevid-issuer" and "serial-number" informs the MASA /requestauditlog URI instead. The "idevid-issuer" and "serial-
server which log is requested so the appropriate log can be prepared number" informs the MASA server which log is requested so the
for the response. Using the same media type and message minimizes appropriate log can be prepared for the response. Using the same
cryptographic and message operations although it results in media type and message minimizes cryptographic and message operations
additional network traffic. The relying MASA server implementation although it results in additional network traffic. The relying MASA
MAY leverage internal state to associate this request with the server implementation MAY leverage internal state to associate this
original, and by now already validated, voucher request so as to request with the original, and by now already validated, Registrar
avoid an extra crypto validation. voucher-request so as to avoid an extra crypto validation.
A MASA which receives a request for a device which does not exist, or
for which the requesting owner was never an owner returns an HTTP 404
("Not found") code.
Rather than returning the audit log as a response to the POST (with a
return code 200), the MASA MAY instead return a 201 ("Created")
RESTful response ([RFC7231] section 7.1) containing a URL to the
prepared (and easily cachable) audit response.
MASA servers that return URLs SHOULD take care to make the returned
URL unguessable. URLs containing a database number such as
https://example.com/auditlog/1234 or the EUI of the device such
https://example.com/auditlog/10-00-00-11-22-33, would be easily
enumerable by an attacker. It is recommended put to put some
meaningless randomly generated slug that indexes a database instead.
A MASA that returns a code 200 MAY also include a Location: header
for future reference by the Registrar.
The request media type is: The request media type is:
application/pkcs7-mime; smime-type=voucher-request The request is a application/pkcs7-mime; smime-type=voucher-request The request is a
"YANG-defined JSON document that has been signed using a PKCS#7 "YANG-defined JSON document that has been signed using a PKCS#7
structure" as described in Section 3 using the JSON encoded structure" as described in Section 3 using the JSON encoded
described in [RFC7951]. The Registrar MUST sign the request. The described in [RFC7951]. The Registrar MUST sign the request. The
entire Registrar certificate chain, up to and including the Domain entire Registrar certificate chain, up to and including the Domain
CA, MUST be included in the PKCS#7 structure. CA, MUST be included in the PKCS#7 structure.
5.7.1. MASA authorization log Response 5.7.1. MASA authorization log Response
A log data file is returned consisting of all log entries. For A log data file is returned consisting of all log entries. For
example: example:
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"<date/time of the entry>", "date":"<date/time of the entry>",
"domainID":"<domainID as extracted from the domain CA certificate "domainID":"<domainID extracted from voucher-request>",
within the CMS of the audit voucher request>", "nonce":"<any nonce if supplied (or the exact string 'NULL')>"
"nonce":"<any nonce if supplied (or the exact string 'NULL')>" },
}, {
{ "date":"<date/time of the entry>",
"date":"<date/time of the entry>", "domainID":"<domainID extracted from voucher-request>",
"domainID":"<domainID as extracted from the domain CA certificate "nonce":"<any nonce if supplied (or the exact string 'NULL')>"
within the CMS of the audit voucher request>", }
"nonce":"<any nonce if supplied (or the exact string 'NULL')>" ]
} }
]
}
Distribution of a large log is less than ideal. This structure can Distribution of a large log is less than ideal. This structure can
be optimized as follows: All nonce-less entries for the same domainID be optimized as follows: All nonceless entries for the same domainID
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 an unexpected domainID then the Pledge
of problematic imprints by the Pledge. If the log includes nonce- could have imprinted on an unexpected domain. If the log includes
less entries this is indicative of the permanent ability for the nonceless entries then any registrar in the same domain could
indicated domain to trigger a reset of the device and take over theoretically trigger a reset of the device and take over management
management of it. Equipment that is purchased pre-owned can be of the Pledge. Equipment that is purchased pre-owned can be expected
expected to have an extensive history. A Registrar MAY request logs to have an extensive history. A Registrar MAY request logs at future
at future times. A Registrar MAY be configured to ignore the history times. A Registrar MAY be configured to ignore the history of the
of the device but it is RECOMMENDED that this only be configured if device but it is RECOMMENDED that this only be configured if hardware
hardware assisted NEA [RFC5209] is supported. assisted NEA [RFC5209] is supported.
Log entries containing the Domain's ID can be compared against local Log entries can be compared against local history logs in search of
history logs in search of discrepancies. 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.
skipping to change at page 44, line 34 skipping to change at page 45, line 22
AuthorityKeyIdentifier value which would be statically configured AuthorityKeyIdentifier value which would be statically configured
on the Pledge). The Pledge MAY refuse to provide a TLS client on the Pledge). The Pledge MAY refuse to provide a TLS client
certificate (as one is not available). The Pledge SHOULD support certificate (as one is not available). The Pledge SHOULD support
HTTP-based or certificate-less TLS authentication as described in HTTP-based or certificate-less TLS authentication as described in
EST RFC7030 section 3.3.2. A Registrar MUST NOT accept EST RFC7030 section 3.3.2. A Registrar MUST NOT accept
unauthenticated New Entities unless it has been configured to do unauthenticated New Entities unless it has been configured to do
so by an administrator that has verified that only expected new so by an administrator that has verified that only expected 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 submit a nonceless voucher-requests to MASA
(by not including a nonce in the request). These Vouchers can service (by not including a nonce in the voucher-request). The
then be transmitted to the Registrar and stored until they are resulting Vouchers can then be stored by the Registrar until they
needed during bootstrapping operations. This is for use cases are needed during bootstrapping operations. This is for use
where target network is protected by an air gap and therefore can cases where target network is protected by an air gap and
not contact the MASA service during Pledge deployment. therefore can 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 nonceless log entries. This
could occur when used equipment is purchased with a valid history could occur when used equipment is purchased with a valid history
being deployed in air gap networks that required permanent being deployed in air gap networks that required permanent
Vouchers. Vouchers.
6.4. MASA security reductions 6.4. MASA security reductions
Lower security modes chosen by the MASA service effect all device Lower security modes chosen by the MASA service effect all device
deployments unless bound to the specific device identities. In which deployments unless bound to the specific device identities. In which
case these modes can be provided as additional features for specific case these modes can be provided as additional features for specific
customers. The MASA service can choose to run in less secure modes customers. The MASA service can choose to run in less secure modes
skipping to change at page 46, line 5 skipping to change at page 46, line 43
7.1. PKIX Registry 7.1. PKIX Registry
IANA is requested to register the following: IANA is requested to register the following:
This document requests a number for id-mod-MASAURLExtn2016(TBD) from This document requests a number for id-mod-MASAURLExtn2016(TBD) from
the pkix(7) id-mod(0) Registry. [[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
7.2. MIME 7.2. Voucher Status Telemetry
Type name:
Subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Interoperability considerations:
Published specification:
Applications that use this media type:
Fragment identifier considerations:
Additional information:
Deprecated alias names for this type:
Magic number(s):
File extension(s):
Macintosh file type code(s):
Person and email address to contact for further information:
Intended usage: LIMITED USED
Restrictions on usage:
Author:
Change controller:
Provisional registration? (standards tree only):
7.3. Voucher Status Telemetry
IANA is requested to create a registry entitled: _Voucher Status IANA is requested to create a registry entitled: _Voucher Status
Telemetry Attributes_. New items can be added using the Telemetry Attributes_. New items can be added using the
Specification Required. The following items are to be in the initial Specification Required. The following items are to be in the initial
registration, with this document as the reference: registration, with this document as the reference:
o version o version
o Status o Status
o Reason o Reason
o reason-context o reason-context
8. Security Considerations 8. Security Considerations
There are uses cases where the MASA could be unavailable or There are uses cases where the MASA could be unavailable or
uncooperative to the Registrar. They include planned and unplanned uncooperative to the Registrar. They include planned and unplanned
skipping to change at page 47, line 50 skipping to change at page 47, line 40
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 reflects a balance between partition resistant recovery Pledge. This reflects a balance between partition resistant recovery
and security of future bootstrapping. Registrars take the Pledge's and security of future bootstrapping. Registrars take the Pledge's
audit history into account when applying policy to new devices. audit history into account when applying policy to 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. Pledge signatures specific Pledge devices, helps to mitigate this. Pledge signatures
on the initial voucher request, as forwarded by the Registrar in the on the Pledge voucher-request, as forwarded by the Registrar in the
prior-signed-voucher field, significantly reduce this risk by prior-signed-voucher field of the Registrar voucher-request,
ensuring the MASA can confirm proximity between the Pledge and the significantly reduce this risk by ensuring the MASA can confirm
Registrar making the request. This mechanism is optional to allow proximity between the Pledge and the Registrar making the request.
for constrained devices. This mechanism is optional to allow for constrained devices.
It is possible for an attacker to request a voucher from the MASA
service directly after the real Registrar obtains an audit log. If
the attacker could also force the bootstrapping protocol to reset
there is a theoretical opportunity for the attacker to use their
voucher to take control of the Pledge but then proceed to enroll with
the target domain. Possible prevention mechanisms include:
o Per device rate limits on the MASA service ensure such timing
attacks are difficult.
o The Registrar can repeat the request for audit log information at
some time after bootstrapping is complete.
To facilitate logging and administrative oversight the Pledge reports To facilitate logging and administrative oversight in addition to
triggering Registration verification of MASA logs 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 mandated anyway because of the operational benefits of an
an informed administrator in cases where the failure is indicative of informed administrator in cases where the failure is indicative of a
a problem. problem. The Registrar is RECOMMENDED to verify MASA logs if voucher
status telemetry is not received.
The MASA authorization log includes a hash of the domainID for each
registrar a voucher has been issued to. This information is closely
related to the actual domain identity, especially when paired with
the anti-DDoS authentication information the MASA might collect.
This could provide sufficient information for the MASA service to
build a detailed understanding the devices that have been provisioned
within a domain. There are a number of design choices that mitigate
this risk. The domain can maintain some privacy since it has not
necessarily been authenticated and is not authoritatively bound to
the supply chain. Additionally the domainID captures only the
unauthenticated subject key identifier of the domain. A privacy
sensitive domain could theoretically generate a new domainID for each
device being deployed. Similarly a privacy sensitive domain would
likely purchase devices that support proximity assertions from a
vendor that does not require sales channel integrations. This would
result in a significant level of privacy while maintaining the
security characteristics provided by Registrar based audit log
inspection.
To facilitate truely limited clients EST RFC7030 section 3.3.2 To facilitate truely limited clients EST RFC7030 section 3.3.2
requirements that the client MUST support a client authentication requirements that the client MUST support a client authentication
model have been reduced in Section 6 to a statement that the model have been reduced in Section 6 to a statement that the
Registrar "MAY" choose to accept devices that fail cryptographic Registrar "MAY" choose to accept devices that fail cryptographic
authentication. This reflects current (poor) practices in shipping authentication. This reflects current (poor) practices in shipping
devices without a cryptographic identity that are NOT RECOMMENDED. devices without a cryptographic identity that are NOT RECOMMENDED.
During the provisional period of the connection all HTTP header and During the provisional period of the connection the Pledge MUST treat
content data MUST treated as untrusted data. HTTP libraries are all HTTP header and content data as untrusted data. HTTP libraries
regularly exposed to non-secured HTTP traffic: mature libraries are regularly exposed to non-secured HTTP traffic: mature libraries
should not have any problems. should not have any problems.
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 multiple
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
device. This is not a failure and the Pledge choses whichever device. This is not a failure and the Pledge choses whichever
voucher to accept based on internal logic. The Registrar's verifying voucher to accept based on internal logic. The Registrar's verifying
log information will see multiple entries and take this into account log information will see multiple entries and take this into account
for their analytics purposes. for their analytics purposes.
8.1. Freshness in Voucher Requests 8.1. Freshness in Voucher-Requests
A concern has been raised that the voucher request produced by the A concern has been raised that the Pledge voucher-request should
Pledge should contain some content (a nonce) from the Registrar and/ contain some content (a nonce) provided by the Registrar and/or MASA
or MASA in order for those actors to verify that the voucher request in order for those actors to verify that the Pledge voucher-request
is fresh. is fresh.
There are a number of operational problems with getting a nonce from There are a number of operational problems with getting a nonce from
the MASA to the pledge. It is somewhat easier to collect a random the MASA to the pledge. It is somewhat easier to collect a random
value from the Registrar, but as the Registrar is not yet vouched value from the Registrar, but as the Registrar is not yet vouched
for, such a Registrar nonce has little value. There are privacy and for, such a Registrar nonce has little value. There are privacy and
logistical challenges to addressing these operational issues, so if logistical challenges to addressing these operational issues, so if
such a thing were to be considered, it would have to provide some such a thing were to be considered, it would have to provide some
clear value. This section examines the impacts of not having a fresh clear value. This section examines the impacts of not having a fresh
voucher request from the pledge. Pledge voucher-request.
Because the Registrar authenticates the Pledge a full Man-in-the- Because the Registrar authenticates the Pledge a full Man-in-the-
Middle attack is not possible, despite the provisional TLS Middle attack is not possible, despite the provisional TLS
authentication by the Pledge (see Section 5). Instead we examine the authentication by the Pledge (see Section 5). Instead we examine the
case of a fake Registrar (Rm) that communicates with the Pledge in case of a fake Registrar (Rm) that communicates with the Pledge in
parallel or in close time proximity with the intended Registrar. parallel or in close time proximity with the intended Registrar.
(This scenario is intentionally supported as described in (This scenario is intentionally supported as described in
Section 4.1). Section 4.1).
The fake Registrar (Rm) can obtain a voucher signed by the MASA The fake Registrar (Rm) can obtain a voucher signed by the MASA
either directly or through arbitrary intermediaries. Assuming that either directly or through arbitrary intermediaries. Assuming that
the MASA accepts the voucher request (either because Rm is the MASA accepts the Registar voucher-request (either because Rm is
collaborating with a legitimate Registrar according to supply chain collaborating with a legitimate Registrar according to supply chain
information, or because the MASA is in audit-log only mode), then a information, or because the MASA is in audit-log only mode), then a
voucher linking the pledge to the Registrar Rm is issued. voucher linking the pledge to the Registrar Rm is issued.
Such a voucher, when passed back to the Pledge, would link the pledge Such a voucher, when passed back to the Pledge, would link the pledge
to Registrar Rm, and would permit the Pledge to end the provisional to Registrar Rm, and would permit the Pledge to end the provisional
state. It now trusts Rm and, if it has any security vulnerabilities state. It now trusts Rm and, if it has any security vulnerabilities
leveragable by an Rm with full administrative control, can be assumed leveragable by an Rm with full administrative control, can be assumed
to be a threat against the intended Registrar. to be a threat against the intended Registrar.
This flow is mitigated by the intended Registar verifying the audit This flow is mitigated by the intended Registar verifying the audit
logs available from the MASA as described in Section 5.7. Rm might logs available from the MASA as described in Section 5.7. Rm might
chose to wait until after the intended Registrar completes the chose to wait until after the intended Registrar completes the
authorization process before submitting the now-stale voucher authorization process before submitting the now-stale Pledge voucher-
request. The Rm would need to remove the Pledge's nonce. request. The Rm would need to remove the Pledge's nonce.
In order to successfully use the resulting "stale voucher" Rm would In order to successfully use the resulting "stale voucher" Rm would
have to attack the Pledge and return it to a bootstrapping enabled have to attack the Pledge and return it to a bootstrapping enabled
state. This would require wiping the Pledge of current configuration state. This would require wiping the Pledge of current configuration
and triggering a re-bootstrapping of the Pledge. This is no more and triggering a re-bootstrapping of the Pledge. This is no more
likely than simply taking control of the Pledge directly but if this likely than simply taking control of the Pledge directly but if this
is a consideration the target network is RECOMMENDED to take the is a consideration the target network is RECOMMENDED to take the
following steps: following steps:
skipping to change at page 50, line 27 skipping to change at page 50, line 25
particular Brian Carpenter, Toerless Eckert, Fuyu Eleven, Eliot Lear, particular Brian Carpenter, Toerless Eckert, Fuyu Eleven, Eliot Lear,
Sergey Kasatkin, Markus Stenberg, and Peter van der Stok Sergey Kasatkin, Markus Stenberg, and Peter van der Stok
10. References 10. References
10.1. Normative References 10.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 (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-10 (work in progress), September 2017. plane-12 (work in progress), October 2017.
[I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 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-05 (work in progress), August 2017. anima-voucher-06 (work in progress), October 2017.
[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", [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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 52, line 39 skipping to change at page 52, line 39
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
10.2. Informative References 10.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]
Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017.
[I-D.ietf-netconf-zerotouch] [I-D.ietf-netconf-zerotouch]
Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch
Provisioning for NETCONF or RESTCONF based Management", Provisioning for NETCONF or RESTCONF based Management",
draft-ietf-netconf-zerotouch-17 (work in progress), draft-ietf-netconf-zerotouch-19 (work in progress),
September 2017. October 2017.
[I-D.ietf-opsawg-mud] [I-D.ietf-opsawg-mud]
Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", draft-ietf-opsawg-mud-12 (work Description Specification", draft-ietf-opsawg-mud-13 (work
in progress), October 2017. in progress), October 2017.
[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.
[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.
[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, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://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,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
skipping to change at page 59, line 5 skipping to change at page 59, line 5
MASA URL."; MASA URL.";
leaf masa-server { leaf masa-server {
type inet:uri; type inet:uri;
description description
"This value is the URI of the MASA server"; "This value is the URI of the MASA server";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Appendix E. Example Vouchers
Three entities are involved in a voucher: the MASA issues (signs) it,
the registrar's public key is mentioned in the voucher, and the
pledge validates it. In order to provide reproduceable examples the
public and private keys for an example MASA and Registrar are first
listed.
E.1. Keys involved
The Manufacturer has a Certificate Authority that signs the Pledge's
IDevID. In addition the Manufacturer's signing authority (the MASA)
signs the vouchers, and that certificate must distributed to the
devices at manufacturing time so that vouchers can be validated.
E.1.1. MASA key pair for voucher signatures
This private key signs vouchers:
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho
r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA
zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz
Tvv+5PV++elkP9HQ83vqTAws2WwWTxI=
-----END EC PRIVATE KEY-----
This public key validates vouchers:
-----BEGIN CERTIFICATE-----
MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC
Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n
IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw
EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU
BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R
b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf
w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO
MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O
DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd
MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw=
-----END CERTIFICATE-----
E.1.2. Manufacturer key pair for IDevID signatures
This private key signs IDevID certificates:
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho
r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA
zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz
Tvv+5PV++elkP9HQ83vqTAws2WwWTxI=
-----END EC PRIVATE KEY-----
This public key validates IDevID certificates:
-----BEGIN CERTIFICATE-----
MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC
Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n
IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw
EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU
BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R
b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf
w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO
MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O
DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd
MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw=
-----END CERTIFICATE-----
E.1.3. Registrar key pair
The registrar key (or chain) is the representative of the domain
owner. This key signs Registrar voucher-requests:
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49
AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g
6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg==
-----END EC PRIVATE KEY-----
The public key is indicated in a pledge voucher-request to show
proximity.
-----BEGIN CERTIFICATE-----
MIIBrjCCATOgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYC
Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5n
IEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES
MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRIw
EAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ1ZA7N
w0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/puhObJMZ0U6H/
wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49BAMDA2kAMGYCMQC3
/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNifVKtyaara3F30AIkKSEC
MQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYR
c3o=
-----END CERTIFICATE-----
The registrar public certificate as decoded by openssl's x509
utility. Note that the registrar certificate is marked with the
cmcRA extension.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: ecdsa-with-SHA384
Issuer: DC=ca, DC=sandelman, CN=Unstrung Fountain CA
Validity
Not Before: Sep 5 01:12:45 2017 GMT
Not After : Sep 5 01:12:45 2019 GMT
Subject: DC=ca, DC=sandelman, CN=localhost
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
EC Public Key:
pub:
04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7
8:17:
34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5
3:3e:
03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e
9:ba:
13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2
f:96:
e9:9d:e2:bc:b2
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Signature Algorithm: ecdsa-with-SHA384
30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78:5
b:
9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e:b
6:
9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21:0
2:
31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa:c
3:
ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53:4
b:
83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a
E.1.4. Pledge key pair
The pledge has an IDevID key pair built in at manufacturing time:
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIL+ue8PQcN+M7LFBGPsompYwobI/rsoHnTb2a+0hO+8joAoGCCqGSM49
AwEHoUQDQgAEumBVaDlX87WyME8CJToyt9NWy6sYw0DTbjjJIn79pgr7ALa//Y8p
r70WpK1SIaiUeeFw7e+lCzTp1Z+wJu14Bg==
-----END EC PRIVATE KEY-----
The public key is used by the registrar to find the MASA. The MASA
URL is in an extension described in Section 2.3. RFC-EDITOR: Note
that these certificates are using a Private Enterprise Number for the
not-yet-assigned by IANA MASA URL, and need to be replaced before
AUTH48.
-----BEGIN CERTIFICATE-----
MIICMjCCAbegAwIBAgIBDDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC
Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n
IEhpZ2h3YXkgQ0EwIBcNMTcxMDEyMTM1MjUyWhgPMjk5OTEyMzEwMDAwMDBaMEsx
EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEa
MBgGA1UEAwwRMDAtRDAtRTUtRjItMDAtMDIwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAARJp5i0dU1aUnR2u8wMRwgkNupNbNM7m1n0mj+0KJZjcPIqID+trPjTSobt
uIdpRPfGZ8hU/nIUveqwyoYI8BPbo4GHMIGEMB0GA1UdDgQWBBQdMRZhthFQmzz6
E7YVXzkL7XZDKjAJBgNVHRMEAjAAMCsGA1UdEQQkMCKgIAYJKwYBBAGC7lIBoBMM
ETAwLUQwLUU1LUYyLTAwLTAyMCsGCSsGAQQBgu5SAgQeDBxodHRwczovL2hpZ2h3
YXkuc2FuZGVsbWFuLmNhMAoGCCqGSM49BAMCA2kAMGYCMQDhJ1N+eanW1U/e5qoM
SGvUvWHR7uic8cJbh7vXy580nBs8bpNn60k/+IzvEUetMzICMQCr1uxvdYeKq7mb
RXCR4ZCJsw67fJ7jyXZbCUSir+3wBT2+lWggzPDRgYB5ABb7sAw=
-----END CERTIFICATE-----
The pledge public certificate as decoded by openssl's x509 utility so
that the extensions can be seen. A second custom Extension is
included to provided to contain the EUI48/EUI64 that the pledge will
configure.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12 (0xc)
Signature Algorithm: ecdsa-with-SHA256
Issuer: DC=ca, DC=sandelman, CN=Unstrung Highway CA
Validity
Not Before: Oct 12 13:52:52 2017 GMT
Not After : Dec 31 00:00:00 2999 GMT
Subject: DC=ca, DC=sandelman, CN=00-D0-E5-F2-00-02
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
EC Public Key:
pub:
04:49:a7:98:b4:75:4d:5a:52:74:76:bb:cc:0
c:47:
08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b
4:28:
96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e
d:b8:
87:69:44:f7:c6:67:c8:54:fe:72:14:bd:ea:b
0:ca:
86:08:f0:13:db
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Subject Key Identifier:
1D:31:16:61:B6:11:50:9B:3C:FA:13:B6:15:5F:39
:0B:ED:76:43:2A
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Alternative Name:
othername:<unsupported>
1.3.6.1.4.1.46930.2:
..https://highway.sandelman.ca
Signature Algorithm: ecdsa-with-SHA256
30:66:02:31:00:e1:27:53:7e:79:a9:d6:d5:4f:de:e6:aa:0
c:
48:6b:d4:bd:61:d1:ee:e8:9c:f1:c2:5b:87:bb:d7:cb:9f:3
4:
9c:1b:3c:6e:93:67:eb:49:3f:f8:8c:ef:11:47:ad:33:32:0
2:
31:00:ab:d6:ec:6f:75:87:8a:ab:b9:9b:45:70:91:e1:90:8
9:
b3:0e:bb:7c:9e:e3:c9:76:5b:09:44:a2:af:ed:f0:05:3d:b
e:
95:68:20:cc:f0:d1:81:80:79:00:16:fb:b0:0c
E.2. Example process
RFC-EDITOR: these examples will need to be replaced with CMS versions
once IANA has assigned the eContentType in [I-D.ietf-anima-voucher].
E.2.1. Pledge to Registrar
As described in Section 5.2, the pledge will sign a pledge voucher-
request containing the Registrar's public key in the proximity-
registrar-cert field. The base64 has been wrapped at 60 characters
for presentation reasons.
MIIHHAYJKoZIhvcNAQcCoIIHDTCCBwkCAQExDzANBglghkgBZQMEAgEFADCC
Aw4GCSqGSIb3DQEHAaCCAv8EggL7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2
b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i
OiIyMDE3LTA5LTAxIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAw
LTAyIiwibm9uY2UiOiJEc3M5OXNCcjNwTk1PQUNlLUxZWTd3IiwicHJveGlt
aXR5LXJlZ2lzdHJhci1jZXJ0IjoiTUlJQnJqQ0NBVE9nQXdJQkFnSUJBekFL
QmdncWhrak9QUVFEQXpCT01SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhH
VEFYQmdvSmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhIVEFiQmdOVkJB
TU1GRlZ1YzNSeWRXNW5JRVp2ZFc1MFlXbHVJRU5CTUI0WERURTNNRGt3TlRB
eE1USTBOVm9YRFRFNU1Ea3dOVEF4TVRJME5Wb3dRekVTTUJBR0NnbVNKb21U
OGl4a0FSa1dBbU5oTVJrd0Z3WUtDWkltaVpQeUxHUUJHUllKYzJGdVpHVnNi
V0Z1TVJJd0VBWURWUVFEREFsc2IyTmhiR2h2YzNRd1dUQVRCZ2NxaGtqT1BR
SUJCZ2dxaGtqT1BRTUJCd05DQUFRMVpBN053MHhTTS9RMnUxOTRGelFNa3Ra
OTR3YUFJVjBpL29WVFBnT0o4elc2TXdGNXorRHBiOC9wdWhPYkpNWjBVNkgv
d2ZBcFI2c3ZsdW1kNHJ5eW93MHdDekFKQmdOVkhSTUVBakFBTUFvR0NDcUdT
TTQ5QkFNREEya0FNR1lDTVFDMy9pVFFKM2V2WVljZ2JYaGJtenJwNjR0M1FD
NnFqSWVZMmprRHgwNjJudU5pZlZLdHlhYXJhM0YzMEFJa0tTRUNNUURpMjll
ZmJUTGJkdERrM3RlY1kvckQ3Vjc3WGFKNm5ZQ21kRENSNTRUclNGTkxneHZ0
MWx5Rk0rMGZZcFlSYzNvPSJ9faCCAjYwggIyMIIBt6ADAgECAgEMMAoGCCqG
SM49BAMCME0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkW
CXNhbmRlbG1hbjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQTAgFw0x
NzEwMTIxMzUyNTJaGA8yOTk5MTIzMTAwMDAwMFowSzESMBAGCgmSJomT8ixk
ARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRowGAYDVQQDDBEw
MC1EMC1FNS1GMi0wMC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEmn
mLR1TVpSdHa7zAxHCCQ26k1s0zubWfSaP7QolmNw8iogP62s+NNKhu24h2lE
98ZnyFT+chS96rDKhgjwE9ujgYcwgYQwHQYDVR0OBBYEFB0xFmG2EVCbPPoT
thVfOQvtdkMqMAkGA1UdEwQCMAAwKwYDVR0RBCQwIqAgBgkrBgEEAYLuUgGg
EwwRMDAtRDAtRTUtRjItMDAtMDIwKwYJKwYBBAGC7lICBB4MHGh0dHBzOi8v
aGlnaHdheS5zYW5kZWxtYW4uY2EwCgYIKoZIzj0EAwIDaQAwZgIxAOEnU355
qdbVT97mqgxIa9S9YdHu6JzxwluHu9fLnzScGzxuk2frST/4jO8RR60zMgIx
AKvW7G91h4qruZtFcJHhkImzDrt8nuPJdlsJRKKv7fAFPb6VaCDM8NGBgHkA
FvuwDDGCAaUwggGhAgEBMFIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK
CZImiZPyLGQBGRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdo
d2F5IENBAgEMMA0GCWCGSAFlAwQCAQUAoIHkMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTAxMjE3NTQzMFowLwYJKoZI
hvcNAQkEMSIEIP59cuKVAPkKOOlQIaIV/W1AsWKbmVmBd9wFSuD5yLafMHkG
CSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglg
hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3
DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSM49BAMCBEYw
RAIgYUy0NTdP+xTkm/Et69eI++S/2z3dQwPKOwdL0cDCSvACIAh3jJbybMnK
cf7DKKnsn2G/O06HeB/8imMI+hnA7CfN
file: examples/vr_00-D0-E5-F2-00-02.pkcs
The ASN1 decoding of the artifact:
The JSON contained in the voucher request:
E.2.2. Registrar to MASA
As described in Section 5.4 the Registrar will sign a registrar
voucher-request, and will include pledge's voucher request in the
prior-signed-voucher-request.
MIIN2gYJKoZIhvcNAQcCoIINyzCCDccCAQExDzANBglghkgBZQMEAgEFADCC
Ck4GCSqGSIb3DQEHAaCCCj8Eggo7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2
b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i
OiIyMDE3LTA5LTE1VDAwOjAwOjAwLjAwMFoiLCJzZXJpYWwtbnVtYmVyIjoi
SkFEQTEyMzQ1Njc4OSIsIm5vbmNlIjoiYWJjZDEyMzQiLCJwcmlvci1zaWdu
ZWQtdm91Y2hlci1yZXF1ZXN0IjoiTUlJSEhRWUpLb1pJaHZjTkFRY0NvSUlI
RGpDQ0J3b0NBUUV4RHpBTkJnbGdoa2dCWlFNRUFnRUZBRENDQXc0R0NTcUdT
SWIzRFFFSEFhQ0NBdjhFZ2dMN2V5SnBaWFJtTFhadmRXTm9aWEl0Y21WeGRX
VnpkRHAyYjNWamFHVnlJanA3SW1GemMyVnlkR2x2YmlJNkluQnliM2hwYlds
MGVTSXNJbU55WldGMFpXUXRiMjRpT2lJeU1ERTNMVEE1TFRBeElpd2ljMlZ5
YVdGc0xXNTFiV0psY2lJNklqQXdMVVF3TFVVMUxVWXlMVEF3TFRBeUlpd2li
bTl1WTJVaU9pSkVjM001T1hOQ2NqTndUazFQUVVObExVeFpXVGQzSWl3aWNI
SnZlR2x0YVhSNUxYSmxaMmx6ZEhKaGNpMWpaWEowSWpvaVRVbEpRbkpxUTBO
QlZFOW5RWGRKUWtGblNVSkJla0ZMUW1kbmNXaHJhazlRVVZGRVFYcENUMDFT
U1hkRlFWbExRMXBKYldsYVVIbE1SMUZDUjFKWlExa3lSWGhIVkVGWVFtZHZT
bXRwWVVwckwwbHpXa0ZGV2tabmJIcFpWelZyV2xkNGRGbFhOSGhJVkVGaVFt
ZE9Wa0pCVFUxR1JsWjFZek5TZVdSWE5XNUpSVnAyWkZjMU1GbFhiSFZKUlU1
Q1RVSTBXRVJVUlROTlJHdDNUbFJCZUUxVVNUQk9WbTlZUkZSRk5VMUVhM2RP
VkVGNFRWUkpNRTVXYjNkUmVrVlRUVUpCUjBObmJWTktiMjFVT0dsNGEwRlNh
MWRCYlU1b1RWSnJkMFozV1V0RFdrbHRhVnBRZVV4SFVVSkhVbGxLWXpKR2RW
cEhWbk5pVjBaMVRWSkpkMFZCV1VSV1VWRkVSRUZzYzJJeVRtaGlSMmgyWXpO
UmQxZFVRVlJDWjJOeGFHdHFUMUJSU1VKQ1oyZHhhR3RxVDFCUlRVSkNkMDVE
UVVGUk1WcEJOMDUzTUhoVFRTOVJNblV4T1RSR2VsRk5hM1JhT1RSM1lVRkpW
akJwTDI5V1ZGQm5UMG80ZWxjMlRYZEdOWG9yUkhCaU9DOXdkV2hQWWtwTldq
QlZOa2d2ZDJaQmNGSTJjM1pzZFcxa05ISjVlVzkzTUhkRGVrRktRbWRPVmto
U1RVVkJha0ZCVFVGdlIwTkRjVWRUVFRRNVFrRk5SRUV5YTBGTlIxbERUVkZE
TXk5cFZGRktNMlYyV1ZsaloySllhR0p0ZW5Kd05qUjBNMUZETm5GcVNXVlpN
bXByUkhnd05qSnVkVTVwWmxaTGRIbGhZWEpoTTBZek1FRkphMHRUUlVOTlVV
UnBNamxsWm1KVVRHSmtkRVJyTTNSbFkxa3Zja1EzVmpjM1dHRktObTVaUTIx
a1JFTlNOVFJVY2xOR1RreG5lSFowTVd4NVJrMHJNR1paY0ZsU1l6TnZQU0o5
ZmFDQ0FqWXdnZ0l5TUlJQnQ2QURBZ0VDQWdFTU1Bb0dDQ3FHU000OUJBTUNN
RTB4RWpBUUJnb0praWFKay9Jc1pBRVpGZ0pqWVRFWk1CY0dDZ21TSm9tVDhp
eGtBUmtXQ1hOaGJtUmxiRzFoYmpFY01Cb0dBMVVFQXd3VFZXNXpkSEoxYm1j
Z1NHbG5hSGRoZVNCRFFUQWdGdzB4TnpFd01USXhNelV5TlRKYUdBOHlPVGs1
TVRJek1UQXdNREF3TUZvd1N6RVNNQkFHQ2dtU0pvbVQ4aXhrQVJrV0FtTmhN
Umt3RndZS0NaSW1pWlB5TEdRQkdSWUpjMkZ1WkdWc2JXRnVNUm93R0FZRFZR
UUREQkV3TUMxRU1DMUZOUzFHTWkwd01DMHdNakJaTUJNR0J5cUdTTTQ5QWdF
R0NDcUdTTTQ5QXdFSEEwSUFCRW1ubUxSMVRWcFNkSGE3ekF4SENDUTI2azFz
MHp1YldmU2FQN1FvbG1Odzhpb2dQNjJzK05OS2h1MjRoMmxFOThabnlGVCtj
aFM5NnJES2hnandFOXVqZ1ljd2dZUXdIUVlEVlIwT0JCWUVGQjB4Rm1HMkVW
Q2JQUG9UdGhWZk9RdnRka01xTUFrR0ExVWRFd1FDTUFBd0t3WURWUjBSQkNR
d0lxQWdCZ2tyQmdFRUFZTHVVZ0dnRXd3Uk1EQXRSREF0UlRVdFJqSXRNREF0
TURJd0t3WUpLd1lCQkFHQzdsSUNCQjRNSEdoMGRIQnpPaTh2YUdsbmFIZGhl
UzV6WVc1a1pXeHRZVzR1WTJFd0NnWUlLb1pJemowRUF3SURhUUF3WmdJeEFP
RW5VMzU1cWRiVlQ5N21xZ3hJYTlTOVlkSHU2Snp4d2x1SHU5ZkxuelNjR3p4
dWsyZnJTVC80ak84UlI2MHpNZ0l4QUt2VzdHOTFoNHFydVp0RmNKSGhrSW16
RHJ0OG51UEpkbHNKUktLdjdmQUZQYjZWYUNETThOR0JnSGtBRnZ1d0RER0NB
YVl3Z2dHaUFnRUJNRkl3VFRFU01CQUdDZ21TSm9tVDhpeGtBUmtXQW1OaE1S
a3dGd1lLQ1pJbWlaUHlMR1FCR1JZSmMyRnVaR1ZzYldGdU1Sd3dHZ1lEVlFR
RERCTlZibk4wY25WdVp5QklhV2RvZDJGNUlFTkJBZ0VNTUEwR0NXQ0dTQUZs
QXdRQ0FRVUFvSUhrTUJnR0NTcUdTSWIzRFFFSkF6RUxCZ2txaGtpRzl3MEJC
d0V3SEFZSktvWklodmNOQVFrRk1ROFhEVEUzTVRBeE1qRXpOVGd5TTFvd0x3
WUpLb1pJaHZjTkFRa0VNU0lFSVA1OWN1S1ZBUGtLT09sUUlhSVYvVzFBc1dL
Ym1WbUJkOXdGU3VENXlMYWZNSGtHQ1NxR1NJYjNEUUVKRHpGc01Hb3dDd1lK
WUlaSUFXVURCQUVxTUFzR0NXQ0dTQUZsQXdRQkZqQUxCZ2xnaGtnQlpRTUVB
UUl3Q2dZSUtvWklodmNOQXdjd0RnWUlLb1pJaHZjTkF3SUNBZ0NBTUEwR0ND
cUdTSWIzRFFNQ0FnRkFNQWNHQlNzT0F3SUhNQTBHQ0NxR1NJYjNEUU1DQWdF
b01Bb0dDQ3FHU000OUJBTUNCRWN3UlFJZ0VNZzFkSkw3RmNkdHJWRHg4cUNh
em9lOSsyMk56NFp3UkI5Z0FUR0w3TU1DSVFEanNzVWxaekpxcDIva0NkNFdo
eFVoc2FDcFRGd1Bybk5ldzV3Q2tZVUY4UT09In19oIIBsjCCAa4wggEzoAMC
AQICAQMwCgYIKoZIzj0EAwMwTjESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK
CZImiZPyLGQBGRYJc2FuZGVsbWFuMR0wGwYDVQQDDBRVbnN0cnVuZyBGb3Vu
dGFpbiBDQTAeFw0xNzA5MDUwMTEyNDVaFw0xOTA5MDUwMTEyNDVaMEMxEjAQ
BgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjES
MBAGA1UEAwwJbG9jYWxob3N0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
NWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g6W/P6boT
myTGdFOh/8HwKUerL5bpneK8sqMNMAswCQYDVR0TBAIwADAKBggqhkjOPQQD
AwNpADBmAjEAt/4k0Cd3r2GHIG14W5s66euLd0AuqoyHmNo5A8dOtp7jYn1S
rcmmq2txd9ACJCkhAjEA4tvXn20y23bQ5N7XnGP6w+1e+12iep2ApnQwkeeE
60hTS4Mb7dZchTPtH2KWEXN6MYIBpzCCAaMCAQEwUzBOMRIwEAYKCZImiZPy
LGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMM
FFVuc3RydW5nIEZvdW50YWluIENBAgEDMA0GCWCGSAFlAwQCAQUAoIHkMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTAy
NjAxMzYxOFowLwYJKoZIhvcNAQkEMSIEIEQBM73PZzPo7tE9Mj8gQvaaYeMQ
OsxlACaW/HenAqNwMHkGCSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsG
CWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MAoGCCqGSM49BAMCBEcwRQIgDdp5uPUlMKp7GFQAD7ypAgqFv8q+KkJt6c3O
7iVpVI8CIQCD1u8BkxipvigwvIDmWfjlYdJxcvozNjffq5j3UHg7Rg==
file: examples/parboiled_vr_00-D0-E5-F2-00-02.pkcs
The ASN1 decoding of the artifact:
E.2.3. MASA to Registrar
The MASA will return a voucher to the Registrar, to be relayed to the
pledge.
MIIG3AYJKoZIhvcNAQcCoIIGzTCCBskCAQExDzANBglghkgBZQMEAgEFADCC
AxAGCSqGSIb3DQEHAaCCAwEEggL9eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6
eyJhc3NlcnRpb24iOiJsb2dnZWQiLCJjcmVhdGVkLW9uIjoiMjAxNy0xMC0x
MlQxMzo1NDozMS40MzktMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtRDAt
RTUtRjItMDAtMDIiLCJub25jZSI6IkRzczk5c0JyM3BOTU9BQ2UtTFlZN3ci
LCJwaW5uZWQtZG9tYWluLWNlcnQiOiJNSUlCcmpDQ0FUT2dBd0lCQWdJQkF6
QUtCZ2dxaGtqT1BRUURBekJPTVJJd0VBWUtDWkltaVpQeUxHUUJHUllDWTJF
eEdUQVhCZ29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0eEhUQWJCZ05W
QkFNTUZGVnVjM1J5ZFc1bklFWnZkVzUwWVdsdUlFTkJNQjRYRFRFM01Ea3dO
VEF4TVRJME5Wb1hEVEU1TURrd05UQXhNVEkwTlZvd1F6RVNNQkFHQ2dtU0pv
bVQ4aXhrQVJrV0FtTmhNUmt3RndZS0NaSW1pWlB5TEdRQkdSWUpjMkZ1WkdW
c2JXRnVNUkl3RUFZRFZRUUREQWxzYjJOaGJHaHZjM1F3V1RBVEJnY3Foa2pP
UFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVExWkE3TncweFNNL1EydTE5NEZ6UU1r
dFo5NHdhQUlWMGkvb1ZUUGdPSjh6VzZNd0Y1eitEcGI4L3B1aE9iSk1aMFU2
SC93ZkFwUjZzdmx1bWQ0cnl5b3cwd0N6QUpCZ05WSFJNRUFqQUFNQW9HQ0Nx
R1NNNDlCQU1EQTJrQU1HWUNNUUMzL2lUUUozZXZZWWNnYlhoYm16cnA2NHQz
UUM2cWpJZVkyamtEeDA2Mm51TmlmVkt0eWFhcmEzRjMwQUlrS1NFQ01RRGky
OWVmYlRMYmR0RGszdGVjWS9yRDdWNzdYYUo2bllDbWREQ1I1NFRyU0ZOTGd4
dnQxbHlGTSswZllwWVJjM289In19oIIB0zCCAc8wggFWoAMCAQICAQEwCgYI
KoZIzj0EAwIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQB
GRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdod2F5IENBMB4X
DTE3MDMyNjE2MTk0MFoXDTE5MDMyNjE2MTk0MFowRzESMBAGCgmSJomT8ixk
ARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRYwFAYDVQQDDA1V
bnN0cnVuZyBNQVNBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE2QB90W9hbyCT
p7bPr17llt+aH8jWwh84wMzotpFmRRNQcrqyiJjXDTBRoqxp0VyFxqlgn8OS
AoCfArjN71ebcvW3+ylJTpHo8077/uT1fvnpZD/R0PN76kwMLNlsFk8SoxAw
DjAMBgNVHRMBAf8EAjAAMAoGCCqGSM49BAMCA2cAMGQCMBm9KMjNHaD+rd/y
0jy+Tg7mrRMDGIe1hjviGExwvCuxMhwTpgmEXik9vhoVfwi1swIwTculDCU7
dbbMSbCanTD1CBY/uMGYNQDiG/yaAOjO6996cC0E6x0cRM1TBn1jpGFMMYIB
xjCCAcICAQEwUjBNMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/Is
ZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5nIEhpZ2h3YXkgQ0EC
AQEwDQYJYIZIAWUDBAIBBQCggeQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTcxMDEyMTc1NDMxWjAvBgkqhkiG9w0BCQQx
IgQgQXnG628cIW8MoYfB1ljDDlLlJQlxED2tnjcvkLEfix0weQYJKoZIhvcN
AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB
AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIzj0EAwIEZzBlAjEAhzid
/AkNjttpSP1rflNppdHsi324Z2+TXJxueewnJ8z/2NXb+Tf3DsThv7du00Oz
AjBjyOnmkkSKHsPR2JluA5c6wovuPEnNKP32daGGeFKGEHMkTInbrqipC881
/5K9Q+k=
file: examples/voucher_00-D0-E5-F2-00-02.pkcs
The ASN1 decoding of the artifact:
Authors' Addresses Authors' Addresses
Max Pritikin Max Pritikin
Cisco Cisco
Email: pritikin@cisco.com Email: pritikin@cisco.com
Michael C. Richardson Michael C. Richardson
Sandelman Software Works Sandelman Software Works
 End of changes. 89 change blocks. 
331 lines changed or deleted 769 lines changed or added

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