draft-ietf-anima-bootstrapping-keyinfra-15.txt   draft-ietf-anima-bootstrapping-keyinfra-16.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: October 28, 2018 Sandelman Expires: December 23, 2018 Sandelman
M. Behringer M. Behringer
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
K. Watsen K. Watsen
Juniper Networks Juniper Networks
April 26, 2018 June 21, 2018
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-15 draft-ietf-anima-bootstrapping-keyinfra-16
Abstract Abstract
This document specifies automated bootstrapping of a remote secure This document specifies automated bootstrapping of a remote secure
key infrastructure (BRSKI) using manufacturer installed X.509 key infrastructure (BRSKI) using manufacturer installed X.509
certificate, in combination with a manufacturer's authorizing certificate, in combination with a manufacturer's authorizing
service, both online and offline. Bootstrapping a new device can service, both online and offline. Bootstrapping a new device can
occur using a routable address and a cloud service, or using only occur using a routable address and a cloud service, or using only
link-local connectivity, or on limited/disconnected networks. link-local connectivity, or on limited/disconnected networks.
Support for lower security models, including devices with minimal Support for lower security models, including devices with minimal
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 October 28, 2018. This Internet-Draft will expire on December 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
2.8. Determining the MASA to contact . . . . . . . . . . . . . 23 2.8. Determining the MASA to contact . . . . . . . . . . . . . 23
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 24 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 24
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 25 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27
4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 30 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 30
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 31 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 31
4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 32 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 32
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 33 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 33
4.3. Proxy discovery of Registrar . . . . . . . . . . . . . . 33 4.3. Proxy discovery of Registrar . . . . . . . . . . . . . . 33
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 35 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 34
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 37 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 36
5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 38 5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 38
5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 39 5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 38
5.4.1. MASA renewal of expired vouchers . . . . . . . . . . 40 5.4.1. MASA renewal of expired vouchers . . . . . . . . . . 40
5.4.2. MASA verification of voucher-request signature 5.4.2. MASA verification of voucher-request signature
consistency . . . . . . . . . . . . . . . . . . . . . 40 consistency . . . . . . . . . . . . . . . . . . . . . 40
5.4.3. MASA authentication of registrar (certificate) . . . 41 5.4.3. MASA authentication of registrar (certificate) . . . 40
5.4.4. MASA revocation checking of registrar (certificate) . 41 5.4.4. MASA revocation checking of registrar (certificate) . 41
5.4.5. MASA verification of pledge prior-signed-voucher- 5.4.5. MASA verification of pledge prior-signed-voucher-
request . . . . . . . . . . . . . . . . . . . . . . . 41 request . . . . . . . . . . . . . . . . . . . . . . . 41
5.4.6. MASA pinning of registrar . . . . . . . . . . . . . . 41 5.4.6. MASA pinning of registrar . . . . . . . . . . . . . . 41
5.4.7. MASA nonce handling . . . . . . . . . . . . . . . . . 42 5.4.7. MASA nonce handling . . . . . . . . . . . . . . . . . 41
5.5. MASA and Registrar Voucher Response . . . . . . . . . . . 42 5.5. MASA and Registrar Voucher Response . . . . . . . . . . . 42
5.5.1. Pledge voucher verification . . . . . . . . . . . . . 44 5.5.1. Pledge voucher verification . . . . . . . . . . . . . 44
5.5.2. Pledge authentication of provisional TLS connection . 45 5.5.2. Pledge authentication of provisional TLS connection . 44
5.6. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 46 5.6. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 45
5.7. Registrar audit log request . . . . . . . . . . . . . . . 46 5.7. Registrar audit log request . . . . . . . . . . . . . . . 46
5.7.1. MASA audit log response . . . . . . . . . . . . . . . 48 5.7.1. MASA audit log response . . . . . . . . . . . . . . . 47
5.7.2. Registrar audit log verification . . . . . . . . . . 49 5.7.2. Registrar audit log verification . . . . . . . . . . 49
5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 50 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 50
5.8.1. EST Distribution of CA Certificates . . . . . . . . . 51 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 50
5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51
5.8.3. EST Client Certificate Request . . . . . . . . . . . 52 5.8.3. EST Client Certificate Request . . . . . . . . . . . 52
5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52
5.8.5. Multiple certificates . . . . . . . . . . . . . . . . 53 5.8.5. Multiple certificates . . . . . . . . . . . . . . . . 53
5.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53 5.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53
6. Reduced security operational modes . . . . . . . . . . . . . 53 6. Reduced security operational modes . . . . . . . . . . . . . 53
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 54 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 53
6.2. Pledge security reductions . . . . . . . . . . . . . . . 54 6.2. Pledge security reductions . . . . . . . . . . . . . . . 54
6.3. Registrar security reductions . . . . . . . . . . . . . . 55 6.3. Registrar security reductions . . . . . . . . . . . . . . 55
6.4. MASA security reductions . . . . . . . . . . . . . . . . 56 6.4. MASA security reductions . . . . . . . . . . . . . . . . 56
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
7.1. Well-known EST registration . . . . . . . . . . . . . . . 57 7.1. Well-known EST registration . . . . . . . . . . . . . . . 57
7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 57 7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 57
7.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 57 7.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 57
7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 58 7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 57
7.5. MUD File Extension for the MASA server . . . . . . . . . 58 7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 58
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 58 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 58
8.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 58 8.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 58
9. Security Considerations . . . . . . . . . . . . . . . . . . . 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 59
9.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 60 9.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 60
9.2. Trusting manufacturers . . . . . . . . . . . . . . . . . 61 9.2. Trusting manufacturers . . . . . . . . . . . . . . . . . 61
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 62
11.1. Normative References . . . . . . . . . . . . . . . . . . 62 11.1. Normative References . . . . . . . . . . . . . . . . . . 62
11.2. Informative References . . . . . . . . . . . . . . . . . 65 11.2. Informative References . . . . . . . . . . . . . . . . . 65
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 67 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 67
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 67 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 67
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 67 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 67
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 68 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 68
Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 68 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 68
C.1. Multiple Join networks on the Join Proxy side . . . . . . 69 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 71
C.2. Automatic configuration of tunnels on Registrar . . . . . 70 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 71
C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 70 D.1.1. MASA key pair for voucher signatures . . . . . . . . 71
C.4. Use of connected sockets; or IP_PKTINFO for CoAP on D.1.2. Manufacturer key pair for IDevID signatures . . . . . 71
Registrar . . . . . . . . . . . . . . . . . . . . . . . . 70 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 72
C.5. Use of socket extension rather than virtual interface . . 71 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 74
Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 71 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 76
Appendix E. Example Vouchers . . . . . . . . . . . . . . . . . . 73 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 76
E.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 73 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 82
E.1.1. MASA key pair for voucher signatures . . . . . . . . 73 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 87
E.1.2. Manufacturer key pair for IDevID signatures . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92
E.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 74
E.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 76
E.2. Example process . . . . . . . . . . . . . . . . . . . . . 78
E.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 78
E.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 84
E.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
1. Introduction 1. Introduction
BRSKI provides a solution for secure zero-touch (automated) bootstrap BRSKI provides a solution for secure zero-touch (automated) bootstrap
of virgin (untouched) devices that are called pledges in this of virgin (untouched) devices that are called pledges in this
document. These pledges need to discover (or be discovered by) an document. These pledges need to discover (or be discovered by) an
element of the network domain to which the pledge belongs to perform element of the network domain to which the pledge belongs to perform
the bootstrap. This element (device) is called the registrar. the bootstrap. This element (device) is called the registrar.
Before any other operation, pledge and registrar need to establish Before any other operation, pledge and registrar need to establish
mutual trust: mutual trust:
skipping to change at page 5, line 18 skipping to change at page 5, line 11
questions. It uses a TLS connection and an PKIX (X.509v3) questions. It uses a TLS connection and an PKIX (X.509v3)
certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer
points 1 and 2. It uses a new artifact called a "voucher" that the points 1 and 2. It uses a new artifact called a "voucher" that the
registrar receives from a "Manufacturer Authorized Signing Authority" registrar receives from a "Manufacturer Authorized Signing Authority"
and passes to the pledge to answer points 3 and 2. and passes to the pledge to answer points 3 and 2.
A proxy provides very limited connectivity between the pledge and the A proxy provides very limited connectivity between the pledge and the
registrar. registrar.
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 [RFC8366]. This document details automated protocol mechanisms to
mechanisms to obtain vouchers, including the definition of a obtain vouchers, including the definition of a 'voucher-request'
'voucher-request' message that is a minor extension to the voucher message that is a minor extension to the voucher format (see
format (see Section 3) defined by [I-D.ietf-anima-voucher]. Section 3) defined by [RFC8366].
BRSKI results in the pledge storing an X.509 root certificate BRSKI results in the pledge storing an X.509 root certificate
sufficient for verifying the registrar identity. In the process a sufficient for verifying the registrar identity. In the process a
TLS connection is established that can be directly used for TLS connection is established that can be directly used for
Enrollment over Secure Transport (EST). In effect BRSKI provides an Enrollment over Secure Transport (EST). In effect BRSKI provides an
automated mechanism for the "Bootstrap Distribution of CA automated mechanism for the "Bootstrap Distribution of CA
Certificates" described in [RFC7030] Section 4.1.1 wherein the pledge Certificates" described in [RFC7030] Section 4.1.1 wherein the pledge
"MUST [...] engage a human user to authorize the CA certificate using "MUST [...] engage a human user to authorize the CA certificate using
out-of-band" information". With BRSKI the pledge now can automate out-of-band" information". With BRSKI the pledge now can automate
this process using the voucher. Integration with a complete EST this process using the voucher. Integration with a complete EST
skipping to change at page 7, line 40 skipping to change at page 7, line 35
network and acquires a network specific identity. For example network and acquires a network specific identity. For example
when a certificate signing request is presented to a certification when a certificate signing request is presented to a certification
authority and a certificate is obtained in response. authority and a certificate is obtained in response.
Pledge: The prospective device, which has an identity installed at Pledge: The prospective device, which has an identity installed at
the factory. the factory.
Voucher: A signed artifact from the MASA that indicates to a pledge Voucher: A signed artifact from the MASA that indicates to a pledge
the cryptographic identity of the registrar it should trust. the cryptographic identity of the registrar it should trust.
There are different types of vouchers depending on how that trust There are different types of vouchers depending on how that trust
is asserted. Multiple voucher types are defined in is asserted. Multiple voucher types are defined in [RFC8366]
[I-D.ietf-anima-voucher]
Domain: The set of entities that share a common local trust anchor. Domain: The set of entities that share a common local trust anchor.
This includes the proxy, registrar, Domain Certificate Authority, This includes the proxy, registrar, Domain Certificate Authority,
Management components and any existing entity that is already a Management components and any existing entity that is already a
member of the domain. member of the domain.
Domain CA: The domain Certification Authority (CA) provides Domain CA: The domain Certification Authority (CA) provides
certification functionalities to the domain. At a minimum it certification functionalities to the domain. At a minimum it
provides certification functionalities to a registrar and manages provides certification functionalities to a registrar and manages
the private key that defines the domain. Optionally, it certifies the private key that defines the domain. Optionally, it certifies
skipping to change at page 8, line 47 skipping to change at page 8, line 42
of privacy protected bootstrapping events. It does not track of privacy protected bootstrapping events. It does not track
ownership. ownership.
Ownership Tracker: An Ownership Tracker service on the global Ownership Tracker: An Ownership Tracker service on the global
internet. The Ownership Tracker uses business processes to internet. The Ownership Tracker uses business processes to
accurately track ownership of all devices shipped against domains accurately track ownership of all devices shipped against domains
that have purchased them. Although optional, this component that have purchased them. Although optional, this component
allows vendors to provide additional value in cases where their allows vendors to provide additional value in cases where their
sales and distribution channels allow for accurately tracking of sales and distribution channels allow for accurately tracking of
such ownership. Ownership tracking information is indicated in such ownership. Ownership tracking information is indicated in
vouchers as described in [I-D.ietf-anima-voucher] vouchers as described in [RFC8366]
IDevID: An Initial Device Identity X.509 certificate installed by IDevID: An Initial Device Identity X.509 certificate installed by
the vendor on new equipment. the vendor on new equipment.
TOFU: Trust on First Use. Used similarly to [RFC7435]. This is TOFU: Trust on First Use. Used similarly to [RFC7435]. This is
where a pledge device makes no security decisions but rather where a pledge device makes no security decisions but rather
simply trusts the first registrar it is contacted by. This is simply trusts the first registrar it is contacted by. This is
also known as the "resurrecting duckling" model. also known as the "resurrecting duckling" model.
nonced: a voucher (or request) that contains a nonce (the normal nonced: a voucher (or request) that contains a nonce (the normal
skipping to change at page 9, line 30 skipping to change at page 9, line 25
situations it could be a "value added retailer" (VAR), or possibly situations it could be a "value added retailer" (VAR), or possibly
even a systems integrator. In general, it a goal of BRSKI to even a systems integrator. In general, it a goal of BRSKI to
eliminate small distinctions between different sales channels. eliminate small distinctions between different sales channels.
The reason for this is that it permits a single device, with a The reason for this is that it permits a single device, with a
uniform firmware load, to be shipped directly to all customers. uniform firmware load, to be shipped directly to all customers.
This eliminates costs for the manufacturer. This also reduces the This eliminates costs for the manufacturer. This also reduces the
number of products supported in the field increasing the chance number of products supported in the field increasing the chance
that firmware will be more up to date. that firmware will be more up to date.
ANI: The Autonomic Network Infrastructure as defined by ANI: The Autonomic Network Infrastructure as defined by
[I-D.ietf-anima-autonomic-control-plane]. This document details [I-D.ietf-anima-reference-model]. This document details specific
specific requirements for pledges, proxies and registrars when requirements for pledges, proxies and registrars when they are
they are part of an ANI. part of an ANI.
offline: When an architectural component cannot perform realtime offline: When an architectural component cannot perform realtime
communications with a peer, either due to network connectivity or communications with a peer, either due to network connectivity or
because the peer is turned off, the operation is said to be because the peer is turned off, the operation is said to be
occurring offline. occurring offline.
1.3. Scope of solution 1.3. Scope of solution
1.3.1. Support environment 1.3.1. Support environment
skipping to change at page 15, line 42 skipping to change at page 15, line 42
pledges can optionally obtain a locally issued certificate, although pledges can optionally obtain a locally issued certificate, although
any REST interface could be integrated in future work. any REST interface could be integrated in future work.
2.2. Secure Imprinting using Vouchers 2.2. Secure Imprinting using Vouchers
A voucher is a cryptographically protected artifact (a digital A voucher is a cryptographically protected artifact (a digital
signature) to the pledge device authorizing a zero-touch imprint on signature) to the pledge device authorizing a zero-touch imprint on
the registrar domain. the registrar domain.
The format and cryptographic mechanism of vouchers is described in The format and cryptographic mechanism of vouchers is described in
detail in [I-D.ietf-anima-voucher]. detail in [RFC8366].
Vouchers provide a flexible mechanism to secure imprinting: the Vouchers provide a flexible mechanism to secure imprinting: the
pledge device only imprints when a voucher can be validated. At the pledge device only imprints when a voucher can be validated. At the
lowest security levels the MASA server can indiscriminately issue lowest security levels the MASA can indiscriminately issue vouchers
vouchers and log claims of ownership by domains. At the highest and log claims of ownership by domains. At the highest security
security levels issuance of vouchers can be integrated with complex levels issuance of vouchers can be integrated with complex sales
sales channel integrations that are beyond the scope of this channel integrations that are beyond the scope of this document. The
document. The sales channel integration would verify actual (legal) sales channel integration would verify actual (legal) ownership of
ownership of the pledge by the domain. This provides the flexibility the pledge by the domain. This provides the flexibility for a number
for a number of use cases via a single common protocol mechanism on of use cases via a single common protocol mechanism on the pledge and
the pledge and registrar devices that are to be widely deployed in registrar devices that are to be widely deployed in the field. The
the field. The MASA services have the flexibility to leverage either MASA services have the flexibility to leverage either the currently
the currently defined claim mechanisms or to experiment with higher defined claim mechanisms or to experiment with higher or lower
or lower security levels. security levels.
Vouchers provide a signed but non-encrypted communication channel Vouchers provide a signed but non-encrypted communication channel
among the pledge, the MASA, and the registrar. The registrar among 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 pledge voucher-request signing is via a Pledge authentication and pledge voucher-request signing is via a
PKIX certificate installed during the manufacturing process. This is PKIX certificate installed during the manufacturing process. This is
skipping to change at page 16, line 35 skipping to change at page 16, line 35
and subjectAltName (SAN) parameters in the IDevID. The unique and subjectAltName (SAN) parameters in the IDevID. The unique
identification of a pledge in the voucher objects are derived identification of a pledge in the voucher objects are derived
from those parameters as described below. from those parameters as described below.
2. Securely authentating the pledges identity via TLS connection to 2. Securely authentating the pledges identity via TLS connection to
registrar. This provides protection against cloned/fake pledged. registrar. This provides protection against cloned/fake pledged.
3. Secure auto-discovery of the pledges MASA by the registrar via 3. Secure auto-discovery of the pledges MASA by the registrar via
the MASA URI in IDevID as explained below. the MASA URI in IDevID as explained below.
4. (Optionally) communicating the MUD URL (see Appendix D. 4. (Optionally) communicating the MUD URL (see Appendix C.
5. (Optional) Signing of voucher-request by the pledges IDevID to 5. (Optional) Signing of voucher-request by the pledges IDevID to
enable MASA to generate voucher only to a registrar that has a enable MASA to generate voucher only to a registrar that has a
connection to the pledge. connection to the pledge.
6. Authorizing pledge (via registrar) to receive certificate from 6. Authorizing pledge (via registrar) to receive certificate from
domain CA, by signing the Certificate Signing Request (CSR). domain CA, by signing the Certificate Signing Request (CSR).
2.3.1. Identification of the Pledge 2.3.1. Identification of the Pledge
skipping to change at page 20, line 16 skipping to change at page 20, line 16
2.5.1. Pledge 2.5.1. Pledge
The pledge is the device that is attempting to join. Until the The pledge is the device that is attempting to join. Until the
pledge completes the enrollment process, it has link-local network pledge completes the enrollment process, it has link-local network
connectivity only to the proxy. connectivity only to the proxy.
2.5.2. Join Proxy 2.5.2. Join Proxy
The join proxy provides HTTPS connectivity between the pledge and the The join proxy provides HTTPS connectivity between the pledge and the
registrar. A circuit proxy mechanism is described in Section 4, with registrar. A circuit proxy mechanism is described in Section 4.
an optional stateless IPIP proxy mechanism described in Appendix C. Additional mechanisms, including a CoAP mechanism and a stateless
IPIP mechanism are the subject of future work.
2.5.3. Domain Registrar 2.5.3. Domain Registrar
The domain's registrar operates as the BRSKI-MASA client when The domain's registrar operates as the BRSKI-MASA client when
requesting vouchers from the MASA (see Section 5.3). The registrar requesting vouchers from the MASA (see Section 5.3). The registrar
operates as the BRSKI-EST server when pledges request vouchers (see operates as the BRSKI-EST server when pledges request vouchers (see
Section 5.1). The registrar operates as the BRSKI-EST server Section 5.1). The registrar operates as the BRSKI-EST server
"Registration Authority" if the pledge requests an end entity "Registration Authority" if the pledge requests an end entity
certificate over the BRSKI-EST connection (see Section 5.8). certificate over the BRSKI-EST connection (see Section 5.8).
The registrar uses an Implicit Trust Anchor database for The registrar uses an Implicit Trust Anchor database for
authenticating the BRSKI-MASA TLS connection MASA server certificate. authenticating the BRSKI-MASA TLS connection MASA certificate. The
The registrar uses a different Implicit Trust Anchor database for registrar uses a different Implicit Trust Anchor database for
authenticating the BRSKI-EST TLS connection pledge client authenticating the BRSKI-EST TLS connection pledge client
certificate. Configuration or distribution of these trust anchor certificate. Configuration or distribution of these trust anchor
databases is out-of-scope of this specification. databases is out-of-scope of this specification.
2.5.4. Manufacturer Service 2.5.4. Manufacturer Service
The Manufacturer Service provides two logically seperate functions: The Manufacturer Service provides two logically seperate functions:
the Manufacturer Authorized Signing Authority (MASA) described in the Manufacturer Authorized Signing Authority (MASA) described in
Section 5.4 and Section 5.5, and an ownership tracking/auditing Section 5.4 and Section 5.5, and an ownership tracking/auditing
function described in Section 5.6 and Section 5.7. function described in Section 5.6 and Section 5.7.
skipping to change at page 24, line 8 skipping to change at page 24, line 8
The registrar needs to be able to contact a MASA that is trusted by The registrar needs to be able to contact a MASA that is trusted by
the pledge in order to obtain vouchers. There are three mechanisms the pledge in order to obtain vouchers. There are three mechanisms
described: described:
The device's Initial Device Identifier will normally contain the MASA The device's Initial Device Identifier will normally contain the MASA
URL as detailed in Section 2.3. This is the RECOMMENDED mechanism. URL as detailed in Section 2.3. This is the RECOMMENDED mechanism.
If the registrar is integrated with [I-D.ietf-opsawg-mud] and the If the registrar is integrated with [I-D.ietf-opsawg-mud] and the
pledge IDevID contains the id-pe-mud-url then the registrar MAY pledge IDevID contains the id-pe-mud-url then the registrar MAY
attempt to obtain the MASA URL from the MUD file. The MUD file attempt to obtain the MASA URL from the MUD file. The MUD file
extension for the MASA URL is defined in Appendix D. extension for the MASA URL is defined in Appendix C.
It can be operationally difficult to ensure the necessary X.509 It can be operationally difficult to ensure the necessary X.509
extensions are in the pledge's IDevID due to the difficulty of extensions are in the pledge's IDevID due to the difficulty of
aligning current pledge manufacturing with software releases and aligning current pledge manufacturing with software releases and
development. As a final fallback the registrar MAY be manually development. As a final fallback the registrar MAY be manually
configured or distributed with a MASA URL for each manufacturer. configured or distributed with a MASA URL for each manufacturer.
Note that the registrar can only select the configured MASA URL based Note that the registrar can only select the configured MASA URL based
on the trust anchor -- so manufacturers can only leverage this on the trust anchor -- so manufacturers can only leverage this
approach if they ensure a single MASA URL works for all pledge's approach if they ensure a single MASA URL works for all pledge's
associated with each trust anchor. associated with each trust anchor.
3. Voucher-Request artifact 3. Voucher-Request artifact
Voucher-requests are how vouchers are requested. The semantics of Voucher-requests are how vouchers are requested. The semantics of
the vouchers are described below, in the YANG model. the vouchers are described below, in the YANG model.
A pledge forms the "pledge voucher-request" and submits it to the A pledge forms the "pledge voucher-request" and submits it to the
registrar. registrar.
The registrar in turn forms the "registrar voucher-request", and The registrar in turn forms the "registrar voucher-request", and
submits it to the MASA server. submits it to the MASA.
The "proximity-registrar-cert" leaf is used in the pledge voucher- The "proximity-registrar-cert" leaf is used in the pledge voucher-
requests. This provides a method for the pledge to assert the requests. This provides a method for the pledge to assert the
registrar's proximity. registrar's proximity.
The "prior-signed-voucher-request" leaf is used in registrar voucher- The "prior-signed-voucher-request" leaf is used in registrar voucher-
requests. If present, it is the encoded (signed form) of the pledge requests. If present, it is the encoded (signed form) of the pledge
voucher-request. This provides a method for the registrar to forward voucher-request. This provides a method for the registrar to forward
the pledge's signed request to the MASA. This completes transmission the pledge's signed request to the MASA. This completes transmission
of the signed "proximity-registrar-cert" leaf. of the signed "proximity-registrar-cert" leaf.
skipping to change at page 24, line 51 skipping to change at page 24, line 51
A registrar MAY also retrieve nonceless vouchers by sending nonceless A registrar MAY also retrieve nonceless vouchers by sending nonceless
voucher-requests to the MASA in order to obtain vouchers for use when voucher-requests to the MASA in order to obtain vouchers for use when
the registrar does not have connectivity to the MASA. No "prior- the registrar does not have connectivity to the MASA. No "prior-
signed-voucher-request" leaf would be included. The registrar will signed-voucher-request" leaf would be included. The registrar will
also need to know the serial number of the pledge. This document also need to know the serial number of the pledge. This document
does not provide a mechanism for the registrar to learn that in an does not provide a mechanism for the registrar to learn that in an
automated fashion. Typically this will be done via scanning of bar- automated fashion. Typically this will be done via scanning of bar-
code or QR-code on packaging, or via some sales channel integration. code or QR-code on packaging, or via some sales channel integration.
Unless otherwise signaled (outside the voucher-request artifact), the Unless otherwise signaled (outside the voucher-request artifact), the
signing structure is as defined for vouchers, see signing structure is as defined for vouchers, see [RFC8366].
[I-D.ietf-anima-voucher].
3.1. Tree Diagram 3.1. Tree Diagram
The following tree diagram illustrates a high-level view of a The following tree diagram illustrates a high-level view of a
voucher-request document. The notation used in this diagram is voucher-request document. The notation used in this diagram is
described in [I-D.ietf-anima-voucher]. Each node in the diagram is described in [RFC8366]. Each node in the diagram is fully described
fully described by the YANG module in Section 3.3. Please review the by the YANG module in Section 3.3. Please review the YANG module for
YANG module for a detailed description of the voucher-request format. a detailed description of the voucher-request format.
module: ietf-voucher-request module: ietf-voucher-request
grouping 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
skipping to change at page 27, line 17 skipping to change at page 27, line 17
"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 [RFC8366]
[I-D.ietf-anima-voucher] voucher into a voucher-request. voucher into a voucher-request.
<CODE BEGINS> file "ietf-voucher-request@2018-02-14.yang" <CODE BEGINS> file "ietf-voucher-request@2018-02-14.yang"
module ietf-voucher-request { module ietf-voucher-request {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-voucher-request"; "urn:ietf:params:xml:ns:yang:ietf-voucher-request";
prefix "vch"; prefix "vch";
import ietf-restconf { import ietf-restconf {
skipping to change at page 31, line 5 skipping to change at page 31, line 5
GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI
registrar ACP addresses and ports by ANI proxies. The TCP leg of the registrar ACP addresses and ports by ANI proxies. The TCP leg of the
proxy connection between ANI proxy and ANI registrar therefore also proxy connection between ANI proxy and ANI registrar therefore also
runs across the ACP. runs across the ACP.
During the discovery of the Registrar by the Join Proxy, the Join During the discovery of the Registrar by the Join Proxy, the Join
Proxy will also learn which kinds of proxy mechanisms are available. Proxy will also learn which kinds of proxy mechanisms are available.
This will allow the Join Proxy to use the lowest impact mechanism This will allow the Join Proxy to use the lowest impact mechanism
which the Join Proxy and Registrar have in common. which the Join Proxy and Registrar have in common.
For the IPIP encapsulation methods (described in Appendix C), the
port announced by the proxy SHOULD be the same as on the registrar in
order for the proxy to remain stateless.
In order to permit the proxy functionality to be implemented on the In order to permit the proxy functionality to be implemented on the
maximum variety of devices the chosen mechanism SHOULD use the maximum variety of devices the chosen mechanism SHOULD use the
minimum amount of state on the proxy device. While many devices in minimum amount of state on the proxy device. While many devices in
the ANIMA target space will be rather large routers, the proxy the ANIMA target space will be rather large routers, the proxy
function is likely to be implemented in the control plane CPU of such function is likely to be implemented in the control plane CPU of such
a device, with available capabilities for the proxy function similar a device, with available capabilities for the proxy function similar
to many class 2 IoT devices. to many class 2 IoT devices.
The document [I-D.richardson-anima-state-for-joinrouter] provides a The document [I-D.richardson-anima-state-for-joinrouter] provides a
more extensive analysis and background of the alternative proxy more extensive analysis and background of the alternative proxy
skipping to change at page 33, line 5 skipping to change at page 33, line 5
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
["AN_Proxy", 4, 1, ""], ["AN_Proxy", 4, 1, ""],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]] h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]
Figure 6b: Proxy Discovery Figure 6b: Proxy Discovery
The formal CDDL definition is: The formal CDDL definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_Proxy", objective-flags, loop-count, objective = ["AN_Proxy", objective-flags, loop-count,
objective-value] objective-value]
ttl = 180000 ; 180,000 ms (3 minutes) ttl = 180000 ; 180,000 ms (3 minutes)
initiator = ACP address to contact Registrar initiator = ACP address to contact Registrar
objective-flags = sync-only ; as in GRASP spec objective-flags = sync-only ; as in GRASP spec
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 1 ; one hop only loop-count = 1 ; one hop only
objective-value = any ; none objective-value = any ; none
locator = [ O_IPv6_LOCATOR, ipv6-address, locator-option = [ O_IPv6_LOCATOR, ipv6-address,
transport-proto, port-number ] transport-proto, port-number ]
ipv6-address = the v6 LL of the Proxy ipv6-address = the v6 LL of the Proxy
transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 $transport-proto /= IPPROTO_TCP ; note this can be any value from the
port-number = selected by Proxy ; IANA protocol registry, as per
; [GRASP] section 2.9.5.1, note 3.
port-number = selected by Proxy
Figure 6c: AN_Proxy CDDL Figure 6c: AN_Proxy CDDL
4.2. CoAP connection to Registrar 4.2. CoAP connection to Registrar
The use of CoAP to connect from pledge to registrar is out of scope The use of CoAP to connect from pledge to registrar is out of scope
for this document, and may be described in future work. for this document, and may be described in future work.
4.3. Proxy discovery of Registrar 4.3. 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.
The registrar announces itself using ACP instance of GRASP using The registrar announces itself using ACP instance of GRASP using
M_FLOOD messages. They MUST support ANI TLS circuit proxy and M_FLOOD messages. They MUST support ANI TLS circuit proxy and
therefore BRSKI across HTTPS/TLS native across the ACP. ANI therefore BRSKI across HTTPS/TLS native across the ACP. ANI proxies
registrars MAY support the IPIP proxy method by implementing IPIP
tunneling for their HTTPS/TLS traffic across the ACP. ANI proxies
MUST support GRASP discovery of registrars. MUST support GRASP discovery of registrars.
The M_FLOOD is formatted as follows: The M_FLOOD is formatted as follows:
[M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000,
["AN_join_registrar", 4, 255, "EST-TLS"], ["AN_join_registrar", 4, 255, "EST-TLS"],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 80]] h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 80]]
Figure 7a: Registrar Discovery Figure 7a: Registrar Discovery
skipping to change at page 34, line 25 skipping to change at page 34, line 25
objective-value = text ; name of the (list of) of supported objective-value = text ; name of the (list of) of supported
; protocols: "EST-TLS" for RFC7030. ; protocols: "EST-TLS" for RFC7030.
Figure 7: AN_join_registrar CDDL Figure 7: AN_join_registrar CDDL
The M_FLOOD message MUST be sent periodically. The period is subject The M_FLOOD message MUST be sent periodically. The period is subject
to network administrator policy (EST server configuration). It must to network administrator policy (EST server configuration). It must
be sufficiently low that the aggregate amount of periodic M_FLOODs be sufficiently low that the aggregate amount of periodic M_FLOODs
from all EST servers causes negligible traffic across the ACP. from all EST servers causes negligible traffic across the ACP.
The locators are to be interpreted as follows: Here are some examples of locators for illustrative purposes. Only
the first one (transport-protocol = 6, TCP) is defined in this
document and is mandatory to implement.
locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443]
locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
A protocol of 6 indicates that TCP proxying on the indicated port is A protocol of 6 indicates that TCP proxying on the indicated port is
desired. A protocol of 17 indicates that UDP proxying on the desired.
indicated port is desired. In each case, the traffic SHOULD be
proxied to the same port at the ULA address provided.
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
address MUST be advertised on the local link using proxy neighbour
discovery. The proxy MAY limit forwarded traffic to the protocol (6
and 17) and port numbers indicated by locator1 and locator2. The
address to which the IPIP traffic should be sent is the initiator
address (an ACP address of the registrar), not the address given in
the locator.
Registrars MUST accept TCP / UDP traffic on the ports given at the Registrars MUST announce the set of protocols that they support.
ACP address of the registrar. If the registrar supports IPIP They MUST support TCP traffic.
tunnelling, 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 ports, in
addition to TCP traffic.
5. Protocol Details (Pledge - Registrar - MASA) 5. Protocol Details (Pledge - Registrar - MASA)
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.
BRSKI is described as extensions to EST [RFC7030]. The goal of these BRSKI is described as extensions to EST [RFC7030]. The goal of these
extensions is to reduce the number of TLS connections and crypto extensions is to reduce the number of TLS connections and crypto
operations required on the pledge. The registrar implements the operations required on the pledge. The registrar implements the
skipping to change at page 38, line 27 skipping to change at page 38, line 16
If authorization is successful the registrar obtains a voucher from If authorization is successful the registrar obtains a voucher from
the MASA service (see Section 5.4) and returns that MASA signed the MASA service (see Section 5.4) and returns that MASA signed
voucher to the pledge as described in Section 5.5. voucher to the pledge as described in Section 5.5.
5.3. BRSKI-MASA TLS establishment details 5.3. BRSKI-MASA TLS establishment details
The BRSKI-MASA TLS connection is a 'normal' TLS connection The BRSKI-MASA TLS connection is a 'normal' TLS connection
appropriate for HTTPS REST interfaces. The registrar initiates the appropriate for HTTPS REST interfaces. The registrar initiates the
connection and uses the MASA URL obtained as described in Section 2.8 connection and uses the MASA URL obtained as described in Section 2.8
for [RFC6125] authentication of the MASA server. for [RFC6125] authentication of the MASA.
The primary method of registrar "authentication" by the MASA is The primary method of registrar "authentication" by the MASA is
detailed in Section 5.4. As detailed in Section 9 the MASA might detailed in Section 5.4. As detailed in Section 9 the MASA might
find it necessary to request additional registrar authentication. find it necessary to request additional registrar authentication.
The MASA and the registrars SHOULD be prepared to support TLS client The MASA and the registrars SHOULD be prepared to support TLS client
certificate authentication and/or HTTP Basic or Digest authentication certificate authentication and/or HTTP Basic or Digest authentication
as described in RFC7030 for EST clients. This connection MAY also as described in RFC7030 for EST clients. This connection MAY also
have no client authentication at all (Section 6.4) have no client authentication at all (Section 6.4)
skipping to change at page 39, line 14 skipping to change at page 38, line 48
5.4. Registrar Requests Voucher from MASA 5.4. Registrar Requests Voucher from MASA
When a registrar receives a pledge voucher-request it in turn submits When a registrar receives a pledge voucher-request it in turn submits
a registrar voucher-request to the MASA service via an HTTPS RESTful a registrar voucher-request to the MASA service via an HTTPS RESTful
interface ([RFC7231]). interface ([RFC7231]).
This is done with an HTTP POST using the operation path value of This is done with an HTTP POST using the operation path value of
"/.well-known/est/requestvoucher". "/.well-known/est/requestvoucher".
The request media type is defined in [I-D.ietf-anima-voucher] and is The request media type is defined in [RFC8366] and is application/
application/voucher-cms+json. It is a JSON document that has been voucher-cms+json. It is a JSON document that has been signed using a
signed using a CMS structure. The registrar MUST sign the registrar CMS structure. The registrar MUST sign the registrar voucher-
voucher-request. The entire registrar certificate chain, up to and request. The entire registrar certificate chain, up to and including
including the Domain CA, MUST be included in the CMS structure. the Domain CA, MUST be included in the CMS structure.
MASA impementations SHOULD anticipate future media types but of MASA impementations SHOULD anticipate future media types but of
course will simply fail the request if those types are not yet known. course will simply fail the request if those types are not yet known.
The 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
skipping to change at page 40, line 20 skipping to change at page 40, line 7
field from the physical device labeling or from the sales channel field from the physical device labeling or from the sales channel
(out-of-scope for this document). (out-of-scope for this document).
All other fields MAY be omitted in the registrar voucher-request. All other fields MAY be omitted in the registrar voucher-request.
Example JSON payloads of registrar voucher-requests are in Example JSON payloads of registrar voucher-requests are in
Section 3.2 Examples 2 through 4. Section 3.2 Examples 2 through 4.
The MASA verifies that the registrar voucher-request is internally The MASA verifies that the registrar voucher-request is internally
consistent but does not necessarily authenticate the registrar consistent but does not necessarily authenticate the registrar
certificate since the registrar is not known to the MASA server in certificate since the registrar is not known to the MASA in advance.
advance. The MASA performs the actions and validation checks The MASA performs the actions and validation checks described in the
described in the following sub-sections before issuing a voucher. following sub-sections before issuing a voucher.
5.4.1. MASA renewal of expired vouchers 5.4.1. MASA renewal of expired vouchers
As described in [I-D.ietf-anima-voucher] vouchers are normally short As described in [RFC8366] vouchers are normally short lived to avoid
lived to avoid revocation issues. If the request is for a previous revocation issues. If the request is for a previous (expired)
(expired) voucher using the same registrar then the request for a voucher using the same registrar then the request for a renewed
renewed voucher SHOULD be automatically authorized. The MASA has voucher SHOULD be automatically authorized. The MASA has sufficient
sufficient information to determine this by examining the request, information to determine this by examining the request, the registrar
the registrar authentication, and the existing audit log. The authentication, and the existing audit log. The issuance of a
issuance of a renewed voucher is logged as detailed in Section 5.5. renewed voucher is logged as detailed in Section 5.5.
To inform the MASA that existing vouchers are not to be renewed one To inform the MASA that existing vouchers are not to be renewed one
can update or revoke the registrar credentials used to authorize the can update or revoke the registrar credentials used to authorize the
request (see Section 5.4.3 and Section 5.4.4). More flexible methods request (see Section 5.4.3 and Section 5.4.4). More flexible methods
will likely involve sales channel integration and authorizations will likely involve sales channel integration and authorizations
(details are out-of-scope of this document). (details are out-of-scope of this document).
5.4.2. MASA verification of voucher-request signature consistency 5.4.2. MASA verification of voucher-request signature consistency
The MASA MUST verify that the registrar voucher-request is signed by The MASA MUST verify that the registrar voucher-request is signed by
skipping to change at page 41, line 10 skipping to change at page 40, line 45
voucher-request signer to be a registrar. Performing this check voucher-request signer to be a registrar. Performing this check
provides value to the domain PKI by assuring the domain administrator provides value to the domain PKI by assuring the domain administrator
that the MASA service will only respect claims from authorized that the MASA service will only respect claims from authorized
Registration Authorities of the domain. Registration Authorities of the domain.
The MASA verifies that the domain CA certificate is included in the The MASA verifies that the domain CA certificate is included in the
CMS structure as detailed in Section 5.4. CMS structure as detailed in Section 5.4.
5.4.3. MASA authentication of registrar (certificate) 5.4.3. MASA authentication of registrar (certificate)
If a nonceless voucher-request is submitted the MASA server MUST If a nonceless voucher-request is submitted the MASA MUST
authenticate the registrar as described in either EST [RFC7030] authenticate the registrar as described in either EST [RFC7030]
section 3.2, section 3.3, or by validating the registrar's section 3.2, section 3.3, or by validating the registrar's
certificate used to sign the registrar voucher-request. Any of these certificate used to sign the registrar voucher-request. Any of these
methods reduce the risk of DDoS attacks and provide an authenticated methods reduce the risk of DDoS attacks and provide an authenticated
identity as an input to sales channel integration and authorizations identity as an input to sales channel integration and authorizations
(details are out-of-scope of this document). (details are out-of-scope of this document).
In the nonced case, validation of the registrar MAY be omitted if the In the nonced case, validation of the registrar MAY be omitted if the
device policy is to accept audit-only vouchers. device policy is to accept audit-only vouchers.
skipping to change at page 41, line 33 skipping to change at page 41, line 20
As noted in Section 5.4.3 the MASA performs registrar authentication As noted in Section 5.4.3 the MASA performs registrar authentication
in a subset of situations (e.g. nonceless voucher requests). Normal in a subset of situations (e.g. nonceless voucher requests). Normal
PKIX revocation checking is assumed during either EST client PKIX revocation checking is assumed during either EST client
authentication or voucher-request signature validation. Similarly, authentication or voucher-request signature validation. Similarly,
as noted in Section 5.4.2, the MASA performs normal PKIX revocation as noted in Section 5.4.2, the MASA performs normal PKIX revocation
checking during signature consistency checks (a signature by a checking during signature consistency checks (a signature by a
registrar certificate that has been revoked is an inconsistency). registrar certificate that has been revoked is an inconsistency).
5.4.5. MASA verification of pledge prior-signed-voucher-request 5.4.5. MASA verification of pledge prior-signed-voucher-request
The MASA server MAY verify that the registrar voucher-request The MASA MAY verify that the registrar voucher-request includes the
includes the 'prior-signed-voucher-request' field. If so the prior- 'prior-signed-voucher-request' field. If so the prior-signed-
signed-voucher-request MUST include a 'proximity-registrar-cert' that voucher-request MUST include a 'proximity-registrar-cert' that is
is consistent with the certificate used to sign the registrar consistent with the certificate used to sign the registrar voucher-
voucher-request. Additionally the voucher-request serial-number leaf request. Additionally the voucher-request serial-number leaf MUST
MUST match the pledge serial-number that the MASA extracts from the match the pledge serial-number that the MASA extracts from the
signing certificate of the prior-signed-voucher-request. The MASA signing certificate of the prior-signed-voucher-request. The MASA is
server is aware of which pledges support signing of their voucher aware of which pledges support signing of their voucher requests and
requests and can use this information to confirm proximity of the can use this information to confirm proximity of the pledge with the
pledge with the registrar, thus ensuring that the BRSKI-EST TLS registrar, thus ensuring that the BRSKI-EST TLS connection has no
connection has no man-in-the-middle. man-in-the-middle.
If these checks succeed the MASA updates the voucher and audit log If these checks succeed the MASA updates the voucher and audit log
assertion leafs with the "proximity" assertion. assertion leafs with the "proximity" assertion.
5.4.6. MASA pinning of registrar 5.4.6. MASA pinning of registrar
The registrar's certificate chain is extracted from the signature The registrar's certificate chain is extracted from the signature
method. The chain includes the domain CA certificate as specified in method. The chain includes the domain CA certificate as specified in
Section 5.4. This certificate is used to populate the "pinned- Section 5.4. This certificate is used to populate the "pinned-
domain-cert" of the voucher being issued. The domainID (e.g., hash domain-cert" of the voucher being issued. The domainID (e.g., hash
skipping to change at page 42, line 33 skipping to change at page 42, line 22
changes to the pledge; therefore this section applies to both the changes to the pledge; therefore this section applies to both the
MASA and the registrar. The HTTP signaling described applies to both MASA and the registrar. The HTTP signaling described applies to both
the MASA and registrar responses. A registrar either caches prior the MASA and registrar responses. 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 (it does not generate or sign a voucher). policy (it does not generate or sign a voucher).
If the voucher-request is successful, the server (MASA responding to If the voucher-request is successful, the server (MASA responding to
registrar or registrar responding to pledge) response MUST contain an registrar or registrar responding to pledge) response MUST contain an
HTTP 200 response code. The server MUST answer with a suitable 4xx HTTP 200 response code. The server MUST answer with a suitable 4xx
or 5xx HTTP [RFC2616] error code when a problem occurs. In this or 5xx HTTP [RFC2616] error code when a problem occurs. In this
case, the response data from the MASA server MUST be a plaintext case, the response data from the MASA MUST be a plaintext human-
human-readable (ASCII, English) error message containing explanatory readable (ASCII, English) error message containing explanatory
information describing why the request was rejected. information describing why the request was rejected.
The registrar MAY respond with an HTTP 202 ("the request has been The registrar MAY respond with an HTTP 202 ("the request has been
accepted for processing, but the processing has not been completed") accepted for processing, but the processing has not been completed")
as described in EST [RFC7030] section 4.2.3 wherein the client "MUST as described in EST [RFC7030] section 4.2.3 wherein the client "MUST
wait at least the specified 'Retry-After' time before repeating the wait at least the specified 'Retry-After' time before repeating the
same request". (see [RFC7231] section 6.6.4) The pledge is same request". (see [RFC7231] section 6.6.4) The pledge is
RECOMMENDED to provide local feedback (blinked LED etc) during this RECOMMENDED to provide local feedback (blinked LED etc) during this
wait cycle if mechanisms for this are available. To prevent an wait cycle if mechanisms for this are available. To prevent an
attacker registrar from significantly delaying bootstrapping the attacker registrar from significantly delaying bootstrapping the
skipping to change at page 43, line 34 skipping to change at page 43, line 23
pledge is unacceptable due to inventory control, MASA audit logs, or pledge is unacceptable due to inventory control, MASA audit logs, or
any other reason. any other reason.
A 415 (Unsupported Media Type) response is approriate for a request A 415 (Unsupported Media Type) response is approriate for a request
that has a voucher encoding that is not understood. that has a voucher encoding that is not understood.
The response media type is: The response media type is:
application/voucher-cms+json The response is a "YANG-defined JSON application/voucher-cms+json The response is a "YANG-defined JSON
document that has been signed using a CMS structure" as described document that has been signed using a CMS structure" as described
in [I-D.ietf-anima-voucher] using the JSON encoded described in in [RFC8366] using the JSON encoded described in [RFC7951]. The
[RFC7951]. The MASA MUST sign the response. MASA MUST sign the response.
The syntactic details of vouchers are described in detail in The syntactic details of vouchers are described in detail in
[I-D.ietf-anima-voucher]. For example, the voucher consists of: [RFC8366]. For example, the voucher consists of:
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"assertion": "logging" "assertion": "logging"
"pinned-domain-cert": "base64encodedvalue==" "pinned-domain-cert": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
skipping to change at page 44, line 13 skipping to change at page 43, line 50
nonce: The nonce from the pledge if available. See Section 5.4.7. nonce: The nonce from the pledge if available. See Section 5.4.7.
assertion: The method used to verify assertion. See Section 5.4.5. assertion: The method used to verify assertion. See Section 5.4.5.
pinned-domain-cert: The domain CA cert. See Section 5.4.6. pinned-domain-cert: The domain CA cert. See Section 5.4.6.
serial-number: The serial-number as provided in the voucher-request. serial-number: The serial-number as provided in the voucher-request.
Also see Section 5.4.5. Also see Section 5.4.5.
domain-cert-revocation-checks: Set as appropriate for the pledge's domain-cert-revocation-checks: Set as appropriate for the pledge's
capabilities and as documented in [I-D.ietf-anima-voucher]. The capabilities and as documented in [RFC8366]. The MASA MAY set
MASA MAY set this field to 'false' since setting it to 'true' this field to 'false' since setting it to 'true' would require
would require that revocation information be available to the that revocation information be available to the pledge and this
pledge and this document does not make normative requirements for document does not make normative requirements for [RFC6961] or
[RFC6961] or equivalent integrations. equivalent integrations.
expires-on: This is set for nonceless vouchers. The MASA ensures expires-on: This is set for nonceless vouchers. The MASA ensures
the voucher lifetime is consistent with any revocation or pinned- the voucher lifetime is consistent with any revocation or pinned-
domain-cert consistency checks the pledge might perform. See domain-cert consistency checks the pledge might perform. See
section Section 2.6.1. There are three times to consider: (a) a section Section 2.6.1. There are three times to consider: (a) a
configured voucher lifetime in the MASA, (b) the expiry time for configured voucher lifetime in the MASA, (b) the expiry time for
the registrar's certificate, (c) any certificate revocation the registrar's certificate, (c) any certificate revocation
information (CRL) lifetime. The expires-on field SHOULD be before information (CRL) lifetime. The expires-on field SHOULD be before
the earliest of these three values. Typically (b) will be some the earliest of these three values. Typically (b) will be some
significant time in the future, but (c) will typically be short significant time in the future, but (c) will typically be short
skipping to change at page 47, line 8 skipping to change at page 46, line 42
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 audit log from the MASA service. registrar SHOULD request the MASA audit log from the MASA service.
This is done with an HTTP GET using the operation path value of This is done with an HTTP GET using the operation path value of
"/.well-known/est/requestauditlog". "/.well-known/est/requestauditlog".
The registrar SHOULD HTTP POST the same registrar voucher-request as The registrar SHOULD HTTP POST the same registrar voucher-request as
it did when requesting a voucher. It is posted to the it did when requesting a voucher. It is posted to the
/requestauditlog URI instead. The "idevid-issuer" and "serial- /requestauditlog URI instead. The "idevid-issuer" and "serial-
number" informs the MASA server which log is requested so the number" informs the MASA which log is requested so the appropriate
appropriate log can be prepared for the response. Using the same log can be prepared for the response. Using the same media type and
media type and message minimizes cryptographic and message operations message minimizes cryptographic and message operations although it
although it results in additional network traffic. The relying MASA results in additional network traffic. The relying MASA
server implementation MAY leverage internal state to associate this implementation MAY leverage internal state to associate this request
request with the original, and by now already validated, voucher- with the original, and by now already validated, voucher-request so
request so as to avoid an extra crypto validation. as to avoid an extra crypto validation.
A registrar MAY request logs at future times. If the registrar A registrar MAY request logs at future times. If the registrar
generates a new request then the MASA is forced to perform the generates a new request then the MASA is forced to perform the
additional cryptographic operations to verify the new request. additional cryptographic operations to verify the new request.
A MASA that receives a request for a device that does not exist, or A MASA that receives a request for a device that does not exist, or
for which the requesting owner was never an owner returns an HTTP 404 for which the requesting owner was never an owner returns an HTTP 404
("Not found") code. ("Not found") code.
Rather than returning the audit log as a response to the POST (with a 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") return code 200), the MASA MAY instead return a 201 ("Created")
RESTful response ([RFC7231] section 7.1) containing a URL to the RESTful response ([RFC7231] section 7.1) containing a URL to the
prepared (and easily cachable) audit response. prepared (and easily cachable) audit response.
In order to avoid enumeration of device audit logs, MASA servers that In order to avoid enumeration of device audit logs, MASA that return
return URLs SHOULD take care to make the returned URL unguessable. URLs SHOULD take care to make the returned URL unguessable. For
For instance, rather than returning URLs containing a database number instance, rather than returning URLs containing a database number
such as https://example.com/auditlog/1234 or the EUI of the device such as https://example.com/auditlog/1234 or the EUI of the device
such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD
return a randomly generated value (a "slug" in web parlance). The return a randomly generated value (a "slug" in web parlance). The
value is used to find the relevant database entry. value is used to find the relevant database entry.
A MASA that returns a code 200 MAY also include a Location: header A MASA that returns a code 200 MAY also include a Location: header
for future reference by the registrar. for future reference by the registrar.
The request media type is: The request media type is:
skipping to change at page 53, line 35 skipping to change at page 53, line 27
connections to the registrar. connections to the registrar.
5.8.6. EST over CoAP 5.8.6. EST over CoAP
This document describes extensions to EST for the purposes of This document describes extensions to EST for the purposes of
bootstrapping of remote key infrastructures. Bootstrapping is bootstrapping of remote key infrastructures. Bootstrapping is
relevant for CoAP enrollment discussions as well. The defintion of relevant for CoAP enrollment discussions as well. The defintion of
EST and BRSKI over CoAP is not discussed within this document beyond EST and BRSKI over CoAP is not discussed within this document beyond
ensuring proxy support for CoAP operations. Instead it is ensuring proxy support for CoAP operations. Instead it is
anticipated that a definition of CoAP mappings will occur in anticipated that a definition of CoAP mappings will occur in
subsequent documents such as [I-D.vanderstok-ace-coap-est] and that subsequent documents such as [I-D.ietf-ace-coap-est] and that CoAP
CoAP mappings for BRSKI will be discussed either there or in future mappings for BRSKI will be discussed either there or in future work.
work.
6. Reduced security operational modes 6. Reduced security operational modes
A common requirement of bootstrapping is to support less secure A common requirement of bootstrapping is to support less secure
operational modes for support specific use cases. The following operational modes for support specific use cases. The following
sections detail specific ways that the pledge, registrar and MASA can sections detail specific ways that the pledge, registrar and MASA can
be configured to run in a less secure mode for the indicated reasons. be configured to run in a less secure mode for the indicated reasons.
This section is considered non-normative: use suggested methods MUST This section is considered non-normative: use suggested methods MUST
be detailed in specific profiles of BRSKI. This is the subject for be detailed in specific profiles of BRSKI. This is the subject for
skipping to change at page 54, line 14 skipping to change at page 54, line 4
6.1. Trust Model 6.1. Trust Model
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| Pledge | | Join | | Domain | |Manufacturer| | Pledge | | Join | | Domain | |Manufacturer|
| | | Proxy | | Registrar | | Service | | | | Proxy | | Registrar | | Service |
| | | | | | | (Internet) | | | | | | | | (Internet) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
Figure 10 Figure 10
Pledge: The pledge could be compromised and providing an attack Pledge: The pledge could be compromised and providing an attack
vector for malware. The entity is trusted to only imprint using vector for malware. The entity is trusted to only imprint using
secure methods described in this document. Additional endpoint secure methods described in this document. Additional endpoint
assessment techniques are RECOMMENDED but are out-of-scope of this assessment techniques are RECOMMENDED but are out-of-scope of this
document. document.
Join Proxy: Provides proxy functionalities but is not involved in Join Proxy: Provides proxy functionalities but is not involved in
security considerations. security considerations.
Registrar: When interacting with a MASA server a registrar makes all Registrar: When interacting with a MASA a registrar makes all
decisions. For Ownership Audit Vouchers (see decisions. For Ownership Audit Vouchers (see [RFC8366]) the
[I-D.ietf-anima-voucher]) the registrar is provided an opportunity registrar is provided an opportunity to accept MASA decisions.
to accept MASA server decisions.
Vendor Service, MASA: This form of manufacturer service is trusted Vendor Service, MASA: This form of manufacturer service is trusted
to accurately log all claim attempts and to provide authoritative to accurately log all claim attempts and to provide authoritative
log information to registrars. The MASA does not know which log information to registrars. The MASA does not know which
devices are associated with which domains. These claims could be devices are associated with which domains. These claims could be
strengthened by using cryptographic log techniques to provide strengthened by using cryptographic log techniques to provide
append only, cryptographic assured, publicly auditable logs. append only, cryptographic assured, publicly auditable logs.
Current text provides only for a trusted manufacturer. Current text provides only for a trusted manufacturer.
Vendor Service, Ownership Validation: This form of manufacturer Vendor Service, Ownership Validation: This form of manufacturer
skipping to change at page 56, line 38 skipping to change at page 56, line 25
1. Not enforcing that a nonce is in the voucher. This results in 1. Not enforcing that a nonce is in the voucher. This results in
distribution of a voucher that never expires and in effect makes distribution of a voucher that never expires and in effect makes
the Domain an always trusted entity to the pledge during any the Domain an always trusted entity to the pledge during any
subsequent bootstrapping attempts. That this occurred is subsequent bootstrapping attempts. That this occurred is
captured in the log information so that the registrar can make captured in the log information so that the registrar can make
appropriate security decisions when a pledge joins the Domain. appropriate security decisions when a pledge joins the Domain.
This is useful to support use cases where registrars might not be This is useful to support use cases where registrars might not be
online during actual device deployment. Because this results in online during actual device deployment. Because this results in
a long lived voucher and does not require the proof that the a long lived voucher and does not require the proof that the
device is online, this is only accepted when the registrar is device is online, this is only accepted when the registrar is
authenticated by the MASA server and authorized to provide this authenticated by the MASA and authorized to provide this
functionality. The MASA server is RECOMMENDED to use this functionality. The MASA is RECOMMENDED to use this functionality
functionality only in concert with an enhanced level of ownership only in concert with an enhanced level of ownership tracking
tracking (out-of-scope.) If the pledge device is known to have a (out-of-scope.) If the pledge device is known to have a real-
real-time-clock that is set from the factory, use of a voucher time-clock that is set from the factory, use of a voucher
validity period is RECOMMENDED. validity period is RECOMMENDED.
2. Not verifying ownership before responding with a voucher. This 2. Not verifying ownership before responding with a voucher. This
is expected to be a common operational model because doing so is expected to be a common operational model because doing so
relieves the manufacturer providing MASA services from having to relieves the manufacturer providing MASA services from having to
track ownership during shipping and supply chain and allows for a track ownership during shipping and supply chain and allows for a
very low overhead MASA service. A registrar uses the audit log very low overhead MASA service. A registrar uses the audit log
information as a defense in depth strategy to ensure that this information as a defense in depth strategy to ensure that this
does not occur unexpectedly (for example when purchasing new does not occur unexpectedly (for example when purchasing new
equipment the registrar would throw an error if any audit log equipment the registrar would throw an error if any audit log
skipping to change at page 58, line 25 skipping to change at page 58, line 21
Reference: [This document] Reference: [This document]
Service Name: _brski-registrar Service Name: _brski-registrar
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>. Assignee: IESG <iesg@ietf.org>.
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Description: The Bootstrapping Remote Secure Key Description: The Bootstrapping Remote Secure Key
Infrastructures Registrar Infrastructures Registrar
Reference: [This document] Reference: [This document]
7.5. MUD File Extension for the MASA server 7.5. MUD File Extension for the MASA
The IANA is requested to list the name "masa" in the MUD extensions The IANA is requested to list the name "masa" in the MUD extensions
registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in
Appendix D. Appendix C.
8. Privacy Considerations 8. Privacy Considerations
8.1. MASA audit log 8.1. MASA audit log
The MASA audit log includes a hash of the domainID for each Registrar The MASA audit log includes a hash of the domainID for each Registrar
a voucher has been issued to. This information is closely related to a voucher has been issued to. This information is closely related to
the actual domain identity, especially when paired with the anti-DDoS the actual domain identity, especially when paired with the anti-DDoS
authentication information the MASA might collect. This could authentication information the MASA might collect. This could
provide sufficient information for the MASA service to build a provide sufficient information for the MASA service to build a
skipping to change at page 59, line 33 skipping to change at page 59, line 31
voucher to establish management control of a pledge device even after voucher to establish management control of a pledge device even after
having sold it. This risk is mitigated by recording the issuance of having sold it. This risk is mitigated by recording the issuance of
such vouchers in the MASA audit log that is verified by the such vouchers in the MASA audit log that is verified by the
subsequent Registrar. This reduces the resale value of the equipment subsequent Registrar. This reduces the resale value of the equipment
because future owners will detect the lowered security inherent in because future owners will detect the lowered security inherent in
the existence of a nonceless voucher that would be trusted by their the existence of a nonceless voucher that would be trusted by their
pledge. This 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 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 manufacturer customer, even without validating ownership of a valid manufacturer customer, even without validating ownership
of specific pledge devices, helps to mitigate this. Pledge of specific pledge devices, helps to mitigate this. Pledge
signatures on the pledge voucher-request, as forwarded by the signatures on the pledge voucher-request, as forwarded by the
registrar in the prior-signed-voucher-request field of the registrar registrar in the prior-signed-voucher-request field of the registrar
voucher-request, significantly reduce this risk by ensuring the MASA voucher-request, significantly reduce this risk by ensuring the MASA
can confirm proximity between the pledge and the registrar making the can confirm proximity between the pledge and the registrar making the
request. This mechanism is optional to allow for constrained request. This mechanism is optional to allow for constrained
devices. devices.
skipping to change at page 63, line 8 skipping to change at page 62, line 50
Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg, Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg,
and Peter van der Stok and Peter van der Stok
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-13 (work in progress), December 2017. plane-16 (work in progress), June 2018.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-anima-voucher]
Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"Voucher Profile for Bootstrapping Protocols", draft-ietf-
anima-voucher-07 (work in progress), January 2018.
[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>.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
skipping to change at page 65, line 27 skipping to change at page 65, line 18
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>.
11.2. Informative References 11.2. Informative References
[docsisroot] [docsisroot]
CableLabs, "CableLabs Digital Certificate Issuance CableLabs, "CableLabs Digital Certificate Issuance
Service", February 2018, Service", February 2018,
<https://www.cablelabs.com/resources/ <https://www.cablelabs.com/resources/
digital-certificate-issuance-service/>. digital-certificate-issuance-service/>.
[I-D.ietf-ace-coap-est]
Stok, P., Kampanakis, P., Kumar, S., Richardson, M.,
Furuhed, M., and S. Raza, "EST over secure CoAP (EST-
coaps)", draft-ietf-ace-coap-est-02 (work in progress),
June 2018.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
Networking", draft-ietf-anima-reference-model-06 (work in Networking", draft-ietf-anima-reference-model-06 (work in
progress), February 2018. progress), February 2018.
[I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-10 (work in progress), February
2018.
[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 Networking Devices", draft-ietf-netconf- Provisioning for Networking Devices", draft-ietf-netconf-
zerotouch-21 (work in progress), March 2018. zerotouch-22 (work in progress), June 2018.
[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-20 (work Description Specification", draft-ietf-opsawg-mud-25 (work
in progress), April 2018. in progress), June 2018.
[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-02 (work in progress), January 2018. state-for-joinrouter-02 (work in progress), January 2018.
[I-D.vanderstok-ace-coap-est]
Stok, P., Kampanakis, P., Kumar, S., Richardson, M.,
Furuhed, M., and S. Raza, "EST over secure CoAP (EST-
coaps)", draft-vanderstok-ace-coap-est-04 (work in
progress), January 2018.
[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>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
skipping to change at page 68, line 46 skipping to change at page 68, line 46
service. Also see Section 2.7. service. Also see Section 2.7.
The current DNS services returned during each query are maintained The current DNS services returned during each query are maintained
until bootstrapping is completed. If bootstrapping fails and the until bootstrapping is completed. If bootstrapping fails and the
pledge returns to the Discovery state, it picks up where it left off pledge returns to the Discovery state, it picks up where it left off
and continues attempting bootstrapping. For example, if the first and continues attempting bootstrapping. For example, if the first
Multicast DNS _bootstrapks._tcp.local response doesn't work then the Multicast DNS _bootstrapks._tcp.local response doesn't work then the
second and third responses are tried. If these fail the pledge moves second and third responses are tried. If these fail the pledge moves
on to normal DNS-based Service Discovery. on to normal DNS-based Service Discovery.
Appendix C. IPIP Join Proxy mechanism Appendix C. MUD Extension
The circuit proxy mechanism suffers from requiring a state on the
proxy for each connection that is relayed. The proxy can be
considered a kind of Algorithm Gateway (see [RFC2663], section 2.9).
An alternative to proxying at the TCP layer is to selectively forward
at the IP layer. This moves all per-connection state to the
registrar. The IPIP tunnel statelessly forwards packets. This
section provides explanation of some of the details of the registrar
discovery procotol, which are not important to proxy, and some
implementation advice.
The IPIP tunnel is described in [RFC2473]. Each such tunnel is
considered a unidirectional construct, but two tunnels may be
associated to form a bidirectional mechanism. An IPIP tunnel is
setup as follows. The outer addresses are an ACP address of the
proxy, and the ACP address of the join registrar. The inner
addresses seen in the tunnel are the link-local addresses of the
network on which the join activity is occurring.
One way to look at this construct is to consider that the registrar
is extending an interface to attaching to the network on which the
proxy is physically present. The registrar then interacts as if it
were present on that network using link-local (fe80::) addresses.
The registrar is unaware that the traffic is being proxied through a
tunnel, and does not need any special routing.
There are a number of considerations with this mechanism which cause
some minor amounts of complexity. Note that due to the tunnels, the
registrar sees multiple connections to a fe80::/10 network on not
just physical interfaces, but on each of the virtual interfaces
representing the tunnels.
C.1. Multiple Join networks on the Join Proxy side
The proxy will in the general case be a routing device with multiple
interfaces. Even a device as simple as a wifi access point may have
wired, and multiple frequencies of wireless interfaces, potentially
with multiple ESSIDs.
Each of these interfaces on the proxy may be separate L3 routing
domains, and therefore will have a unique set of link-local
addresses. An IPIP packet being returned by the registrar needs to
be forwarded to the correct interface, so the proxy needs an
additional key to distinguish which network the packet should be
returned to.
The simplest way to get this additional key is to allocate an
additional ACP address; one address for each network on which join
traffic is occurring.
C.2. Automatic configuration of tunnels on Registrar
The proxy is expected to do a GRASP negotiation with the proxy for
each interface that it needs to relay traffic from. This is to
permit registrars to configure the appropriate virtual interfaces
before traffic arrives.
A registrar serving a large number of interfaces may not wish to
allocate resources to every interface at all times, but can instead
dynamically allocate interfaces. It can do this by monitoring IPIP
traffic that arrives on its ACP interface, and when packets arrive
from new proxys, it can dynamically configure virtual interfaces.
A more sophisticated registrar willing to modify the behaviour of its
TCP and UDP stack could note the IPIP traffic origination in the
socket control block and make information available to the TCP layer
(for HTTPS connections), or to the application (for CoAP connections)
via a proprietary extension to the socket API.
C.3. Proxy Neighbor Discovery by Join Proxy
The proxy MUST answer neighbor discovery messages for the address
given by the registrar as being its link-local address. The proxy
must also advertise this address as the address to which to connect
when advertising its existence.
This proxy neighbor discovery means that the pledge will create TCP
and UDP connections to the correct registrar address. This matters
as the TCP and UDP pseudo-header checksum includes the destination
address, and for the proxy to remain completely stateless, it must
not be necessary for the checksum to be updated.
C.4. Use of connected sockets; or IP_PKTINFO for CoAP on Registrar
TCP connections on the registrar SHOULD properly capture the ifindex
of the incoming connection into the socket structure. This is normal
IPv6 socket API processing. The outgoing responses will go out on
the same (virtual) interface by ifindex.
When using UDP sockets with CoAP, the application will have to pay
attention to the incoming ifindex on the socket. Access to this
information is available using the IP_PKTINFO auxiliary extension,
which is a standard part of the IPv6 sockets API [RFC3542].
A registrar application could, after receipt of an initial CoAP
message from the pledge, create a connected UDP socket (including the
ifindex information.) The kernel would then take care of accurate
demultiplexing upon receive, and subsequent transmission to the
correct interface.
C.5. Use of socket extension rather than virtual interface
Some operating systems on which a registrar needs to be implemented
may find need for a virtual interface per proxy to be problematic.
There are other mechanisms which can be implemented.
If the IPIP decapsulator can mark the (SYN) packet inside the kernel
with the address of the proxy sending the traffic, then an interface
per proxy may not be needed. The outgoing path need just pay
attention to this extra information and add an appropriate IPIP
header on outgoing. A CoAP over UDP mechanism may need to expose
this extra information to the application as the UDP sockets are
often not connected, and the application will need to specify the
outgoing path on each packet sent.
Such an additional socket mechanism has not been standardized.
Terminating L2TP connections over IPsec transport mode suffers from
the same challenges.
Appendix D. MUD Extension
The following extension augments the MUD model to include a single The following extension augments the MUD model to include a single
node, as described in [I-D.ietf-opsawg-mud] section 3.6, using the node, as described in [I-D.ietf-opsawg-mud] section 3.6, using the
following sample module that has the following tree structure: following sample module that has the following tree structure:
module: ietf-mud-brski-masa module: ietf-mud-brski-masa
augment /ietf-mud:mud: augment /ietf-mud:mud:
+--rw masa-server? inet:uri +--rw masa-server? inet:uri
The model is defined as follows: The model is defined as follows:
skipping to change at page 73, line 5 skipping to change at page 71, line 5
"This value is the URI of the MASA server"; "This value is the URI of the MASA server";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
The MUD extensions string "masa" is defined, and MUST be included in The MUD extensions string "masa" is defined, and MUST be included in
the extensions array of the mud container of a MUD file when this the extensions array of the mud container of a MUD file when this
extension is used. extension is used.
Appendix E. Example Vouchers Appendix D. Example Vouchers
Three entities are involved in a voucher: the MASA issues (signs) it, Three entities are involved in a voucher: the MASA issues (signs) it,
the registrar's public key is mentioned in the voucher, and the the registrar's public key is mentioned in the voucher, and the
pledge validates it. In order to provide reproduceable examples the pledge validates it. In order to provide reproduceable examples the
public and private keys for an example MASA and registrar are first public and private keys for an example MASA and registrar are first
listed. listed.
E.1. Keys involved D.1. Keys involved
The Manufacturer has a Certificate Authority that signs the pledge's The Manufacturer has a Certificate Authority that signs the pledge's
IDevID. In addition the Manufacturer's signing authority (the MASA) IDevID. In addition the Manufacturer's signing authority (the MASA)
signs the vouchers, and that certificate must distributed to the signs the vouchers, and that certificate must distributed to the
devices at manufacturing time so that vouchers can be validated. devices at manufacturing time so that vouchers can be validated.
E.1.1. MASA key pair for voucher signatures D.1.1. MASA key pair for voucher signatures
This private key signs vouchers: This private key signs vouchers:
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho
r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA
zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz
Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= Tvv+5PV++elkP9HQ83vqTAws2WwWTxI=
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
skipping to change at page 73, line 46 skipping to change at page 71, line 46
IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw
EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU
BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R
b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf
w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO
MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O
DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd
MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw=
-----END CERTIFICATE----- -----END CERTIFICATE-----
E.1.2. Manufacturer key pair for IDevID signatures D.1.2. Manufacturer key pair for IDevID signatures
This private key signs IDevID certificates: This private key signs IDevID certificates:
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho
r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA
zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz
Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= Tvv+5PV++elkP9HQ83vqTAws2WwWTxI=
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
skipping to change at page 74, line 27 skipping to change at page 72, line 27
IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw
EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU
BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R
b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf
w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO
MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O
DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd
MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw=
-----END CERTIFICATE----- -----END CERTIFICATE-----
E.1.3. Registrar key pair D.1.3. Registrar key pair
The registrar key (or chain) is the representative of the domain The registrar key (or chain) is the representative of the domain
owner. This key signs registrar voucher-requests: owner. This key signs registrar voucher-requests:
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49 MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49
AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g
6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg== 6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
skipping to change at page 75, line 32 skipping to change at page 73, line 32
04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7
8:17: 8:17:
34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5
3:3e: 3:3e:
03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e
9:ba: 9:ba:
13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2
f:96: f:96:
e9:9d:e2:bc:b2 e9:9d:e2:bc:b2
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Basic Constraints: X509v3 Basic Constraints:
CA:FALSE CA:FALSE
Signature Algorithm: ecdsa-with-SHA384 Signature Algorithm: ecdsa-with-SHA384
30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78: 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78:
5b: 5b:
9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e: 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e:
b6: b6:
9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21: 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21:
02: 02:
31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa: 31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa:
c3: c3:
ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53: ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53:
4b: 4b:
83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a 83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a
E.1.4. Pledge key pair D.1.4. Pledge key pair
The pledge has an IDevID key pair built in at manufacturing time: The pledge has an IDevID key pair built in at manufacturing time:
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIL+ue8PQcN+M7LFBGPsompYwobI/rsoHnTb2a+0hO+8joAoGCCqGSM49 MHcCAQEEIL+ue8PQcN+M7LFBGPsompYwobI/rsoHnTb2a+0hO+8joAoGCCqGSM49
AwEHoUQDQgAEumBVaDlX87WyME8CJToyt9NWy6sYw0DTbjjJIn79pgr7ALa//Y8p AwEHoUQDQgAEumBVaDlX87WyME8CJToyt9NWy6sYw0DTbjjJIn79pgr7ALa//Y8p
r70WpK1SIaiUeeFw7e+lCzTp1Z+wJu14Bg== r70WpK1SIaiUeeFw7e+lCzTp1Z+wJu14Bg==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
The public key is used by the registrar to find the MASA. The MASA The public key is used by the registrar to find the MASA. The MASA
skipping to change at page 77, line 29 skipping to change at page 75, line 29
04:49:a7:98:b4:75:4d:5a:52:74:76:bb:cc:0 04:49:a7:98:b4:75:4d:5a:52:74:76:bb:cc:0
c:47: c:47:
08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b 08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b
4:28: 4:28:
96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e 96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e
d:b8: d:b8:
87:69:44:f7:c6:67:c8:54:fe:72:14:bd:ea:b 87:69:44:f7:c6:67:c8:54:fe:72:14:bd:ea:b
0:ca: 0:ca:
86:08:f0:13:db 86:08:f0:13:db
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Subject Key Identifier: X509v3 Subject Key Identifier:
1D:31:16:61:B6:11:50:9B:3C:FA:13:B6:15:5F:39 1D:31:16:61:B6:11:50:9B:3C:FA:13:B6:15:5F:39
:0B:ED:76:43:2A :0B:ED:76:43:2A
X509v3 Basic Constraints: X509v3 Basic Constraints:
CA:FALSE CA:FALSE
X509v3 Subject Alternative Name: X509v3 Subject Alternative Name:
othername:<unsupported> othername:<unsupported>
1.3.6.1.4.1.46930.2: 1.3.6.1.4.1.46930.2:
..https://highway.sandelman.ca ..https://highway.sandelman.ca
skipping to change at page 78, line 5 skipping to change at page 76, line 5
48:6b:d4:bd:61:d1:ee:e8:9c:f1:c2:5b:87:bb:d7:cb:9f: 48:6b:d4:bd:61:d1:ee:e8:9c:f1:c2:5b:87:bb:d7:cb:9f:
34: 34:
9c:1b:3c:6e:93:67:eb:49:3f:f8:8c:ef:11:47:ad:33:32: 9c:1b:3c:6e:93:67:eb:49:3f:f8:8c:ef:11:47:ad:33:32:
02: 02:
31:00:ab:d6:ec:6f:75:87:8a:ab:b9:9b:45:70:91:e1:90: 31:00:ab:d6:ec:6f:75:87:8a:ab:b9:9b:45:70:91:e1:90:
89: 89:
b3:0e:bb:7c:9e:e3:c9:76:5b:09:44:a2:af:ed:f0:05:3d: b3:0e:bb:7c:9e:e3:c9:76:5b:09:44:a2:af:ed:f0:05:3d:
be: be:
95:68:20:cc:f0:d1:81:80:79:00:16:fb:b0:0c 95:68:20:cc:f0:d1:81:80:79:00:16:fb:b0:0c
E.2. Example process D.2. Example process
RFC-EDITOR: these examples will need to be replaced with CMS versions RFC-EDITOR: these examples will need to be replaced with CMS versions
once IANA has assigned the eContentType in [I-D.ietf-anima-voucher]. once IANA has assigned the eContentType in [RFC8366].
E.2.1. Pledge to Registrar D.2.1. Pledge to Registrar
As described in Section 5.2, the pledge will sign a pledge voucher- As described in Section 5.2, the pledge will sign a pledge voucher-
request containing the registrar's public key in the proximity- request containing the registrar's public key in the proximity-
registrar-cert field. The base64 has been wrapped at 60 characters registrar-cert field. The base64 has been wrapped at 60 characters
for presentation reasons. for presentation reasons.
MIIHHAYJKoZIhvcNAQcCoIIHDTCCBwkCAQExDzANBglghkgBZQMEAgEFADCC MIIHHAYJKoZIhvcNAQcCoIIHDTCCBwkCAQExDzANBglghkgBZQMEAgEFADCC
Aw4GCSqGSIb3DQEHAaCCAv8EggL7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2 Aw4GCSqGSIb3DQEHAaCCAv8EggL7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2
b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i
OiIyMDE3LTA5LTAxIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAw OiIyMDE3LTA5LTAxIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAw
skipping to change at page 84, line 5 skipping to change at page 82, line 5
GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVu GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVu
c3RydW5nIEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAx c3RydW5nIEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAx
MTI0NVowQzESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJ MTI0NVowQzESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJ
c2FuZGVsbWFuMRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggq c2FuZGVsbWFuMRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggq
hkjOPQMBBwNCAAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6 hkjOPQMBBwNCAAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6
MwF5z+Dpb8/puhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAA MwF5z+Dpb8/puhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAA
MAoGCCqGSM49BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY MAoGCCqGSM49BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY
2jkDx062nuNifVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77 2jkDx062nuNifVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77
XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYRc3o="}} XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYRc3o="}}
E.2.2. Registrar to MASA D.2.2. Registrar to MASA
As described in Section 5.4 the registrar will sign a registrar As described in Section 5.4 the registrar will sign a registrar
voucher-request, and will include pledge's voucher request in the voucher-request, and will include pledge's voucher request in the
prior-signed-voucher-request. prior-signed-voucher-request.
MIIN2gYJKoZIhvcNAQcCoIINyzCCDccCAQExDzANBglghkgBZQMEAgEFADCC MIIN2gYJKoZIhvcNAQcCoIINyzCCDccCAQExDzANBglghkgBZQMEAgEFADCC
Ck4GCSqGSIb3DQEHAaCCCj8Eggo7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2 Ck4GCSqGSIb3DQEHAaCCCj8Eggo7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2
b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i
OiIyMDE3LTA5LTE1VDAwOjAwOjAwLjAwMFoiLCJzZXJpYWwtbnVtYmVyIjoi OiIyMDE3LTA5LTE1VDAwOjAwOjAwLjAwMFoiLCJzZXJpYWwtbnVtYmVyIjoi
SkFEQTEyMzQ1Njc4OSIsIm5vbmNlIjoiYWJjZDEyMzQiLCJwcmlvci1zaWdu SkFEQTEyMzQ1Njc4OSIsIm5vbmNlIjoiYWJjZDEyMzQiLCJwcmlvci1zaWdu
skipping to change at page 89, line 47 skipping to change at page 87, line 47
3452:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3452:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc
3462:d=10 hl=2 l= 1 prim: INTEGER :28 3462:d=10 hl=2 l= 1 prim: INTEGER :28
3465:d=5 hl=2 l= 10 cons: SEQUENCE 3465:d=5 hl=2 l= 10 cons: SEQUENCE
3467:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3467:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S
HA256 HA256
3477:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30 3477:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30
4502200DDA79B8F52530AA7B1854000FBCA9020A85BFCABE2A426DE9CDCE 4502200DDA79B8F52530AA7B1854000FBCA9020A85BFCABE2A426DE9CDCE
EE2569548F02210083D6EF019318A9BE2830BC80E659F8E561D27172FA33 EE2569548F02210083D6EF019318A9BE2830BC80E659F8E561D27172FA33
3637DFAB98F750783B46 3637DFAB98F750783B46
E.2.3. MASA to Registrar D.2.3. MASA to Registrar
The MASA will return a voucher to the registrar, to be relayed to the The MASA will return a voucher to the registrar, to be relayed to the
pledge. pledge.
MIIG3AYJKoZIhvcNAQcCoIIGzTCCBskCAQExDzANBglghkgBZQMEAgEFADCC MIIG3AYJKoZIhvcNAQcCoIIGzTCCBskCAQExDzANBglghkgBZQMEAgEFADCC
AxAGCSqGSIb3DQEHAaCCAwEEggL9eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6 AxAGCSqGSIb3DQEHAaCCAwEEggL9eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6
eyJhc3NlcnRpb24iOiJsb2dnZWQiLCJjcmVhdGVkLW9uIjoiMjAxNy0xMC0x eyJhc3NlcnRpb24iOiJsb2dnZWQiLCJjcmVhdGVkLW9uIjoiMjAxNy0xMC0x
MlQxMzo1NDozMS40MzktMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtRDAt MlQxMzo1NDozMS40MzktMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtRDAt
RTUtRjItMDAtMDIiLCJub25jZSI6IkRzczk5c0JyM3BOTU9BQ2UtTFlZN3ci RTUtRjItMDAtMDIiLCJub25jZSI6IkRzczk5c0JyM3BOTU9BQ2UtTFlZN3ci
LCJwaW5uZWQtZG9tYWluLWNlcnQiOiJNSUlCcmpDQ0FUT2dBd0lCQWdJQkF6 LCJwaW5uZWQtZG9tYWluLWNlcnQiOiJNSUlCcmpDQ0FUT2dBd0lCQWdJQkF6
 End of changes. 81 change blocks. 
326 lines changed or deleted 182 lines changed or added

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