draft-ietf-anima-bootstrapping-keyinfra-16.txt   draft-ietf-anima-bootstrapping-keyinfra-17.txt 
ANIMA WG M. Pritikin ANIMA WG M. Pritikin
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Richardson Intended status: Standards Track M. Richardson
Expires: December 23, 2018 Sandelman Expires: May 9, 2019 Sandelman
M. Behringer M. Behringer
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
K. Watsen K. Watsen
Juniper Networks Juniper Networks
June 21, 2018 November 5, 2018
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-16 draft-ietf-anima-bootstrapping-keyinfra-17
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 December 23, 2018. This Internet-Draft will expire on May 9, 2019.
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 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 5 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 9 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 9
1.3.1. Support environment . . . . . . . . . . . . . . . . . 9 1.3.1. Support environment . . . . . . . . . . . . . . . . . 9
1.3.2. Constrained environments . . . . . . . . . . . . . . 10 1.3.2. Constrained environments . . . . . . . . . . . . . . 10
1.3.3. Network Access Controls . . . . . . . . . . . . . . . 11 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 11
1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 11
1.4. Leveraging the new key infrastructure / next steps . . . 11 1.4. Leveraging the new key infrastructure / next steps . . . 11
1.5. Requirements for Autonomic Network Infrastructure (ANI) 1.5. Requirements for Autonomic Network Infrastructure (ANI)
devices . . . . . . . . . . . . . . . . . . . . . . . . . 11 devices . . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 12 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 12
2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 14 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 14
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 15 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 15
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 16 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 16
2.3.1. Identification of the Pledge . . . . . . . . . . . . 16 2.3.1. Identification of the Pledge . . . . . . . . . . . . 16
2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 17 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 17
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 18 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 13 skipping to change at page 3, line 14
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) . . . . . . . . 34 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 . . . . . . . 36 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 36
5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 38 5.3. Registrar Authorization of
5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 38 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4.1. MASA renewal of expired vouchers . . . . . . . . . . 40 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 38
5.4.2. MASA verification of voucher-request signature 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 39
5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 40
5.5.2. MASA verification of voucher-request signature
consistency . . . . . . . . . . . . . . . . . . . . . 40 consistency . . . . . . . . . . . . . . . . . . . . . 40
5.4.3. MASA authentication of registrar (certificate) . . . 40 5.5.3. MASA authentication of registrar (certificate) . . . 41
5.4.4. MASA revocation checking of registrar (certificate) . 41 5.5.4. MASA revocation checking of registrar (certificate) . 41
5.4.5. MASA verification of pledge prior-signed-voucher- 5.5.5. MASA verification of pledge prior-signed-voucher-
request . . . . . . . . . . . . . . . . . . . . . . . 41 request . . . . . . . . . . . . . . . . . . . . . . . 41
5.4.6. MASA pinning of registrar . . . . . . . . . . . . . . 41 5.5.6. MASA pinning of registrar . . . . . . . . . . . . . . 42
5.4.7. MASA nonce handling . . . . . . . . . . . . . . . . . 41 5.5.7. MASA nonce handling . . . . . . . . . . . . . . . . . 42
5.5. MASA and Registrar Voucher Response . . . . . . . . . . . 42 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 42
5.5.1. Pledge voucher verification . . . . . . . . . . . . . 44 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 45
5.5.2. Pledge authentication of provisional TLS connection . 44 5.6.2. Pledge authentication of provisional TLS connection . 45
5.6. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 45 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 46
5.7. Registrar audit log request . . . . . . . . . . . . . . . 46 5.8. Registrar audit log request . . . . . . . . . . . . . . . 47
5.7.1. MASA audit log response . . . . . . . . . . . . . . . 47 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 48
5.7.2. Registrar audit log verification . . . . . . . . . . 49 5.8.2. Registrar audit log verification . . . . . . . . . . 49
5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 50 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 50
5.8.1. EST Distribution of CA Certificates . . . . . . . . . 50 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 51
5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51
5.8.3. EST Client Certificate Request . . . . . . . . . . . 52 5.9.3. EST Client Certificate Request . . . . . . . . . . . 52
5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52
5.8.5. Multiple certificates . . . . . . . . . . . . . . . . 53 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 53
5.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53
6. Reduced security operational modes . . . . . . . . . . . . . 53 6. Reduced security operational modes . . . . . . . . . . . . . 54
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 53 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 54
6.2. Pledge security reductions . . . . . . . . . . . . . . . 54 6.2. Pledge security reductions . . . . . . . . . . . . . . . 55
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 . . . . . . . . . . . . . . . . . . . . . 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
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. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 57
7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 57 7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 58
7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 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. DoS against MASA . . . . . . . . . . . . . . . . . . . . 60
9.2. Trusting manufacturers . . . . . . . . . . . . . . . . . 61 9.2. Freshness in Voucher-Requests . . . . . . . . . . . . . . 60
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 9.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 62
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63
11.1. Normative References . . . . . . . . . . . . . . . . . . 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 63
11.1. Normative References . . . . . . . . . . . . . . . . . . 63
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 . . . . . . . . . . . . 68
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 67 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 68
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 67 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 68
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 68 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 68
Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 68 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 69
Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 71 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 71
D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 71 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 71
D.1.1. MASA key pair for voucher signatures . . . . . . . . 71 D.1.1. MASA key pair for voucher signatures . . . . . . . . 71
D.1.2. Manufacturer key pair for IDevID signatures . . . . . 71 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 71
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 72 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 72
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 74 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 74
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 76 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 75
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 76 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 75
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 82 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 81
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 87 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92
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.
skipping to change at page 11, line 18 skipping to change at page 11, line 18
occurred, is not required, or is integrated by the proxy and occurred, is not required, or is integrated by the proxy and
registrar in such a way that the device itself does not need to be registrar in such a way that the device itself does not need to be
aware of the details. Although the use of an X.509 Initial Device aware of the details. Although the use of an X.509 Initial Device
Identity is consistant with IEEE 802.1AR [IDevID], and allows for Identity is consistant with IEEE 802.1AR [IDevID], and allows for
alignment with 802.1X network access control methods, its use here is alignment with 802.1X network access control methods, its use here is
for pledge authentication rather than network access control. for pledge authentication rather than network access control.
Integrating this protocol with network access control, perhaps as an Integrating this protocol with network access control, perhaps as an
Extensible Authentication Protocol (EAP) method (see [RFC3748]), is Extensible Authentication Protocol (EAP) method (see [RFC3748]), is
out-of-scope. out-of-scope.
1.3.4. Bootstrapping is not Booting
This document describes "bootstrapping" as the protocol used to
obtain a local trust anchor. It is expected that this trust anchor,
along with any additional configuration information subsequently
installed, is persisted on the device across system restarts
("booting"). Bootstrapping occurs only infrequently such as when a
device is transfered to a new owner or has been reset to factory
default settings.
1.4. Leveraging the new key infrastructure / next steps 1.4. Leveraging the new key infrastructure / next steps
As a result of the protocol described herein, the bootstrapped As a result of the protocol described herein, the bootstrapped
devices have the Domain CA trust anchor in common. An end entity devices have the Domain CA trust anchor in common. An end entity
certificate has optionally been issued from the Domain CA. This certificate has optionally been issued from the Domain CA. This
makes it possible to automatically deploy services across the domain makes it possible to automatically deploy services across the domain
in a secure manner. in a secure manner.
Services that benefit from this: Services that benefit from this:
skipping to change at page 20, line 23 skipping to change at page 20, line 23
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. registrar. A circuit proxy mechanism is described in Section 4.
Additional mechanisms, including a CoAP mechanism and a stateless Additional mechanisms, including a CoAP mechanism and a stateless
IPIP mechanism are the subject of future work. 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.4). The registrar
operates as the BRSKI-EST server when pledges request vouchers (see operates as the BRSKI-EST server when pledges request vouchers (see
Section 5.1). The registrar operates as the BRSKI-EST server Section 5.1). The registrar operates as the BRSKI-EST server
"Registration Authority" if the pledge requests an end entity "Registration Authority" if the pledge requests an end entity
certificate over the BRSKI-EST connection (see Section 5.8). certificate over the BRSKI-EST connection (see Section 5.9).
The registrar uses an Implicit Trust Anchor database for The registrar uses an Implicit Trust Anchor database for
authenticating the BRSKI-MASA TLS connection MASA certificate. The authenticating the BRSKI-MASA TLS connection MASA certificate. 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.5 and Section 5.6, and an ownership tracking/auditing
function described in Section 5.6 and Section 5.7. function described in Section 5.7 and Section 5.8.
2.5.5. Public Key Infrastructure (PKI) 2.5.5. Public Key Infrastructure (PKI)
The Public Key Infrastructure (PKI) administers certificates for the The Public Key Infrastructure (PKI) administers certificates for the
domain of concerns, providing the trust anchor(s) for it and allowing domain of concerns, providing the trust anchor(s) for it and allowing
enrollment of pledges with domain certificates. enrollment of pledges with domain certificates.
The voucher provides a method for the distribution of a single PKI The voucher provides a method for the distribution of a single PKI
trust anchor (as the "pinned-domain-cert"). A distribution of the trust anchor (as the "pinned-domain-cert"). A distribution of the
full set of current trust anchors is possible using the optional EST full set of current trust anchors is possible using the optional EST
skipping to change at page 22, line 36 skipping to change at page 22, line 36
o If the voucher contains a nonce then the pledge MUST confirm the o If the voucher contains a nonce then the pledge MUST confirm the
nonce matches the original pledge voucher-request. This ensures nonce matches the original pledge voucher-request. This ensures
the voucher is fresh. See / (Section 5.2). In that case, the the voucher is fresh. See / (Section 5.2). In that case, the
voucher's created-on date MUST NOT be prior to the pledge's voucher's created-on date MUST NOT be prior to the pledge's
current reasonable date. In addition, when there is a valid current reasonable date. In addition, when there is a valid
nonce, the current reasonable date MAY be incremented to that of nonce, the current reasonable date MAY be incremented to that of
the CMS signingTime. the CMS signingTime.
o Once the voucher is accepted the validity period of the pinned- o Once the voucher is accepted the validity period of the pinned-
domain-cert in the voucher now serves as a valid time window. As domain-cert in the voucher now serves as a valid time window. As
explained in Section 5.4.4, the MASA has checked the registrar's explained in Section 5.5.4, the MASA has checked the registrar's
certificate against real clocks , the endorsement of the MASA certificate against real clocks , the endorsement of the MASA
allows the pledge to treat the notBefore and notAfter dates as allows the pledge to treat the notBefore and notAfter dates as
being constraints on any subsequent certificate validity periods being constraints on any subsequent certificate validity periods
that may need to be checked: for instance, validating peer that may need to be checked: for instance, validating peer
certificates during ANIMA ACP setup. certificates during ANIMA ACP setup.
o When accepting an enrollment certificate the validity period o When accepting an enrollment certificate the validity period
within the new certificate is assumed to be valid by the pledge. within the new certificate is assumed to be valid by the pledge.
The pledge is now willing to use this credential for client The pledge is now willing to use this credential for client
authentication. authentication.
skipping to change at page 25, line 16 skipping to change at page 25, line 16
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 [RFC8366]. Each node in the diagram is fully described described in [RFC8366]. Each node in the diagram is fully described
by the YANG module in Section 3.3. Please review the YANG module for by the YANG module in Section 3.3. Please review the 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
+---- pinned-domain-cert? binary +-- pinned-domain-cert? binary
+---- domain-cert-revocation-checks? boolean +-- domain-cert-revocation-checks? boolean
+---- nonce? binary +-- nonce? binary
+---- last-renewal-date? yang:date-and-time +-- last-renewal-date? yang:date-and-time
+---- prior-signed-voucher-request? binary +-- prior-signed-voucher-request? binary
+---- proximity-registrar-cert? binary +-- proximity-registrar-cert? binary
3.2. Examples 3.2. Examples
This section provides voucher-request examples for illustration This section provides voucher-request examples for illustration
purposes. These examples conform to the encoding rules defined in purposes. These examples conform to the encoding rules defined in
[RFC7951]. [RFC7951].
Example (1) The following example illustrates a pledge voucher- Example (1) The following example illustrates a pledge voucher-
request. The assertion leaf is indicated as 'proximity' request. The assertion leaf is indicated as 'proximity'
and the registrar's TLS server certificate is included and the registrar's TLS server certificate is included
skipping to change at page 26, line 10 skipping to change at page 26, line 10
Example (2) The following example illustrates a registrar voucher- Example (2) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is request. The 'prior-signed-voucher-request' leaf is
populated with the pledge's voucher-request (such as the populated with the pledge's voucher-request (such as the
prior example). The pledge's voucher-request, if a prior example). The pledge's voucher-request, if a
signed artifact with a CMS format signature is a binary signed artifact with a CMS format signature is a binary
object. In the JSON encoding used here it must be object. In the JSON encoding used here it must be
base64 encoded. The nonce, created-on and assertion is base64 encoded. The nonce, created-on and assertion is
carried forward. The serial-number is extracted from carried forward. The serial-number is extracted from
the pledge's Client Certificate from the TLS connection. the pledge's Client Certificate from the TLS connection.
See Section 5.4. See Section 5.5.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"assertion": "proximity", "assertion": "proximity",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
"prior-signed-voucher": "base64encodedvalue==" "prior-signed-voucher": "base64encodedvalue=="
} }
skipping to change at page 26, line 32 skipping to change at page 26, line 32
Example (3) The following example illustrates a registrar voucher- Example (3) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is not request. The 'prior-signed-voucher-request' leaf is not
populated with the pledge's voucher-request nor is the populated with the pledge's voucher-request nor is the
nonce leaf. This form might be used by a registrar nonce leaf. This form might be used by a registrar
requesting a voucher when the pledge can not communicate requesting a voucher when the pledge can not communicate
with the registrar (such as when it is powered down, or with the registrar (such as when it is powered down, or
still in packaging), and therefore could not submit a still in packaging), and therefore could not submit a
nonce. This scenario is most useful when the registrar nonce. This scenario is most useful when the registrar
is aware that it will not be able to reach the MASA is aware that it will not be able to reach the MASA
during deployment. See Section 5.4. during deployment. See Section 5.5.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"assertion": "TBD", "assertion": "TBD",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
Example (4) The following example illustrates a registrar voucher- Example (4) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is not request. The 'prior-signed-voucher-request' leaf is not
populated with the pledge voucher-request because the populated with the pledge voucher-request because the
pledge did not sign its own request. This form might be pledge did not sign its own request. This form might be
used when more constrained pledges are being deployed. used when more constrained pledges are being deployed.
The nonce is populated from the pledge's request. See The nonce is populated from the pledge's request. See
Section 5.4. Section 5.5.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"assertion": "proximity", "assertion": "proximity",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
skipping to change at page 28, line 13 skipping to change at page 28, line 13
Author: Kent Watsen Author: Kent Watsen
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Author: Max Pritikin Author: Max Pritikin
<mailto:pritikin@cisco.com> <mailto:pritikin@cisco.com>
Author: Michael Richardson Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca> <mailto:mcr+ietf@sandelman.ca>
Author: Toerless Eckert Author: Toerless Eckert
<mailto:tte+ietf@cs.fau.de>"; <mailto:tte+ietf@cs.fau.de>";
description description
"This module module defines the format for a voucher request. "This module defines the format for a voucher request.
It is a superset of the voucher itself. It is a superset of the voucher itself.
This artifact may be optionally signed. This artifact may be optionally signed.
It provides content to the MASA for consideration It provides content to the MASA for consideration
during a voucher request. during a voucher request.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in
the module text are to be interpreted as described in RFC 2119. the module text are to be interpreted as described in RFC 2119.
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2017 IETF Trust and the persons identified as
skipping to change at page 32, line 49 skipping to change at page 32, line 49
announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. announcement detailed in [I-D.ietf-anima-autonomic-control-plane].
The M_FLOOD is formatted as follows: The M_FLOOD is formatted as follows:
[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 [I-D.ietf-cbor-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
skipping to change at page 35, line 36 skipping to change at page 35, line 36
o The pledge provisionally accepts the registrar certificate during o The pledge provisionally accepts the registrar certificate during
the TLS handshake as detailed in Section 5.1. the TLS handshake as detailed in Section 5.1.
o The pledge either attempts concurrent connections, or it times out o The pledge either attempts concurrent connections, or it times out
quickly and tries connections in series. quickly and tries connections in series.
o The pledge requests and validates a voucher using the new REST o The pledge requests and validates a voucher using the new REST
calls described below. calls described below.
o The pledge completes authentication of the server certificate as o The pledge completes authentication of the server certificate as
detailed in Section 5.5.1. This moves the BRSKI-EST TLS detailed in Section 5.6.1. This moves the BRSKI-EST TLS
connection out of the provisional state. connection out of the provisional state.
o Mandatory boostrap steps conclude with voucher status telemetry o Mandatory boostrap steps conclude with voucher status telemetry
(see Section 5.6). (see Section 5.7).
The BRSKI-EST TLS connection can now be used for EST enrollment. The BRSKI-EST TLS connection can now be used for EST enrollment.
The extensions for a registrar (equivalent to EST server) are: The extensions for a registrar (equivalent to EST server) are:
o Client authentication is automated using Initial Device Identity o Client authentication is automated using Initial Device Identity
(IDevID) as per the EST certificate based client authentication. (IDevID) as per the EST certificate based client authentication.
The subject field's DN encoding MUST include the "serialNumber" The subject field's DN encoding MUST include the "serialNumber"
attribute with the device's unique serial number. attribute with the device's unique serial number.
skipping to change at page 36, line 36 skipping to change at page 36, line 36
operations. operations.
Establishment of the BRSKI-EST TLS connection is as specified in EST Establishment of the BRSKI-EST TLS connection is as specified in EST
[RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates"
[RFC7030] wherein the client is authenticated with the IDevID [RFC7030] wherein the client is authenticated with the IDevID
certificate, and the EST server (the registrar) is provisionally certificate, and the EST server (the registrar) is provisionally
authenticated with an unverified server certificate. authenticated with an unverified server certificate.
The pledge maintains a security paranoia concerning the provisional The pledge maintains a security paranoia concerning the provisional
state, and all data received, until a voucher is received and state, and all data received, until a voucher is received and
verified as specified in Section 5.5.1 verified as specified in Section 5.6.1
To avoid blocking on a single erroneous registrar the pledge MUST To avoid blocking on a single erroneous registrar the pledge MUST
drop the connection after 5 seconds in which there has been no drop the connection after 5 seconds in which there has been no
progress on the TCP connection. It should proceed to connect to any progress on the TCP connection. It should proceed to connect to any
other registrar's via any other discovered proxies if there are any. other registrar's via any other discovered proxies if there are any.
If there were no other proxies discovered, the pledge MAY continue to If there were no other proxies discovered, the pledge MAY continue to
wait, as long as it is concurrently listening for new proxy wait, as long as it is concurrently listening for new proxy
announcements. announcements.
5.2. Pledge Requests Voucher from the Registrar 5.2. Pledge Requests Voucher from the Registrar
skipping to change at page 37, line 51 skipping to change at page 37, line 51
assertion is populated. assertion is populated.
All other fields MAY be omitted in the pledge voucher-request. All other fields MAY be omitted in the pledge voucher-request.
An example JSON payload of a pledge voucher-request is in Section 3.2 An example JSON payload of a pledge voucher-request is in Section 3.2
Example 1. Example 1.
The registrar validates the client identity as described in EST The registrar validates the client identity as described in EST
[RFC7030] section 3.3.2. If the request is signed the registrar [RFC7030] section 3.3.2. If the request is signed the registrar
confirms that the 'proximity' asserion and associated 'proximity- confirms that the 'proximity' asserion and associated 'proximity-
registrar-cert' are correct. The registrar performs authorization as registrar-cert' are correct.
detailed in [[EDNOTE: UNRESOLVED. See Appendix D "Pledge
Authorization"]]. If these validations fail the registrar SHOULD 5.3. Registrar Authorization of Pledge
respond with an appropriate HTTP error code.
In a fully automated network all devices must be securely identified
and authorized to join the domain.
A Registrar accepts or declines a request to join the domain, based
on the authenticated identity presented. Automated acceptance
criteria include:
o allow any device of a specific type (as determined by the X.509
IDevID),
o allow any device from a specific vendor (as determined by the
X.509 IDevID),
o allow a specific device from a vendor (as determined by the X.509
IDevID) against a domain white list. (The mechanism for checking
a shared white list potentially used by multiple Registrars is out
of scope).
If these validations fail the registrar SHOULD respond with an
appropriate HTTP error code.
If authorization is successful the registrar obtains a voucher from If authorization is successful the registrar obtains a voucher from
the MASA service (see Section 5.4) and returns that MASA signed the MASA service (see Section 5.5) and returns that MASA signed
voucher to the pledge as described in Section 5.5. voucher to the pledge as described in Section 5.6.
5.3. BRSKI-MASA TLS establishment details 5.4. BRSKI-MASA TLS establishment details
The BRSKI-MASA TLS connection is a 'normal' TLS connection The BRSKI-MASA TLS connection is a 'normal' TLS connection
appropriate for HTTPS REST interfaces. The registrar initiates the appropriate for HTTPS REST interfaces. The registrar initiates the
connection and uses the MASA URL obtained as described in Section 2.8 connection and uses the MASA URL obtained as described in Section 2.8
for [RFC6125] authentication of the MASA. for [RFC6125] authentication of the MASA.
The primary method of registrar "authentication" by the MASA is The primary method of registrar "authentication" by the MASA is
detailed in Section 5.4. As detailed in Section 9 the MASA might detailed in Section 5.5. 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)
The authentication of the BRSKI-MASA connection does not affect the The authentication of the BRSKI-MASA connection does not affect the
voucher-request process, as voucher-requests are already signed by voucher-request process, as voucher-requests are already signed by
the registrar. Instead, this authentication provides access control the registrar. Instead, this authentication provides access control
to the audit log. to the audit log.
Implementors are advised that contacting the MASA is to establish a Implementors are advised that contacting the MASA is to establish a
secured REST connection with a web service and that there are a secured REST connection with a web service and that there are a
number of authentication models being explored within the industry. number of authentication models being explored within the industry.
Registrars are RECOMMENDED to fail gracefully and generate useful Registrars are RECOMMENDED to fail gracefully and generate useful
administrative notifications or logs in the advent of unexpected HTTP administrative notifications or logs in the advent of unexpected HTTP
401 (Unauthorized) responses from the MASA. 401 (Unauthorized) responses from the MASA.
5.4. Registrar Requests Voucher from MASA 5.5. Registrar Requests Voucher from MASA
When a registrar receives a pledge voucher-request it in turn submits When a registrar receives a pledge voucher-request it in turn submits
a registrar voucher-request to the MASA service via an HTTPS 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 [RFC8366] and is application/ The request media type is defined in [RFC8366] and is application/
voucher-cms+json. It is a JSON document that has been signed using a voucher-cms+json. It is a JSON document that has been signed using a
skipping to change at page 40, line 11 skipping to change at page 40, line 29
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 in advance. certificate since the registrar is not known to the MASA in advance.
The MASA performs the actions and validation checks described in the The MASA performs the actions and validation checks 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.5.1. MASA renewal of expired vouchers
As described in [RFC8366] vouchers are normally short lived to avoid As described in [RFC8366] vouchers are normally short lived to avoid
revocation issues. If the request is for a previous (expired) revocation issues. If the request is for a previous (expired)
voucher using the same registrar then the request for a renewed voucher using the same registrar then the request for a renewed
voucher SHOULD be automatically authorized. The MASA has sufficient voucher SHOULD be automatically authorized. The MASA has sufficient
information to determine this by examining the request, the registrar information to determine this by examining the request, the registrar
authentication, and the existing audit log. The issuance of a authentication, and the existing audit log. The issuance of a
renewed voucher is logged as detailed in Section 5.5. renewed voucher is logged as detailed in Section 5.6.
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.5.3 and Section 5.5.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.5.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
a registrar. This is confirmed by verifying that the id-kp-cmcRA a registrar. This is confirmed by verifying that the id-kp-cmcRA
extended key usage extension field (as detailed in EST RFC7030 extended key usage extension field (as detailed in EST RFC7030
section 3.6.1) exists in the certificate of the entity that signed section 3.6.1) exists in the certificate of the entity that signed
the registrar voucher-request. This verification is only a the registrar voucher-request. This verification is only a
consistency check that the unauthenticated domain CA intended the consistency check that the unauthenticated domain CA intended the
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.5.
5.4.3. MASA authentication of registrar (certificate) 5.5.3. MASA authentication of registrar (certificate)
If a nonceless voucher-request is submitted the MASA 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.
5.4.4. MASA revocation checking of registrar (certificate) 5.5.4. MASA revocation checking of registrar (certificate)
As noted in Section 5.4.3 the MASA performs registrar authentication As noted in Section 5.5.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.5.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.5.5. MASA verification of pledge prior-signed-voucher-request
The MASA MAY verify that the registrar voucher-request includes the The MASA MAY verify that the registrar voucher-request includes the
'prior-signed-voucher-request' field. If so the prior-signed- 'prior-signed-voucher-request' field. If so the prior-signed-
voucher-request MUST include a 'proximity-registrar-cert' that is voucher-request MUST include a 'proximity-registrar-cert' that is
consistent with the certificate used to sign the registrar voucher- consistent with the certificate used to sign the registrar voucher-
request. Additionally the voucher-request serial-number leaf MUST request. Additionally the voucher-request serial-number leaf 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 is signing certificate of the prior-signed-voucher-request. The MASA is
aware of which pledges support signing of their voucher requests and aware of which pledges support signing of their voucher requests and
can use this information to confirm proximity of the pledge with the can use this information to confirm proximity of the pledge with the
registrar, thus ensuring that the BRSKI-EST TLS connection has no registrar, thus ensuring that the BRSKI-EST TLS 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.5.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.5. 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
of the root public key) is determined from the pinned-domain-cert and of the root public key) is determined from the pinned-domain-cert and
is used to update the audit log. is used to update the audit log.
5.4.7. MASA nonce handling 5.5.7. MASA nonce handling
The MASA does not verify the nonce itself. It MAY perform a simple The MASA does not verify the nonce itself. It MAY perform a simple
consistency check: If the registrar voucher-request contains a nonce consistency check: If the registrar voucher-request contains a nonce
and the prior-signed-voucher-request exists then the nonce in both and the prior-signed-voucher-request exists then the nonce in both
MUST be consistent. (Recall from above that the voucher-request MUST be consistent. (Recall from above that the voucher-request
might not contain a nonce, see Section 5.4 and Section 5.4.3). might not contain a nonce, see Section 5.5 and Section 5.5.3).
The MASA MUST use the nonce from the registrar voucher-request for The MASA MUST use the nonce from the registrar voucher-request for
the resulting voucher and audit log. The prior-signed-voucher- the resulting voucher and audit log. The prior-signed-voucher-
request nonce is ignored during this operation. request nonce is ignored during this operation.
5.5. MASA and Registrar Voucher Response 5.6. MASA and Registrar Voucher Response
The MASA voucher response to the registrar is forwarded without The MASA voucher response to the registrar is forwarded without
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
skipping to change at page 43, line 40 skipping to change at page 44, line 16
"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"
} }
} }
The MASA populates the voucher fields as follows: The MASA populates the voucher fields as follows:
nonce: The nonce from the pledge if available. See Section 5.4.7. nonce: The nonce from the pledge if available. See Section 5.5.7.
assertion: The method used to verify assertion. See Section 5.4.5. assertion: The method used to verify assertion. See Section 5.5.5.
pinned-domain-cert: The domain CA cert. See Section 5.4.6. pinned-domain-cert: The domain CA cert. See Section 5.5.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.5.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 [RFC8366]. The MASA MAY set capabilities and as documented in [RFC8366]. The MASA MAY set
this field to 'false' since setting it to 'true' would require this field to 'false' since setting it to 'true' would require
that revocation information be available to the pledge and this that revocation information be available to the pledge and this
document does not make normative requirements for [RFC6961] or document does not make normative requirements for [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-
skipping to change at page 44, line 22 skipping to change at page 44, line 47
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
(on the order of a week or less). The RECOMMENDED period for (a) (on the order of a week or less). The RECOMMENDED period for (a)
is on the order of 20 minutes, so it will typically determine the is on the order of 20 minutes, so it will typically determine the
lifespan of the resulting voucher. lifespan of the resulting voucher.
Whenever a voucher is issued the MASA MUST update the audit log Whenever a voucher is issued the MASA MUST update the audit log
appropriately. The internal state requirements to maintain the audit appropriately. The internal state requirements to maintain the audit
log are out-of-scope. See Section 5.7.1 for a discussion of log are out-of-scope. See Section 5.8.1 for a discussion of
reporting the log to a registrar. reporting the log to a registrar.
5.5.1. Pledge voucher verification 5.6.1. Pledge voucher verification
The pledge MUST verify the voucher signature using the manufacturer The pledge MUST verify the voucher signature using the manufacturer
installed trust anchor associated with the manufacturer's MASA (this installed trust anchor associated with the manufacturer's MASA (this
is likely included in the pledge's firmware). is likely included in the pledge's firmware).
The pledge MUST verify the serial-number field of the signed voucher The pledge MUST verify the serial-number field of the signed voucher
matches the pledge's own serial-number. matches the pledge's own serial-number.
The pledge MUST verify that the voucher nonce field is accurate and The pledge MUST verify that the voucher nonce field is accurate and
matches the nonce the pledge submitted to this registrar, or that the matches the nonce the pledge submitted to this registrar, or that the
voucher is nonceless (see Section 6.2). voucher is nonceless (see Section 6.2).
The pledge MUST be prepared to parse and fail gracefully from a The pledge MUST be prepared to parse and fail gracefully from a
voucher response that does not contain a 'pinned-domain-cert' field. voucher response that does not contain a 'pinned-domain-cert' field.
The pledge MUST be prepared to ignore additional fields that it does The pledge MUST be prepared to ignore additional fields that it does
not recognize. not recognize.
5.5.2. Pledge authentication of provisional TLS connection 5.6.2. Pledge authentication of provisional TLS connection
The 'pinned-domain-cert' element of the voucher contains the domain The 'pinned-domain-cert' element of the voucher contains the domain
CA's public key. The pledge MUST use the 'pinned-domain-cert' trust CA's public key. The pledge MUST use the 'pinned-domain-cert' trust
anchor to immediately complete authentication of the provisional TLS anchor to immediately complete authentication of the provisional TLS
connection. connection.
If a registrar's credentials cannot be verified using the pinned- If a registrar's credentials cannot be verified using the pinned-
domain-cert trust anchor from the voucher then the TLS connection is domain-cert trust anchor from the voucher then the TLS connection is
immediately discarded and the pledge abandons attempts to bootstrap immediately discarded and the pledge abandons attempts to bootstrap
with this discovered registrar. The pledge SHOULD send voucher with this discovered registrar. The pledge SHOULD send voucher
skipping to change at page 45, line 38 skipping to change at page 46, line 19
3.6.1; but to reduce system complexity the pledge SHOULD avoid 3.6.1; but to reduce system complexity the pledge SHOULD avoid
additional discovery operations. Instead the pledge SHOULD additional discovery operations. Instead the pledge SHOULD
communicate directly with the registrar as the EST server. The communicate directly with the registrar as the EST server. The
'pinned-domain-cert' is not a complete distribution of the [RFC7030] 'pinned-domain-cert' is not a complete distribution of the [RFC7030]
section 4.1.3 CA Certificate Response, which is an additional section 4.1.3 CA Certificate Response, which is an additional
justification for the recommendation to proceed with EST key justification for the recommendation to proceed with EST key
management operations. Once a full CA Certificate Response is management operations. Once a full CA Certificate Response is
obtained it is more authoritative for the domain than the limited obtained it is more authoritative for the domain than the limited
'pinned-domain-cert' response. 'pinned-domain-cert' response.
5.6. Pledge Voucher Status Telemetry 5.7. Pledge BRSKI Status Telemetry
The domain is expected to provide indications to the system The domain is expected to provide indications to the system
administrators concerning device lifecycle status. To facilitate administrators concerning device lifecycle status. To facilitate
this it needs telemetry information concerning the device's status. this it needs telemetry information concerning the device's status.
To indicate pledge status regarding the voucher, the pledge MUST post To indicate pledge status regarding the voucher, the pledge MUST post
a status message. a status message.
The posted data media type: application/json The posted data media type: application/json
skipping to change at page 46, line 28 skipping to change at page 47, line 10
The server SHOULD respond with an HTTP 200 but MAY simply fail with The server SHOULD respond with an HTTP 200 but MAY simply fail with
an HTTP 404 error. The client ignores any response. Within the an HTTP 404 error. The client ignores any response. Within the
server logs the server SHOULD capture this telemetry information. server logs the server SHOULD capture this telemetry information.
The reason-context attribute is an arbitrary JSON object (literal The reason-context attribute is an arbitrary JSON object (literal
value or hash of values) which provides additional information value or hash of values) which provides additional information
specific to this pledge. The contents of this field are not subject specific to this pledge. The contents of this field are not subject
to standardization. to standardization.
Additional standard responses MAY be added via Specification Additional standard JSON fields in this POST MAY be added, see
Required. Section 7.3.
5.7. Registrar audit log request 5.8. Registrar audit log request
After receiving the voucher status telemetry Section 5.6, the After receiving the pledge status telemetry Section 5.7, the
registrar SHOULD request the MASA audit log from the MASA service. registrar SHOULD request the MASA audit log from the MASA service.
This is done with an HTTP GET using the operation path value of This is done with an HTTP GET using the operation path value of
"/.well-known/est/requestauditlog". "/.well-known/est/requestauditlog".
The registrar SHOULD HTTP POST the same registrar voucher-request as The registrar SHOULD HTTP POST the same registrar voucher-request as
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 which log is requested so the appropriate number" informs the MASA which log is requested so the appropriate
log can be prepared for the response. Using the same media type and log can be prepared for the response. Using the same media type and
skipping to change at page 47, line 38 skipping to change at page 48, line 17
The request media type is: The request media type is:
application/voucher-cms+json The request is a "YANG-defined JSON application/voucher-cms+json The request 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 Section 3 using the JSON encoded described in [RFC7951]. The in Section 3 using the JSON encoded described in [RFC7951]. The
registrar MUST sign the request. The entire registrar certificate registrar MUST sign the request. The entire registrar certificate
chain, up to and including the Domain CA, MUST be included in the chain, up to and including the Domain CA, MUST be included in the
CMS structure. CMS structure.
5.7.1. MASA audit log response 5.8.1. MASA audit log response
A log data file is returned consisting of all log entries. The A log data file is returned consisting of all log entries. The
returned data is in JSON format ([RFC7951]), and the Content-Type returned data is in JSON format ([RFC7951]), and the Content-Type
SHOULD be "application/json". For example: SHOULD be "application/json". For example:
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"<date/time of the entry>", "date":"<date/time of the entry>",
"domainID":"<domainID extracted from voucher-request>", "domainID":"<domainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or the exact string 'NULL')>" "nonce":"<any nonce if supplied (or the exact string 'NULL')>"
"assertion":"<the value from the voucher assertion leaf>" "assertion":"<the value from the voucher assertion leaf>"
"truncated":"<the number of domainID entries truncated>"
}, },
{ {
"date":"<date/time of the entry>", "date":"<date/time of the entry>",
"domainID":"<anotherDomainID extracted from voucher-request>", "domainID":"<anotherDomainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or the exact string 'NULL')>" "nonce":"<any nonce if supplied (or the exact string 'NULL')>"
"assertion":"<the value from the voucher assertion leaf>" "assertion":"<the value from the voucher assertion leaf>"
} }
], ],
"truncation": { "truncation": {
"nonced duplicates": <number of entries truncated>, "nonced duplicates": "<total number of entries truncated>",
"nonceless duplicates": <number of entries truncated>, "nonceless duplicates": "<total number of entries truncated>",
"arbitrary": <number of entries trucated> "arbitrary": "<number of domainID entries removed entirely>"
} }
} }
Distribution of a large log is less than ideal. This structure can Distribution of a large log is less than ideal. This structure can
be optimized as follows: Nonced or Nonceless entries for the same be optimized as follows: Nonced or Nonceless entries for the same
domainID MAY be truncated from the log leaving only the single most domainID MAY be truncated from the log leaving only the single most
recent nonced or nonceless entry. The log SHOULD NOT be further recent nonced or nonceless entry for that domainID. In the case of
reduced but there could exist operational situation where maintaining truncation the 'event' truncation value SHOULD contain a count of the
the full log is not possible. In such situations the log MAY be number of events for this domainID that were truncated. The log
arbitrarily truncated for length. The trunctation method(s) used SHOULD NOT be further reduced but there could exist operational
MUST be indicated in the JSON truncation dictionary using "nonced situation where maintaining the full log is not possible. In such
duplicates", "nonceless duplicates", and "arbitrary" where the number situations the log MAY be arbitrarily truncated for length, with the
of entries that have been truncation is indicated. If the truncation number of removed entries indicated as 'arbitrary'.
count exceeds 1024 then the MASA MAY use this value without further
incrementing it. If the truncation count exceeds 1024 then the MASA MAY use this value
without further incrementing it.
A log where duplicate entries for the same domain have been truncated A log where duplicate entries for the same domain have been truncated
("nonced duplicates" and/or "nonceless duplicates) could still be ("nonced duplicates" and/or "nonceless duplicates) could still be
acceptable for informed decisions. A log that has had "arbitrary" acceptable for informed decisions. A log that has had "arbitrary"
truncations is less acceptable but manufacturer transparency is truncations is less acceptable but manufacturer transparency is
better than hidden truncations. better than hidden truncations.
This document specifies a simple log format as provided by the MASA This document specifies a simple log format as provided by the MASA
service to the registrar. This format could be improved by service to the registrar. This format could be improved by
distributed consensus technologies that integrate vouchers with distributed consensus technologies that integrate vouchers with
technologies such as block-chain or hash trees or optimized logging technologies such as block-chain or hash trees or optimized logging
approaches. Doing so is out of the scope of this document but is an approaches. Doing so is out of the scope of this document but is an
anticipated improvement for future work. As such, the registrar anticipated improvement for future work. As such, the registrar
client SHOULD anticipate new kinds of responses, and SHOULD provide client SHOULD anticipate new kinds of responses, and SHOULD provide
operator controls to indicate how to process unknown responses. operator controls to indicate how to process unknown responses.
5.7.2. Registrar audit log verification 5.8.2. Registrar audit log verification
Each time the Manufacturer Authorized Signing Authority (MASA) issues Each time the Manufacturer Authorized Signing Authority (MASA) issues
a voucher, it places it into the audit log for that device. The a voucher, it places it into the audit log for that device. The
details are described in Section 5.7. The contents of the audit log details are described in Section 5.8. The contents of the audit log
can express a variety of trust levels, and this section explains what can express a variety of trust levels, and this section explains what
kind of trust a registrar can derive from the entries. kind of trust a registrar can derive from the entries.
While the audit log provides a list of vouchers that were issued by While the audit log provides a list of vouchers that were issued by
the MASA, the vouchers are issued in response to voucher-requests, the MASA, the vouchers are issued in response to voucher-requests,
and it is the contents of the voucher-requests which determines how and it is the contents of the voucher-requests which determines how
meaningful the audit log entries are. meaningful the audit log entries are.
A registrar SHOULD use the log information to make an informed A registrar SHOULD use the log information to make an informed
decision regarding the continued bootstrapping of the pledge. The decision regarding the continued bootstrapping of the pledge. The
skipping to change at page 50, line 22 skipping to change at page 50, line 42
A relatively simple policy is to white list known (internal or A relatively simple policy is to white list known (internal or
external) domainIDs and to require all vouchers to have a nonce and/ external) domainIDs and to require all vouchers to have a nonce and/
or require that all nonceless vouchers be from a subset (e.g. only or require that all nonceless vouchers be from a subset (e.g. only
internal) domainIDs. A simple action is to revoke any locally issued internal) domainIDs. A simple action is to revoke any locally issued
credentials for the pledge in question or to refuse to forward the credentials for the pledge in question or to refuse to forward the
voucher. A registrar MAY be configured to ignore the history of the voucher. A registrar MAY be configured to ignore the history of the
device but it is RECOMMENDED that this only be configured if hardware device but it is RECOMMENDED that this only be configured if hardware
assisted NEA [RFC5209] is supported. assisted NEA [RFC5209] is supported.
5.8. EST Integration for PKI bootstrapping 5.9. EST Integration for PKI bootstrapping
The pledge SHOULD follow the BRSKI operations with EST enrollment The pledge SHOULD follow the BRSKI operations with EST enrollment
operations including "CA Certificates Request", "CSR Attributes" and operations including "CA Certificates Request", "CSR Attributes" and
"Client Certificate Request" or "Server-Side Key Generation", etc. "Client Certificate Request" or "Server-Side Key Generation", etc.
This is a relatively seamless integration since BRSKI REST calls This is a relatively seamless integration since BRSKI REST calls
provide an automated alternative to the manual bootstrapping method provide an automated alternative to the manual bootstrapping method
described in [RFC7030]. As noted above, use of HTTP 1.1 persistent described in [RFC7030]. As noted above, use of HTTP 1.1 persistent
connections simplifies the pledge state machine. connections simplifies the pledge state machine.
An ANIMA ANI pledge MUST implement the EST automation extensions An ANIMA ANI pledge MUST implement the EST automation extensions
skipping to change at page 50, line 46 skipping to change at page 51, line 19
Although EST allows clients to obtain multiple certificates by Although EST allows clients to obtain multiple certificates by
sending multiple CSR requests BRSKI mandates use of the CSR sending multiple CSR requests BRSKI mandates use of the CSR
Attributes request and mandates that the registrar validate the CSR Attributes request and mandates that the registrar validate the CSR
against the expected attributes. This implies that client requests against the expected attributes. This implies that client requests
will "look the same" and therefore result in a single logical will "look the same" and therefore result in a single logical
certificate being issued even if the client were to make multiple certificate being issued even if the client were to make multiple
requests. Registrars MAY contain more complex logic but doing so is requests. Registrars MAY contain more complex logic but doing so is
out-of-scope of this specification. BRSKI does not signal any out-of-scope of this specification. BRSKI does not signal any
enhancement or restriction to this capability. enhancement or restriction to this capability.
5.8.1. EST Distribution of CA Certificates 5.9.1. EST Distribution of CA Certificates
The pledge SHOULD request the full EST Distribution of CA The pledge SHOULD request the full EST Distribution of CA
Certificates message. See RFC7030, section 4.1. Certificates message. See RFC7030, section 4.1.
This ensures that the pledge has the complete set of current CA This ensures that the pledge has the complete set of current CA
certificates beyond the pinned-domain-cert (see Section 5.5.1 for a certificates beyond the pinned-domain-cert (see Section 5.6.1 for a
discussion of the limitations inherent in having a single certificate discussion of the limitations inherent in having a single certificate
instead of a full CA Certificates response.) Although these instead of a full CA Certificates response.) Although these
limitations are acceptable during initial bootstrapping, they are not limitations are acceptable during initial bootstrapping, they are not
appropriate for ongoing PKIX end entity certificate validation. appropriate for ongoing PKIX end entity certificate validation.
5.8.2. EST CSR Attributes 5.9.2. EST CSR Attributes
Automated bootstrapping occurs without local administrative Automated bootstrapping occurs without local administrative
configuration of the pledge. In some deployments it is plausible configuration of the pledge. In some deployments it is plausible
that the pledge generates a certificate request containing only that the pledge generates a certificate request containing only
identity information known to the pledge (essentially the X.509 identity information known to the pledge (essentially the X.509
IDevID information) and ultimately receives a certificate containing IDevID information) and ultimately receives a certificate containing
domain specific identity information. Conceptually the CA has domain specific identity information. Conceptually the CA has
complete control over all fields issued in the end entity complete control over all fields issued in the end entity
certificate. Realistically this is operationally difficult with the certificate. Realistically this is operationally difficult with the
current status of PKI certificate authority deployments, where the current status of PKI certificate authority deployments, where the
skipping to change at page 52, line 7 skipping to change at page 52, line 26
"ACP information" field. See "ACP information" field. See
[I-D.ietf-anima-autonomic-control-plane] for more details. [I-D.ietf-anima-autonomic-control-plane] for more details.
The registrar MUST also confirm that the resulting CSR is formatted The registrar MUST also confirm that the resulting CSR is formatted
as indicated before forwarding the request to a CA. If the registrar as indicated before forwarding the request to a CA. If the registrar
is communicating with the CA using a protocol such as full CMC, which is communicating with the CA using a protocol such as full CMC, which
provides mechanisms to override the CSR attributes, then these provides mechanisms to override the CSR attributes, then these
mechanisms MAY be used even if the client ignores CSR Attribute mechanisms MAY be used even if the client ignores CSR Attribute
guidance. guidance.
5.8.3. EST Client Certificate Request 5.9.3. EST Client Certificate Request
The pledge MUST request a new client certificate. See RFC7030, The pledge MUST request a new client certificate. See RFC7030,
section 4.2. section 4.2.
5.8.4. Enrollment Status Telemetry 5.9.4. Enrollment Status Telemetry
For automated bootstrapping of devices, the adminstrative elements For automated bootstrapping of devices, the adminstrative elements
providing bootstrapping also provide indications to the system providing bootstrapping also provide indications to the system
administrators concerning device lifecycle status. This might administrators concerning device lifecycle status. This might
include information concerning attempted bootstrapping messages seen include information concerning attempted bootstrapping messages seen
by the client, MASA provides logs and status of credential by the client, MASA provides logs and status of credential
enrollment. [RFC7030] assumes an end user and therefore does not enrollment. [RFC7030] assumes an end user and therefore does not
include a final success indication back to the server. This is include a final success indication back to the server. This is
insufficient for automated use cases. insufficient for automated use cases.
skipping to change at page 53, line 14 skipping to change at page 53, line 33
The server SHOULD respond with an HTTP 200 but MAY simply fail with The server SHOULD respond with an HTTP 200 but MAY simply fail with
an HTTP 404 error. an HTTP 404 error.
Within the server logs the server MUST capture if this message was Within the server logs the server MUST capture if this message was
received over an TLS session with a matching client certificate. received over an TLS session with a matching client certificate.
This allows for clients that wish to minimize their crypto operations This allows for clients that wish to minimize their crypto operations
to simply POST this response without renegotiating the TLS session - to simply POST this response without renegotiating the TLS session -
at the cost of the server not being able to accurately verify that at the cost of the server not being able to accurately verify that
enrollment was truly successful. enrollment was truly successful.
5.8.5. Multiple certificates 5.9.5. Multiple certificates
Pledges that require multiple certificates could establish direct EST Pledges that require multiple certificates could establish direct EST
connections to the registrar. connections to the registrar.
5.8.6. EST over CoAP 5.9.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.ietf-ace-coap-est] and that CoAP subsequent documents such as [I-D.ietf-ace-coap-est] and that CoAP
mappings for BRSKI will be discussed either there or in future work. mappings for BRSKI will be discussed either there or in future work.
skipping to change at page 55, line 7 skipping to change at page 55, line 31
3. The pledge MAY have an operational mode where it skips voucher 3. The pledge MAY have an operational mode where it skips voucher
validation one time. For example if a physical button is validation one time. For example if a physical button is
depressed during the bootstrapping operation. This can be useful depressed during the bootstrapping operation. This can be useful
if the manufacturer service is unavailable. This behavior SHOULD if the manufacturer service is unavailable. This behavior SHOULD
be available via local configuration or physical presence methods be available via local configuration or physical presence methods
(such as use of a serial/craft console) to ensure new entities (such as use of a serial/craft console) to ensure new entities
can always be deployed even when autonomic methods fail. This can always be deployed even when autonomic methods fail. This
allows for unsecured imprint. allows for unsecured imprint.
It is RECOMMENDED that "trust on first use" or skipping voucher It is RECOMMENDED that "trust on first use" or any method of skipping
validation only be available if hardware assisted Network Endpoint voucher validation (including use of craft serial console) only be
Assessment [RFC5209] is supported. This recommendation ensures that available if hardware assisted Network Endpoint Assessment [RFC5209]
domain network monitoring can detect innappropriate use of offline or is supported. This recommendation ensures that domain network
emergency deployment procedures. monitoring can detect innappropriate use of offline or emergency
deployment procedures when voucher-based bootstrapping is not used.
6.3. Registrar security reductions 6.3. Registrar security reductions
A registrar can choose to accept devices using less secure methods. A registrar can choose to accept devices using less secure methods.
These methods are acceptable when low security models are needed, as These methods are acceptable when low security models are needed, as
the security decisions are being made by the local administrator, but the security decisions are being made by the local administrator, but
they MUST NOT be the default behavior: they MUST NOT be the default behavior:
1. A registrar MAY choose to accept all devices, or all devices of a 1. A registrar MAY choose to accept all devices, or all devices of a
particular type, at the administrator's discretion. This could particular type, at the administrator's discretion. This could
occur when informing all registrars of unique identifiers of new occur when informing all registrars of unique identifiers of new
entities might be operationally difficult. entities might be operationally difficult.
2. A registrar MAY choose to accept devices that claim a unique 2. A registrar MAY choose to accept devices that claim a unique
identity without the benefit of authenticating that claimed identity without the benefit of authenticating that claimed
identity. This could occur when the pledge does not include an identity. This could occur when the pledge does not include an
X.509 IDevID factory installed credential. New Entities without X.509 IDevID factory installed credential. New Entities without
an X.509 IDevID credential MAY form the Section 5.2 request using an X.509 IDevID credential MAY form the Section 5.2 request using
the Section 5.4 format to ensure the pledge's serial number the Section 5.5 format to ensure the pledge's serial number
information is provided to the registrar (this includes the information is provided to the registrar (this includes the
IDevID AuthorityKeyIdentifier value, which would be statically IDevID AuthorityKeyIdentifier value, which would be statically
configured on the pledge.) The pledge MAY refuse to provide a configured on the pledge.) The pledge MAY refuse to provide a
TLS client certificate (as one is not available.) The pledge TLS client certificate (as one is not available.) The pledge
SHOULD support HTTP-based or certificate-less TLS authentication SHOULD support HTTP-based or certificate-less TLS authentication
as described in EST RFC7030 section 3.3.2. A registrar MUST NOT as described in EST RFC7030 section 3.3.2. A registrar MUST NOT
accept unauthenticated New Entities unless it has been configured accept unauthenticated New Entities unless it has been configured
to do so by an administrator that has verified that only expected to do so by an administrator that has verified that only expected
new entities can communicate with a registrar (presumably via a new entities can communicate with a registrar (presumably via a
physically secured perimeter.) physically secured perimeter.)
skipping to change at page 57, line 11 skipping to change at page 57, line 31
7. IANA Considerations 7. IANA Considerations
This document requires the following IANA actions: This document requires the following IANA actions:
7.1. Well-known EST registration 7.1. Well-known EST registration
This document extends the definitions of "est" (so far defined via This document extends the definitions of "est" (so far defined via
RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
well-known-uris.xhtml" registry as follows: well-known-uris.xhtml" registry as follows:
o add /.well-known/est/requestvoucher (see Section 5.4 ) o add /.well-known/est/requestvoucher (see Section 5.5 )
o add /.well-known/est/requestauditlog (see Section 5.6) o add /.well-known/est/requestauditlog (see Section 5.7)
7.2. PKIX Registry 7.2. PKIX Registry
IANA is requested to register the following: IANA is requested to register the following:
This document requests a number for id-mod-MASAURLExtn2016(TBD) from This document requests a number for id-mod-MASAURLExtn2016(TBD) from
the pkix(7) id-mod(0) Registry. [[EDNOTE: fix names]] the pkix(7) id-mod(0) Registry. [[EDNOTE: fix names]]
This document requests a number from the id-pe registry for id-pe- This document requests a number from the id-pe registry for id-pe-
masa-url. XXX masa-url. XXX
7.3. Voucher Status Telemetry 7.3. Pledge BRSKI Status Telemetry
IANA is requested to create a registry entitled: _Voucher Status IANA is requested to create a new Registry entitled: "BRSKI
Telemetry Attributes_. New items can be added using the Parameters", and within that Registry to create a table called:
Specification Required. The following items are to be in the initial "Pledge BRSKI Status Telemetry Attributes". New items can be added
registration, with this document as the reference: using the Specification Required. The following items are to be in
the initial registration, with this document (Section 5.7) as the
reference:
o version o version
o Status o Status
o Reason o Reason
o reason-context o reason-context
7.4. DNS Service Names 7.4. DNS Service Names
skipping to change at page 59, line 7 skipping to change at page 59, line 20
key identifier of the domain. A privacy sensitive domain could key identifier of the domain. A privacy sensitive domain could
theoretically generate a new domainID for each device being deployed. theoretically generate a new domainID for each device being deployed.
Similarly a privacy sensitive domain would likely purchase devices Similarly a privacy sensitive domain would likely purchase devices
that support proximity assertions from a manufacturer that does not that support proximity assertions from a manufacturer that does not
require sales channel integrations. This would result in a require sales channel integrations. This would result in a
significant level of privacy while maintaining the security significant level of privacy while maintaining the security
characteristics provided by Registrar based audit log inspection. characteristics provided by Registrar based audit log inspection.
9. Security Considerations 9. Security Considerations
There are uses cases where the MASA could be unavailable or This document details a protocol for bootstrapping that balances
uncooperative to the Registrar. They include planned and unplanned operational concerns against security concerns. As detailed in the
network partitions, changes to MASA policy, or other instances where introduction, and touched on again in Section 6, the protocol allows
MASA policy rejects a claim. These introduce an operational risk to for reduced security modes. These attempt to deliver additional
the Registrar owner that MASA behavior might limit the ability to re- control to the local administrator and owner in cases where less
boostrap a pledge device. For example this might be an issue during security provides operational benefits. This section goes into more
disaster recovery. This risk can be mitigated by Registrars that detail about a variety of specific considerations.
request and maintain long term copies of "nonceless" vouchers. In
that way they are guaranteed to be able to repeat bootstrapping for
their devices.
The issuance of nonceless vouchers themselves creates a security
concern. If the Registrar of a previous domain can intercept
protocol communications then it can use a previously issued nonceless
voucher to establish management control of a pledge device even after
having sold it. This risk is mitigated by recording the issuance of
such vouchers in the MASA audit log that is verified by the
subsequent Registrar. This reduces the resale value of the equipment
because future owners will detect the lowered security inherent in
the existence of a nonceless voucher that would be trusted by their
pledge. This reflects a balance between partition resistant recovery
and security of future bootstrapping. Registrars take the pledge's
audit history into account when applying policy to new devices.
The MASA is exposed to DoS attacks wherein attackers claim an
unbounded number of devices. Ensuring a registrar is representative
of a valid manufacturer customer, even without validating ownership
of specific pledge devices, helps to mitigate this. Pledge
signatures on the pledge voucher-request, as forwarded by the
registrar in the prior-signed-voucher-request field of the registrar
voucher-request, significantly reduce this risk by ensuring the MASA
can confirm proximity between the pledge and the registrar making the
request. This mechanism is optional to allow for constrained
devices.
To facilitate logging and administrative oversight in addition to To facilitate logging and administrative oversight, in addition to
triggering Registration verification of MASA logs the pledge reports triggering Registration verification of MASA logs, the pledge reports
on voucher parsing status to the registrar. In the case of a on voucher parsing status to the registrar. In the case of a
failure, this information is informative to a potentially malicious failure, this information is informative to a potentially malicious
registrar but this is mandated anyway because of the operational registrar. This is mandated anyway because of the operational
benefits of an informed administrator in cases where the failure is benefits of an informed administrator in cases where the failure is
indicative of a problem. The registrar is RECOMMENDED to verify MASA indicative of a problem. The registrar is RECOMMENDED to verify MASA
logs if voucher status telemetry is not received. logs if voucher status telemetry is not received.
To facilitate truely limited clients EST RFC7030 section 3.3.2 To facilitate truely limited clients EST RFC7030 section 3.3.2
requirements that the client MUST support a client authentication requirements that the client MUST support a client authentication
model have been reduced in Section 6 to a statement that the model have been reduced in Section 6 to a statement that the
registrar "MAY" choose to accept devices that fail cryptographic registrar "MAY" choose to accept devices that fail cryptographic
authentication. This reflects current (poor) practices in shipping authentication. This reflects current (poor) practices in shipping
devices without a cryptographic identity that are NOT RECOMMENDED. devices without a cryptographic identity that are NOT RECOMMENDED.
skipping to change at page 60, line 19 skipping to change at page 60, line 5
During the provisional period of the connection the pledge MUST treat During the provisional period of the connection the pledge MUST treat
all HTTP header and content data as untrusted data. HTTP libraries all HTTP header and content data as untrusted data. HTTP libraries
are regularly exposed to non-secured HTTP traffic: mature libraries are regularly exposed to non-secured HTTP traffic: mature libraries
should not have any problems. should not have any problems.
Pledges might chose to engage in protocol operations with multiple Pledges might chose to engage in protocol operations with multiple
discovered registrars in parallel. As noted above they will only do discovered registrars in parallel. As noted above they will only do
so with distinct nonce values, but the end result could be multiple so with distinct nonce values, but the end result could be multiple
vouchers issued from the MASA if all registrars attempt to claim the vouchers issued from the MASA if all registrars attempt to claim the
device. This is not a failure and the pledge choses whichever device. This is not a failure and the pledge choses whichever
voucher to accept based on internal logic. The registrar's verifying voucher to accept based on internal logic. The registrars verifying
log information will see multiple entries and take this into account log information will see multiple entries and take this into account
for their analytics purposes. for their analytics purposes.
9.1. Freshness in Voucher-Requests 9.1. DoS against MASA
There are uses cases where the MASA could be unavailable or
uncooperative to the Registrar. They include active DoS attacks,
planned and unplanned network partitions, changes to MASA policy, or
other instances where MASA policy rejects a claim. These introduce
an operational risk to the Registrar owner in that MASA behavior
might limit the ability to bootstrap a pledge device. For example
this might be an issue during disaster recovery. This risk can be
mitigated by Registrars that request and maintain long term copies of
"nonceless" vouchers. In that way they are guaranteed to be able to
bootstrap their devices.
The issuance of nonceless vouchers themselves creates a security
concern. If the Registrar of a previous domain can intercept
protocol communications then it can use a previously issued nonceless
voucher to establish management control of a pledge device even after
having sold it. This risk is mitigated by recording the issuance of
such vouchers in the MASA audit log that is verified by the
subsequent Registrar and by Pledges only bootstrapping when in a
factory default state. This reflects a balance between enabling MASA
independence during future bootstrapping and the security of
bootstrapping itself. Registrar control over requesting and auditing
nonceless vouchers allows device owners to choose an appropriate
balance.
The MASA is exposed to DoS attacks wherein attackers claim an
unbounded number of devices. Ensuring a registrar is representative
of a valid manufacturer customer, even without validating ownership
of specific pledge devices, helps to mitigate this. Pledge
signatures on the pledge voucher-request, as forwarded by the
registrar in the prior-signed-voucher-request field of the registrar
voucher-request, significantly reduce this risk by ensuring the MASA
can confirm proximity between the pledge and the registrar making the
request. This mechanism is optional to allow for constrained
devices. Supply chain integration ("know your customer") is an
additional step that MASA providers and device vendors can explore.
9.2. Freshness in Voucher-Requests
A concern has been raised that the pledge voucher-request should A concern has been raised that the pledge voucher-request should
contain some content (a nonce) provided by the registrar and/or MASA contain some content (a nonce) provided by the registrar and/or MASA
in order for those actors to verify that the pledge voucher-request in order for those actors to verify that the pledge voucher-request
is fresh. is fresh.
There are a number of operational problems with getting a nonce from There are a number of operational problems with getting a nonce from
the MASA to the pledge. It is somewhat easier to collect a random the MASA to the pledge. It is somewhat easier to collect a random
value from the registrar, but as the registrar is not yet vouched value from the registrar, but as the registrar is not yet vouched
for, such a registrar nonce has little value. There are privacy and for, such a registrar nonce has little value. There are privacy and
skipping to change at page 61, line 14 skipping to change at page 61, line 38
information, or because the MASA is in audit-log only mode), then a information, or because the MASA is in audit-log only mode), then a
voucher linking the pledge to the registrar Rm is issued. voucher linking the pledge to the registrar Rm is issued.
Such a voucher, when passed back to the pledge, would link the pledge Such a voucher, when passed back to the pledge, would link the pledge
to registrar Rm, and would permit the pledge to end the provisional to registrar Rm, and would permit the pledge to end the provisional
state. It now trusts Rm and, if it has any security vulnerabilities state. It now trusts Rm and, if it has any security vulnerabilities
leveragable by an Rm with full administrative control, can be assumed leveragable by an Rm with full administrative control, can be assumed
to be a threat against the intended registrar. to be a threat against the intended registrar.
This flow is mitigated by the intended registrar verifying the audit This flow is mitigated by the intended registrar verifying the audit
logs available from the MASA as described in Section 5.7. Rm might logs available from the MASA as described in Section 5.8. Rm might
chose to wait until after the intended registrar completes the chose to collect a voucher-request but wait until after the intended
authorization process before submitting the now-stale pledge voucher- registrar completes the authorization process before submitting it.
request. The Rm would need to remove the pledge's nonce. This pledge voucher-request would be 'stale' in that it has a nonce
that no longer matches the internal state of the pledge. In order to
successfully use any resulting voucher the Rm would need to remove
the stale nonce or anticipate the pledge's future nonce state.
Reducing the possibility of this is why the pledge is mandated to
generate a strong random or pseudo-random number nonce.
In order to successfully use the resulting "stale voucher" Rm would Additionally, in order to successfully use the resulting voucher the
have to attack the pledge and return it to a bootstrapping enabled Rm would have to attack the pledge and return it to a bootstrapping
state. This would require wiping the pledge of current configuration enabled state. This would require wiping the pledge of current
and triggering a re-bootstrapping of the pledge. This is no more configuration and triggering a re-bootstrapping of the pledge. This
likely than simply taking control of the pledge directly but if this is no more likely than simply taking control of the pledge directly
is a consideration the target network is RECOMMENDED to take the but if this is a consideration the target network is RECOMMENDED to
following steps: take the following steps:
o Ongoing network monitoring for unexpected bootstrapping attempts o Ongoing network monitoring for unexpected bootstrapping attempts
by pledges. by pledges.
o Retreival and examination of MASA log information upon the o Retreival and examination of MASA log information upon the
occurance of any such unexpected events. Rm will be listed in the occurance of any such unexpected events. Rm will be listed in the
logs. logs along with nonce information for analysis.
9.2. Trusting manufacturers 9.3. Trusting manufacturers
The BRSKI extensions to EST permit a new pledge to be completely The BRSKI extensions to EST permit a new pledge to be completely
configured with domain specific trust anchors. The link from built- configured with domain specific trust anchors. The link from built-
in manufacturer-provided trust anchors to domain-specific trust in manufacturer-provided trust anchors to domain-specific trust
anchors is mediated by the signed voucher artifact. anchors is mediated by the signed voucher artifact.
If the manufacturer's IDevID signing key is not properly validated, If the manufacturer's IDevID signing key is not properly validated,
then there is a risk that the network will accept a pledge that then there is a risk that the network will accept a pledge that
should not be a member of the network. As the address of the should not be a member of the network. As the address of the
manufacturer's MASA is provided in the IDevID using the extension manufacturer's MASA is provided in the IDevID using the extension
skipping to change at page 62, line 50 skipping to change at page 63, line 34
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-16 (work in progress), June 2018. plane-18 (work in progress), August 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.
[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,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003,
<https://www.rfc-editor.org/info/rfc3542>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005, DOI 10.17487/RFC3927, May 2005,
<https://www.rfc-editor.org/info/rfc3927>. <https://www.rfc-editor.org/info/rfc3927>.
skipping to change at page 65, line 5 skipping to change at page 65, line 33
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<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, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
skipping to change at page 65, line 34 skipping to change at page 66, line 8
[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] [I-D.ietf-ace-coap-est]
Stok, P., Kampanakis, P., Kumar, S., Richardson, M., Stok, P., Kampanakis, P., Kumar, S., Richardson, M.,
Furuhed, M., and S. Raza, "EST over secure CoAP (EST- Furuhed, M., and S. Raza, "EST over secure CoAP (EST-
coaps)", draft-ietf-ace-coap-est-02 (work in progress), coaps)", draft-ietf-ace-coap-est-06 (work in progress),
June 2018. October 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-08 (work in
progress), February 2018. progress), October 2018.
[I-D.ietf-anima-stable-connectivity] [I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf- Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-10 (work in progress), February anima-stable-connectivity-10 (work in progress), February
2018. 2018.
[I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor-
cddl-05 (work in progress), August 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-22 (work in progress), June 2018. zerotouch-25 (work in progress), September 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-25 (work Description Specification", draft-ietf-opsawg-mud-25 (work
in progress), June 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.
skipping to change at page 67, line 5 skipping to change at page 67, line 32
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013,
<https://www.rfc-editor.org/info/rfc6961>. <https://www.rfc-editor.org/info/rfc6961>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
skipping to change at page 67, line 41 skipping to change at page 68, line 26
Appendix A. IPv4 and non-ANI operations Appendix A. IPv4 and non-ANI operations
The secification of BRSKI in Section 4 intentionally only covers the The secification of BRSKI in Section 4 intentionally only covers the
mechanisms for an IPv6 pledge using Link-Local addresses. This mechanisms for an IPv6 pledge using Link-Local addresses. This
section describes non-normative extensions that can be used in other section describes non-normative extensions that can be used in other
environments. environments.
A.1. IPv4 Link Local addresses A.1. IPv4 Link Local addresses
Instead of an IPv6 link-local address, an IPv4 address may be Instead of an IPv6 link-local address, an IPv4 address may be
generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local
Addresses. Addresses.
In the case that an IPv4 Link-Local address is formed, then the In the case that an IPv4 Link-Local address is formed, then the
bootstrap process would continue as in the IPv6 case by looking for a bootstrap process would continue as in the IPv6 case by looking for a
(circuit) proxy. (circuit) proxy.
A.2. Use of DHCPv4 A.2. Use of DHCPv4
The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP
provided parameters for the Domain Name System can be used to perform provided parameters for the Domain Name System can be used to perform
skipping to change at page 73, line 12 skipping to change at page 73, line 12
c3o= c3o=
-----END CERTIFICATE----- -----END CERTIFICATE-----
The registrar public certificate as decoded by openssl's x509 The registrar public certificate as decoded by openssl's x509
utility. Note that the registrar certificate is marked with the utility. Note that the registrar certificate is marked with the
cmcRA extension. cmcRA extension.
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 3 (0x3) Serial Number: 3 (0x3)
Signature Algorithm: ecdsa-with-SHA384 Signature Algorithm: ecdsa-with-SHA384
Issuer: DC=ca, DC=sandelman, CN=Unstrung Fountain CA Issuer: DC = ca, DC = sandelman, CN = Unstrung Fount
ain CA
Validity Validity
Not Before: Sep 5 01:12:45 2017 GMT Not Before: Sep 5 01:12:45 2017 GMT
Not After : Sep 5 01:12:45 2019 GMT Not After : Sep 5 01:12:45 2019 GMT
Subject: DC=ca, DC=sandelman, CN=localhost Subject: DC = ca, DC = sandelman, CN = localhost
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7
8:17: 8:17:
34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5
3:3e: 3:3e:
03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e
9:ba: 9:ba:
13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2
f:96: f:96:
e9:9d:e2:bc:b2 e9:9d:e2:bc:b2
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Basic Constraints: X509v3 Basic Constraints:
CA:FALSE CA:FALSE
Signature Algorithm: ecdsa-with-SHA384 Signature Algorithm: ecdsa-with-SHA384
30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78: 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78:
5b: 5b:
9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e: 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e:
b6: b6:
9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21: 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21:
02: 02:
skipping to change at page 75, line 9 skipping to change at page 74, line 45
The pledge public certificate as decoded by openssl's x509 utility so The pledge public certificate as decoded by openssl's x509 utility so
that the extensions can be seen. A second custom Extension is that the extensions can be seen. A second custom Extension is
included to provided to contain the EUI48/EUI64 that the pledge will included to provided to contain the EUI48/EUI64 that the pledge will
configure. configure.
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 12 (0xc) Serial Number: 12 (0xc)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: DC=ca, DC=sandelman, CN=Unstrung Highway CA Issuer: DC = ca, DC = sandelman, CN = Unstrung Highw
ay CA
Validity Validity
Not Before: Oct 12 13:52:52 2017 GMT Not Before: Oct 12 13:52:52 2017 GMT
Not After : Dec 31 00:00:00 2999 GMT Not After : Dec 31 00:00:00 2999 GMT
Subject: DC=ca, DC=sandelman, CN=00-D0-E5-F2-00-02 Subject: DC = ca, DC = sandelman, CN = 00-D0-E5-F2-0
0-02
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04: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 82, line 7 skipping to change at page 81, line 21
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="}}
D.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.5 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
ZWQtdm91Y2hlci1yZXF1ZXN0IjoiTUlJSEhRWUpLb1pJaHZjTkFRY0NvSUlI ZWQtdm91Y2hlci1yZXF1ZXN0IjoiTUlJSEhRWUpLb1pJaHZjTkFRY0NvSUlI
RGpDQ0J3b0NBUUV4RHpBTkJnbGdoa2dCWlFNRUFnRUZBRENDQXc0R0NTcUdT RGpDQ0J3b0NBUUV4RHpBTkJnbGdoa2dCWlFNRUFnRUZBRENDQXc0R0NTcUdT
 End of changes. 105 change blocks. 
219 lines changed or deleted 281 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/