draft-ietf-anima-bootstrapping-keyinfra-43.txt   draft-ietf-anima-bootstrapping-keyinfra-44.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: 8 February 2021 Sandelman Expires: 25 March 2021 Sandelman
T.T.E. Eckert T.T.E. Eckert
Futurewei USA Futurewei USA
M.H. Behringer M.H. Behringer
K.W. Watsen K.W. Watsen
Watsen Networks Watsen Networks
7 August 2020 21 September 2020
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-43 draft-ietf-anima-bootstrapping-keyinfra-44
Abstract Abstract
This document specifies automated bootstrapping of an Autonomic This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Secure Key Infrastructure is Control Plane. To do this a Secure Key Infrastructure is
bootstrapped. This is done using manufacturer-installed X.509 bootstrapped. This is done using manufacturer-installed X.509
certificates, in combination with a manufacturer's authorizing certificates, in combination with a manufacturer's authorizing
service, both online and offline. We call this process the service, both online and offline. We call this process the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
Bootstrapping a new device can occur using a routable address and a Bootstrapping a new device can occur using a routable address and a
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 8 February 2021. This Internet-Draft will expire on 25 March 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 38 skipping to change at page 2, line 38
1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12
1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12 1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12
1.4. Leveraging the new key infrastructure / next steps . . . 12 1.4. Leveraging the new key infrastructure / next steps . . . 12
1.5. Requirements for Autonomic Network Infrastructure (ANI) 1.5. Requirements for Autonomic Network Infrastructure (ANI)
devices . . . . . . . . . . . . . . . . . . . . . . . . . 13 devices . . . . . . . . . . . . . . . . . . . . . . . . . 13
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13
2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17
2.3.1. Identification of the Pledge . . . . . . . . . . . . 18 2.3.1. Identification of the Pledge . . . . . . . . . . . . 18
2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 18 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 19
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 20 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 20
2.5. Architectural Components . . . . . . . . . . . . . . . . 23 2.5. Architectural Components . . . . . . . . . . . . . . . . 23
2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23
2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23
2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23
2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 24 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 24
2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24
2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24
2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24
skipping to change at page 3, line 33 skipping to change at page 3, line 33
5.5.4. MASA verification of domain registrar . . . . . . . . 49 5.5.4. MASA verification of domain registrar . . . . . . . . 49
5.5.5. MASA verification of pledge 5.5.5. MASA verification of pledge
prior-signed-voucher-request . . . . . . . . . . . . 50 prior-signed-voucher-request . . . . . . . . . . . . 50
5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 50 5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 50
5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 50 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 50
5.6.1. Pledge voucher verification . . . . . . . . . . . . . 53 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 53
5.6.2. Pledge authentication of provisional TLS 5.6.2. Pledge authentication of provisional TLS
connection . . . . . . . . . . . . . . . . . . . . . 54 connection . . . . . . . . . . . . . . . . . . . . . 54
5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 55 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 55
5.8. Registrar audit-log request . . . . . . . . . . . . . . . 56 5.8. Registrar audit-log request . . . . . . . . . . . . . . . 56
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 57 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 58
5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 60 5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 60
5.8.3. Registrar audit log verification . . . . . . . . . . 60 5.8.3. Registrar audit log verification . . . . . . . . . . 61
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 62 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 62
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 62 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 63
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 62 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 63
5.9.3. EST Client Certificate Request . . . . . . . . . . . 63 5.9.3. EST Client Certificate Request . . . . . . . . . . . 64
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 63 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 64
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 65 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 65
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 65 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 66
6. Clarification of transfer-encoding . . . . . . . . . . . . . 65 6. Clarification of transfer-encoding . . . . . . . . . . . . . 66
7. Reduced security operational modes . . . . . . . . . . . . . 65 7. Reduced security operational modes . . . . . . . . . . . . . 66
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 66 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 66
7.2. Pledge security reductions . . . . . . . . . . . . . . . 67 7.2. Pledge security reductions . . . . . . . . . . . . . . . 67
7.3. Registrar security reductions . . . . . . . . . . . . . . 68 7.3. Registrar security reductions . . . . . . . . . . . . . . 68
7.4. MASA security reductions . . . . . . . . . . . . . . . . 69 7.4. MASA security reductions . . . . . . . . . . . . . . . . 69
7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 69 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 69
7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 70 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 70
7.4.3. Updating or extending voucher trust anchors . . . . . 70 7.4.3. Updating or extending voucher trust anchors . . . . . 71
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 71 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 72
8.2. YANG Module Names Registry . . . . . . . . . . . . . . . 71 8.2. YANG Module Names Registry . . . . . . . . . . . . . . . 72
8.3. Well-known EST registration . . . . . . . . . . . . . . . 72 8.3. BRSKI well-known considerations . . . . . . . . . . . . . 72
8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 72 8.3.1. BRSKI .well-known registration . . . . . . . . . . . 72
8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 72 8.3.2. BRSKI .well-known registry . . . . . . . . . . . . . 73
8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 72 8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 73
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 73 8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 73
9.1. Operational Requirements . . . . . . . . . . . . . . . . 74 8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 74
9.1.1. MASA Operational Requirements . . . . . . . . . . . . 75 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 74
9.1.2. Domain Owner Operational Requirements . . . . . . . . 75 9.1. Operational Requirements . . . . . . . . . . . . . . . . 75
9.1.3. Device Operational Requirements . . . . . . . . . . . 76 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 76
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 76 9.1.2. Domain Owner Operational Requirements . . . . . . . . 76
10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 76 9.1.3. Device Operational Requirements . . . . . . . . . . . 77
10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 77 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 78
10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 78 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 78
10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 80 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 78
10.5. Manufacturers and Grey market equipment . . . . . . . . 81 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 79
10.6. Some mitigations for meddling by manufacturers . . . . . 82 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 81
10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 83 10.5. Manufacturers and Grey market equipment . . . . . . . . 82
11. Security Considerations . . . . . . . . . . . . . . . . . . . 83 10.6. Some mitigations for meddling by manufacturers . . . . . 83
11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 84 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 84
11.2. DomainID must be resistant to second-preimage attacks . 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 85
11.3. Availability of good random numbers . . . . . . . . . . 85 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 85
11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 85 11.2. DomainID must be resistant to second-preimage attacks . 86
11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 87 11.3. Availability of good random numbers . . . . . . . . . . 86
11.6. Manufacturer Maintenance of trust anchors . . . . . . . 88 11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 87
11.6.1. Compromise of Manufacturer IDevID signing keys . . . 89 11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 88
11.6.2. Compromise of MASA signing keys . . . . . . . . . . 90 11.6. Manufacturer Maintenance of trust anchors . . . . . . . 89
11.6.3. Compromise of MASA web service . . . . . . . . . . . 92 11.6.1. Compromise of Manufacturer IDevID signing keys . . . 90
11.7. YANG Module Security Considerations . . . . . . . . . . 92 11.6.2. Compromise of MASA signing keys . . . . . . . . . . 91
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 93 11.6.3. Compromise of MASA web service . . . . . . . . . . . 93
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 93 11.7. YANG Module Security Considerations . . . . . . . . . . 94
13.1. Normative References . . . . . . . . . . . . . . . . . . 93 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94
13.2. Informative References . . . . . . . . . . . . . . . . . 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 94
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 101 13.1. Normative References . . . . . . . . . . . . . . . . . . 94
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 101 13.2. Informative References . . . . . . . . . . . . . . . . . 98
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 101 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 102
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 101 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 102
Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 102 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 102
C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 102 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 102
Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 103
C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 103
C.1.1. Manufacturer Certificate Authority for IDevID C.1.1. Manufacturer Certificate Authority for IDevID
signatures . . . . . . . . . . . . . . . . . . . . . 102 signatures . . . . . . . . . . . . . . . . . . . . . 104
C.1.2. MASA key pair for voucher signatures . . . . . . . . 104 C.1.2. MASA key pair for voucher signatures . . . . . . . . 105
C.1.3. Registrar Certificate Authority . . . . . . . . . . . 106 C.1.3. Registrar Certificate Authority . . . . . . . . . . . 107
C.1.4. Registrar key pair . . . . . . . . . . . . . . . . . 107 C.1.4. Registrar key pair . . . . . . . . . . . . . . . . . 108
C.1.5. Pledge key pair . . . . . . . . . . . . . . . . . . . 109 C.1.5. Pledge key pair . . . . . . . . . . . . . . . . . . . 110
C.2. Example process . . . . . . . . . . . . . . . . . . . . . 110 C.2. Example process . . . . . . . . . . . . . . . . . . . . . 111
C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 110 C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 111
C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 114 C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 115
C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 120 C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 121
Appendix D. Additional References . . . . . . . . . . . . . . . 124 Appendix D. Additional References . . . . . . . . . . . . . . . 125
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125
1. Introduction 1. Introduction
The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
provides a solution for secure zero-touch (automated) bootstrap of provides a solution for secure zero-touch (automated) bootstrap of
new (unconfigured) devices that are called pledges in this document. new (unconfigured) devices that are called pledges in this document.
Pledges have an IDevID installed in them at the factory. Pledges have an IDevID installed in them at the factory.
"BRSKI" is pronounced like "brewski", a colloquial term for beer in "BRSKI" is pronounced like "brewski", a colloquial term for beer in
Canada and parts of the US-midwest. [brewski] Canada and parts of the US-midwest. [brewski]
skipping to change at page 18, line 21 skipping to change at page 18, line 21
This is consistent with [RFC5280] section 4.2.1.3, which does not This is consistent with [RFC5280] section 4.2.1.3, which does not
require key usage restrictions for end entity certificates. require key usage restrictions for end entity certificates.
2.3.1. Identification of the Pledge 2.3.1. Identification of the Pledge
In the context of BRSKI, pledges have a 1:1 relationship with a In the context of BRSKI, pledges have a 1:1 relationship with a
"serial-number". This serial-number is used both in the "serial- "serial-number". This serial-number is used both in the "serial-
number" field of voucher or voucher-requests (see Section 3) and in number" field of voucher or voucher-requests (see Section 3) and in
local policies on registrar or MASA (see Section 5). local policies on registrar or MASA (see Section 5).
The serialNumber field is defined in [RFC5280]. That specification There is a (certificate) serialNumber field is defined in [RFC5280]
allows for the field to be omitted if there is a good technical section 4.1.2.2. In the ASN.1, this is referred to as the
reason. IDevID certificates for use with this protocol are REQUIRED CertificateSerialNumber. This field is NOT relevant to this
to include the "serialNumber" attribute with the device's unique specification. Do not confuse this field with the "serial-number"
serial number (from [IDevID] section 7.2.8, and [RFC5280] section defined by this document, or by [IDevID] and [RFC4519] section 2.31.
4.1.2.2's list of standard attributes).
The serialNumber field is used as follows by the pledge to build the The device serial number is defined in [RFC5280] section A.1 and A.2
"serial-number" that is placed in the voucher-request. In order to as the X520SerialNumber, with the OID tag id-at-serialNumber.
build it, the fields need to be converted into a serial-number of
"type string". The device serial number field (X520SerialNumber) is used as follows
by the pledge to build the "serial-number" that is placed in the
voucher-request. In order to build it, the fields need to be
converted into a serial-number of "type string".
An example of a printable form of the "serialNumber" field is An example of a printable form of the "serialNumber" field is
provided in [RFC4519] section 2.31 ("WI-3005"). That section further provided in [RFC4519] section 2.31 ("WI-3005"). That section further
provides equality and syntax attributes. provides equality and syntax attributes.
Due to the reality of existing device identity provisioning Due to the reality of existing device identity provisioning
processes, some manufacturers have stored serial-numbers in other processes, some manufacturers have stored serial-numbers in other
fields. Registrar's SHOULD be configurable, on a per-manufacturer fields. Registrar's SHOULD be configurable, on a per-manufacturer
basis, to look for serial-number equivalents in other fields. basis, to look for serial-number equivalents in other fields.
skipping to change at page 19, line 13 skipping to change at page 19, line 20
Section 7.4 of [RFC5280]. Section 7.4 of [RFC5280].
The URI provides the authority information. The BRSKI "/.well-known" The URI provides the authority information. The BRSKI "/.well-known"
tree ([RFC5785]) is described in Section 5. tree ([RFC5785]) is described in Section 5.
A complete URI MAY be in this extension, including the 'scheme', A complete URI MAY be in this extension, including the 'scheme',
'authority', and 'path', The complete URI will typically be used in 'authority', and 'path', The complete URI will typically be used in
diagnostic or experimental situations. Typically, (and in diagnostic or experimental situations. Typically, (and in
consideration to constrained systems), this SHOULD be reduced to only consideration to constrained systems), this SHOULD be reduced to only
the 'authority', in which case a scheme of "https://" ([RFC7230] the 'authority', in which case a scheme of "https://" ([RFC7230]
section 2.7.3) and 'path' of "/.well-known/est" is to be assumed. section 2.7.3) and 'path' of "/.well-known/brski" is to be assumed.
The registrar can assume that only the 'authority' is present in the The registrar can assume that only the 'authority' is present in the
extension, if there are no slash ("/") characters in the extension. extension, if there are no slash ("/") characters in the extension.
Section 7.4 of [RFC5280] calls out various schemes that MUST be Section 7.4 of [RFC5280] calls out various schemes that MUST be
supported, including LDAP, HTTP and FTP. However, the registrar MUST supported, including LDAP, HTTP and FTP. However, the registrar MUST
use HTTPS for the BRSKI-MASA connection. use HTTPS for the BRSKI-MASA connection.
The new extension is identified as follows: The new extension is identified as follows:
skipping to change at page 27, line 28 skipping to change at page 27, line 28
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 voucher-request builds upon the voucher-request document. The voucher-request builds upon the
voucher artifact described in [RFC8366]. The tree diagram is voucher artifact described in [RFC8366]. The tree diagram is
described in [RFC8340]. Each node in the diagram is fully described described in [RFC8340]. Each node in the diagram is fully described
by the YANG module in Section 3.4. Please review the YANG module for by the YANG module in Section 3.4. 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
Figure 5: YANG Tree diagram for Voucher-Request Figure 5: YANG Tree diagram for Voucher-Request
3.3. Examples 3.3. Examples
This section provides voucher-request examples for illustration This section provides voucher-request examples for illustration
purposes. These examples show the JSON prior to CMS wrapping. JSON purposes. These examples show the JSON prior to CMS wrapping. JSON
encoding rules specify that any binary content be base64 encoded encoding rules specify that any binary content be base64 encoded
([RFC4648] section 4). The contents of the (base64) encoded ([RFC4648] section 4). The contents of the (base64) encoded
certificates have been elided to save space. For detailed examples, certificates have been elided to save space. For detailed examples,
skipping to change at page 31, line 19 skipping to change at page 31, line 19
description description
"Grouping to allow reuse/extensions in future work."; "Grouping to allow reuse/extensions in future work.";
uses vch:voucher-artifact-grouping { uses vch:voucher-artifact-grouping {
refine "voucher/created-on" { refine "voucher/created-on" {
mandatory false; mandatory false;
} }
refine "voucher/pinned-domain-cert" { refine "voucher/pinned-domain-cert" {
mandatory false; mandatory false;
description "A pinned-domain-cert field
is not valid in a voucher request, and
any occurrence MUST be ignored";
}
refine "voucher/last-renewal-date" {
description "A last-renewal-date field
is not valid in a voucher request, and
any occurrence MUST be ignored";
} }
refine "voucher/domain-cert-revocation-checks" { refine "voucher/domain-cert-revocation-checks" {
description "The domain-cert-revocation-checks field description "The domain-cert-revocation-checks field
is not valid in a voucher request, and is not valid in a voucher request, and
any occurence MUST be ignored"; any occurrence MUST be ignored";
} }
refine "voucher/assertion" { refine "voucher/assertion" {
mandatory false; mandatory false;
description "Any assertion included in registrar voucher description "Any assertion included in registrar voucher
requests SHOULD be ignored by the MASA."; requests SHOULD be ignored by the MASA.";
} }
augment "voucher" { augment "voucher" {
description description
skipping to change at page 36, line 33 skipping to change at page 36, line 33
; IANA protocol registry, as per ; IANA protocol registry, as per
; [GRASP] section 2.9.5.1, note 3. ; [GRASP] section 2.9.5.1, note 3.
port-number = selected by Proxy port-number = selected by Proxy
<CODE ENDS> <CODE ENDS>
Figure 10: CDDL definition of Proxy Discovery message Figure 10: CDDL definition of Proxy Discovery message
Here is an example M_FLOOD announcing a proxy at fe80::1, on TCP port Here is an example M_FLOOD announcing a proxy at fe80::1, on TCP port
4443. 4443.
[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 11: Example of Proxy Discovery message Figure 11: Example of Proxy Discovery message
On a small network the Registrar MAY include the GRASP M_FLOOD On a small network the Registrar MAY include the GRASP M_FLOOD
announcements to locally connected networks. announcements to locally connected networks.
The $transport-proto above indicates the method that the pledge- The $transport-proto above indicates the method that the pledge-
proxy-registrar will use. The TCP method described here is proxy-registrar will use. The TCP method described here is
mandatory, and other proxy methods, such as CoAP methods not defined mandatory, and other proxy methods, such as CoAP methods not defined
in this document are optional. Other methods MUST NOT be enabled in this document are optional. Other methods MUST NOT be enabled
unless the Join Registrar ASA indicates support for them in it's own unless the Join Registrar ASA indicates support for them in it's own
announcement. announcement.
skipping to change at page 37, line 23 skipping to change at page 37, line 23
The registrar SHOULD announce itself so that proxies can find it and The registrar SHOULD announce itself so that proxies can find it and
determine what kind of connections can be terminated. determine what kind of connections can be terminated.
The registrar announces itself using ACP instance of GRASP using The registrar announces itself using ACP instance of GRASP using
M_FLOOD messages. A registrar may announce any convenient port M_FLOOD messages. A registrar may announce any convenient port
number, including using a stock port 443. ANI proxies MUST support number, including using a stock port 443. ANI proxies MUST support
GRASP discovery of registrars. GRASP discovery of registrars.
The M_FLOOD is formatted as follows: The M_FLOOD is formatted as follows:
[M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000, [M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
[["AN_join_registrar", 4, 255, "EST-TLS"], [["AN_join_registrar", 4, 255, "EST-TLS"],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]] h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]]
Figure 12: An example of a Registrar announcement message Figure 12: An example of a Registrar announcement message
The formal CDDL definition is: The formal CDDL definition is:
<CODE BEGINS> file "jrcgrasp.cddl" <CODE BEGINS> file "jrcgrasp.cddl"
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_join_registrar", objective-flags, loop-count, objective = ["AN_join_registrar", objective-flags, loop-count,
objective-value] objective-value]
skipping to change at page 38, line 45 skipping to change at page 38, line 45
5. Protocol Details (Pledge - Registrar - MASA) 5. Protocol Details (Pledge - Registrar - MASA)
The pledge MUST initiate BRSKI after boot if it is unconfigured. The The pledge MUST initiate BRSKI after boot if it is unconfigured. The
pledge MUST NOT automatically initiate BRSKI if it has been pledge MUST NOT automatically initiate BRSKI if it has been
configured or is in the process of being configured. configured or is in the process of being configured.
BRSKI is described as extensions to EST [RFC7030]. The goal of these BRSKI is described as extensions to EST [RFC7030]. The goal of these
extensions is to reduce the number of TLS connections and crypto extensions is to reduce the number of TLS connections and crypto
operations required on the pledge. The registrar implements the operations required on the pledge. The registrar implements the
BRSKI REST interface within the same "/.well-known" URI tree as the BRSKI REST interface within the "/.well-known/brski" URI tree, as
existing EST URIs as described in EST [RFC7030] section 3.2.2. The well as implementing the existing EST URIs as described in EST
communication channel between the pledge and the registrar is [RFC7030] section 3.2.2. The communication channel between the
referred to as "BRSKI-EST" (see Figure 1). pledge and the registrar is referred to as "BRSKI-EST" (see
The communication channel between the registrar and MASA is similarly
described as extensions to EST within the same "/.well-known" tree.
For clarity this channel is referred to as "BRSKI-MASA". (See
Figure 1). Figure 1).
The MASA URI is "https://" authority "/.well-known/est". The communication channel between the registrar and MASA is a new
communication channel, similar to EST, within the newly registred
"/.well-known/brski" tree. For clarity this channel is referred to
as "BRSKI-MASA". (See Figure 1).
The MASA URI is "https://" authority "/.well-known/brski".
BRSKI uses existing CMS message formats for existing EST operations. BRSKI uses existing CMS message formats for existing EST operations.
BRSKI uses JSON [RFC8259] for all new operations defined here, and BRSKI uses JSON [RFC8259] for all new operations defined here, and
voucher formats. In all places where a binary value must be carried voucher formats. In all places where a binary value must be carried
in a JSON string, the use of base64 format ([RFC4648] section 4) is in a JSON string, the use of base64 format ([RFC4648] section 4) is
to be used, as per [RFC7951] section 6.6. to be used, as per [RFC7951] section 6.6.
While EST section 3.2 does not insist upon use of HTTP persistent While EST section 3.2 does not insist upon use of HTTP persistent
connections ([RFC7230] section 6.3), BRSKI-EST connections SHOULD use connections ([RFC7230] section 6.3), BRSKI-EST connections SHOULD use
persistent connections. The intention of this guidance is to ensure persistent connections. The intention of this guidance is to ensure
skipping to change at page 41, line 40 skipping to change at page 41, line 40
proxy that has been communicated with least recently. If there were proxy that has been communicated with least recently. If there were
no other proxies discovered, the pledge MAY continue to wait, as long no other proxies discovered, the pledge MAY continue to wait, as long
as it is concurrently listening for new proxy announcements. as it is concurrently listening for new proxy announcements.
5.2. Pledge Requests Voucher from the Registrar 5.2. Pledge Requests Voucher from the Registrar
When the pledge bootstraps it makes a request for a voucher from a When the pledge bootstraps it makes a request for a voucher from a
registrar. registrar.
This is done with an HTTPS POST using the operation path value of This is done with an HTTPS POST using the operation path value of
"/.well-known/est/requestvoucher". "/.well-known/brski/requestvoucher".
The pledge voucher-request Content-Type is: The pledge voucher-request Content-Type is:
application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON
document that has been signed using a CMS structure", and the document that has been signed using a CMS structure", and the
voucher-request described in Section 3 is created in the same way. voucher-request described in Section 3 is created in the same way.
The media type is the same as defined in [RFC8366]. This is also The media type is the same as defined in [RFC8366]. This is also
used for the pledge voucher-request. The pledge MUST sign the used for the pledge voucher-request. The pledge MUST sign the
request using the Section 2.3 credential. request using the Section 2.3 credential.
skipping to change at page 45, line 22 skipping to change at page 45, line 22
ACP applicability, there is a significant difference between supply ACP applicability, there is a significant difference between supply
chain logistics for $100 CPE devices and $100,000 core routers. chain logistics for $100 CPE devices and $100,000 core routers.
5.5. 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 a registrar voucher-request to the MASA service via an HTTPS
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/brski/requestvoucher".
The voucher media type "application/voucher-cms+json" is defined in The voucher media type "application/voucher-cms+json" is defined in
[RFC8366] and is also used for the registrar voucher-request. It is [RFC8366] and is also used for the registrar voucher-request. It is
a JSON document that has been signed using a CMS structure. The a JSON document that has been signed using a CMS structure. The
registrar MUST sign the registrar voucher-request. registrar MUST sign the registrar voucher-request.
MASA implementations SHOULD anticipate future media ntypes but of MASA implementations SHOULD anticipate future media ntypes but of
course will simply fail the request if those types are not yet known. course will simply fail the request if those types are not yet known.
The voucher-request CMS object includes some number of certificates The voucher-request CMS object includes some number of certificates
skipping to change at page 55, line 24 skipping to change at page 55, line 24
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.
The pledge MUST indicate its pledge status regarding the voucher. It The pledge MUST indicate its pledge status regarding the voucher. It
does this by sending a status message to the Registrar. does this by sending a status message to the Registrar.
The posted data media type: application/json The posted data media type: application/json
The client sends an HTTP POST to the server at the URI ".well- The client sends an HTTP POST to the server at the URI ".well-
known/est/voucher_status". known/brski/voucher_status".
The format and semantics described below are for version 1. A The format and semantics described below are for version 1. A
version field is included to permit significant changes to this version field is included to permit significant changes to this
feedback in the future. A Registrar that receives a status message feedback in the future. A Registrar that receives a status message
with a version larger than it knows about SHOULD log the contents and with a version larger than it knows about SHOULD log the contents and
alert a human. alert a human.
The Status field indicates if the voucher was acceptable. Boolean The Status field indicates if the voucher was acceptable. Boolean
values are acceptable, where "true" indicates the voucher was values are acceptable, where "true" indicates the voucher was
acceptable. acceptable.
skipping to change at page 55, line 51 skipping to change at page 56, line 7
the operational costs of not recording that an voucher was ignored by the operational costs of not recording that an voucher was ignored by
a client the registrar expected to continue joining the domain. a client the registrar expected to continue joining the domain.
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.
The version and status fields MUST be present. The Reason field The version and status fields MUST be present. The Reason field
SHOULD be present whenever the status field is false. The Reason- SHOULD be present whenever the status field is false. The Reason-
Context field is optional. Context field is optional. In the case of a SUCCESS the Reason
string MAY be omitted.
The keys to this JSON object are case-sensitive and MUST be The keys to this JSON object are case-sensitive and MUST be
lowercase. Figure 15 shows an example JSON. lowercase. Figure 16 shows an example JSON.
<CODE BEGINS> file "voucherstatus.cddl"
voucherstatus-post = {
"version": uint,
"status": bool,
? "reason": text,
? "reason-context" : { $$arbitrary-map }
}
}
<CODE ENDS>
Figure 15: CDDL for voucher status POST
{ {
"version":"1", "version": 1,
"status":false, "status":false,
"reason":"Informative human readable message", "reason":"Informative human readable message",
"reason-context": { "additional" : "JSON" } "reason-context": { "additional" : "JSON" }
} }
Figure 15: Example Status Telemetry Figure 16: Example Status Telemetry
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.
Additional standard JSON fields in this POST MAY be added, see Additional standard JSON fields in this POST MAY be added, see
Section 8.5. A server that sees unknown fields should log them, but Section 8.5. A server that sees unknown fields should log them, but
otherwise ignore them. otherwise ignore them.
5.8. Registrar audit-log request 5.8. Registrar audit-log request
After receiving the pledge status telemetry Section 5.7, the After receiving the pledge status telemetry Section 5.7, the
registrar SHOULD request the MASA audit-log from the MASA service. registrar SHOULD request the MASA audit-log from the MASA service.
This is done with an HTTP POST using the operation path value of This is done with an HTTP POST using the operation path value of
"/.well-known/est/requestauditlog". "/.well-known/brski/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 (using the same Content-Type). It it did when requesting a voucher (using the same Content-Type). It
is posted to the /requestauditlog URI instead. The "idevid-issuer" is posted to the /requestauditlog URI instead. The "idevid-issuer"
and "serial-number" informs the MASA which log is requested so the and "serial-number" informs the MASA which log is requested so the
appropriate log can be prepared for the response. Using the same appropriate log can be prepared for the response. Using the same
media type and message minimizes cryptographic and message operations media type and message minimizes cryptographic and message operations
although it results in additional network traffic. The relying MASA although it results in additional network traffic. The relying MASA
implementation MAY leverage internal state to associate this request implementation MAY leverage internal state to associate this request
with the original, and by now already validated, voucher-request so with the original, and by now already validated, voucher-request so
skipping to change at page 58, line 25 skipping to change at page 58, line 36
event = { event = {
"date": text, "date": text,
"domainID": text, "domainID": text,
"nonce": text / null, "nonce": text / null,
"assertion": "verified" / "logged" / "proximity", "assertion": "verified" / "logged" / "proximity",
? "truncated": uint, ? "truncated": uint,
} }
<CODE ENDS> <CODE ENDS>
Figure 16: CDDL for audit-log response Figure 17: CDDL for audit-log response
An example: An example:
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"2019-05-15T17:25:55.644-04:00", "date":"2019-05-15T17:25:55.644-04:00",
"domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=",
"nonce":"VOUFT-WwrEv0NuAQEHoV7Q", "nonce":"VOUFT-WwrEv0NuAQEHoV7Q",
skipping to change at page 59, line 4 skipping to change at page 59, line 28
"nonce":"f4G6Vi1t8nKo/FieCVgpBg==", "nonce":"f4G6Vi1t8nKo/FieCVgpBg==",
"assertion":"proximity" "assertion":"proximity"
} }
], ],
"truncation": { "truncation": {
"nonced duplicates": "0", "nonced duplicates": "0",
"nonceless duplicates": "1", "nonceless duplicates": "1",
"arbitrary": "2" "arbitrary": "2"
} }
} }
Figure 17: Example of audit-log response
Figure 18: Example of audit-log response
The domainID is a binary SubjectKeyIdentifier value calculated The domainID is a binary SubjectKeyIdentifier value calculated
according to Section 5.8.2. It is encoded once in base64 in order to according to Section 5.8.2. It is encoded once in base64 in order to
be transported in this JSON container. be transported in this JSON container.
The date is in [RFC3339] format, which is consistent with typical The date is in [RFC3339] format, which is consistent with typical
JavaScript usage of JSON. JavaScript usage of JSON.
The truncation structure MAY be omitted if all values are zero. Any The truncation structure MAY be omitted if all values are zero. Any
counter missing from the truncation structure is the be assumed to be counter missing from the truncation structure is the be assumed to be
skipping to change at page 63, line 48 skipping to change at page 64, line 31
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. The MASA provides logs and status of credential by the client. The 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.
The client MUST send an indicator to the Registrar about its The client MUST send an indicator to the Registrar about its
enrollment status. It does this by using an HTTP POST of a JSON enrollment status. It does this by using an HTTP POST of a JSON
dictionary with the of attributes described below to the new EST dictionary with the of attributes described below to the new EST
endpoint at "/.well-known/est/enrollstatus". endpoint at "/.well-known/brski/enrollstatus". (XXX ?)
When indicating a successful enrollment the client SHOULD first re- When indicating a successful enrollment the client SHOULD first re-
establish the EST TLS session using the newly obtained credentials. establish the EST TLS session using the newly obtained credentials.
TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The
client SHOULD therefore always close the existing TLS connection, and client SHOULD therefore always close the existing TLS connection, and
start a new one. start a new one.
In the case of a failed enrollment, the client MUST send the In the case of a failed enrollment, the client MUST send the
telemetry information over the same TLS connection that was used for telemetry information over the same TLS connection that was used for
the enrollment attempt, with a Reason string indicating why the most the enrollment attempt, with a Reason string indicating why the most
recent enrollment failed. (For failed attempts, the TLS connection recent enrollment failed. (For failed attempts, the TLS connection
is the most reliable way to correlate server-side information with is the most reliable way to correlate server-side information with
what the client provides.) what the client provides.)
The version and status fields MUST be present. The Reason field
SHOULD be present whenever the status field is false. In the case of
a SUCCESS the Reason string MAY be omitted.
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 the failure to unroll from this pledge. The contents of specific to the failure to unroll from this pledge. The contents of
this field are not subject to standardization. This is represented this field are not subject to standardization. This is represented
by the group-socket "$$arbitrary-map" in the CDDL. by the group-socket "$$arbitrary-map" in the CDDL.
In the case of a SUCCESS the Reason string is omitted. In the case of a SUCCESS the Reason string is omitted.
<CODE BEGINS> file "enrollstatus.cddl" <CODE BEGINS> file "enrollstatus.cddl"
enrollstatus-post = { enrollstatus-post = {
"version": uint, "version": uint,
"status": bool, "status": bool,
"reason": text, ? "reason": text,
? "reason-context" : { $$arbitrary-map } ? "reason-context" : { $$arbitrary-map }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 18: CDDL for enrollment status POST Figure 19: CDDL for enrollment status POST
An example status report can be seen below. It is sent with with the An example status report can be seen below. It is sent with with the
media type: application/json media type: application/json
{ {
"version":"1", "version": 1,
"status":true, "status":true,
"reason":"Informative human readable message", "reason":"Informative human readable message",
"reason-context": { "additional" : "JSON" } "reason-context": { "additional" : "JSON" }
} }
Figure 19: Example of enrollment status POST Figure 20: Example of enrollment status POST
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.
5.9.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
skipping to change at page 65, line 32 skipping to change at page 66, line 24
mappings for BRSKI will be discussed either there or in future work. mappings for BRSKI will be discussed either there or in future work.
6. Clarification of transfer-encoding 6. Clarification of transfer-encoding
[RFC7030] defines its endpoints to include a "Content-Transfer- [RFC7030] defines its endpoints to include a "Content-Transfer-
Encoding" heading, and the payloads to be [RFC4648] Base64 encoded Encoding" heading, and the payloads to be [RFC4648] Base64 encoded
DER. DER.
When used within BRSKI, the original RFC7030 EST endpoints remain When used within BRSKI, the original RFC7030 EST endpoints remain
Base64 encoded, but the new BRSKI end points which send and receive Base64 encoded, but the new BRSKI end points which send and receive
binary artifacts (specifically, "/.well-known/est/requestvoucher") binary artifacts (specifically, "/.well-known/brski/requestvoucher")
are binary. That is, no encoding is used. are binary. That is, no encoding is used.
In the BRSKI context, the EST "Content-Transfer-Encoding" header In the BRSKI context, the EST "Content-Transfer-Encoding" header
field if present, SHOULD be ignored. This header field does not need field if present, SHOULD be ignored. This header field does not need
to be included. to be included.
7. Reduced security operational modes 7. Reduced security operational modes
A common requirement of bootstrapping is to support less secure A common requirement of bootstrapping is to support less secure
operational modes for support specific use cases. This section operational modes for support specific use cases. This section
skipping to change at page 72, line 10 skipping to change at page 72, line 42
8.2. YANG Module Names Registry 8.2. YANG Module Names Registry
This document registers a YANG module in the "YANG Module Names" This document registers a YANG module in the "YANG Module Names"
registry [RFC6020]. IANA is asked to register the following: registry [RFC6020]. IANA is asked to register the following:
name: ietf-voucher-request name: ietf-voucher-request
namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request
prefix: vch prefix: vch
reference: THIS DOCUMENT reference: THIS DOCUMENT
8.3. Well-known EST registration 8.3. BRSKI well-known considerations
This document extends the definitions of "est" (so far defined via 8.3.1. BRSKI .well-known registration
RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
well-known-uris.xhtml" registry. IANA is asked to change the To the Well-Known URIs Registry, at:
registration of "est" to include RFC7030 and this document. "https://www.iana.org/assignments/well-known-uris/well-known-
uris.xhtml", this document registers the well-known name "brski" with
the following filled-in template from [RFC5785]:
URI suffix: brski
Change Controller: IETF
IANA is asked to change the registration of "est" to now only include
RFC7030 and no longer this document. Earlier versions of this
document used "/.well-known/est" rather than "/.well-known/brski".
8.3.2. BRSKI .well-known registry
IANA is requested to create a new Registry entitled: "BRSKI well-
known URIs". The registry shall have at least three columns: URI,
description, and reference. New items can be added using the
Specification Required process. The initial contents of this
registry shall be:
URI document description
requestvoucher [THISRFC] pledge to registrar, and from registrar to MASA
voucher_status [THISRFC] pledge to registrar
requestauditlog [THISRFC] registrar to MASA
enrollstatus [THISRFC] pledge to registrar
8.4. PKIX Registry 8.4. PKIX Registry
IANA is requested to register the following: IANA is requested to register the following:
This document requests a number for id-mod-MASAURLExtn2016(TBD) from This document requests a number for id-mod-MASAURLExtn2016(TBD) from
the pkix(7) id-mod(0) Registry. the pkix(7) id-mod(0) Registry.
This document has received an early allocation from the id-pe This document has received an early allocation from the id-pe
registry (SMI Security for PKIX Certificate Extension) for id-pe- registry (SMI Security for PKIX Certificate Extension) for id-pe-
masa-url with the value 32, resulting in an OID of masa-url with the value 32, resulting in an OID of
1.3.6.1.5.5.7.1.32. 1.3.6.1.5.5.7.1.32.
8.5. Pledge BRSKI Status Telemetry 8.5. Pledge BRSKI Status Telemetry
IANA is requested to create a new Registry entitled: "BRSKI IANA is requested to create a new Registry entitled: "BRSKI
Parameters", and within that Registry to create a table called: Parameters", and within that Registry to create a table called:
"Pledge BRSKI Status Telemetry Attributes". New items can be added "Pledge BRSKI Status Telemetry Attributes". New items can be added
using the Specification Required. The following items are to be in using the Specification Required process. The following items are to
the initial registration, with this document (Section 5.7) as the be in the initial registration, with this document (Section 5.7) as
reference: the reference:
* version * version
* Status * Status
* Reason * Reason
* reason-context * reason-context
8.6. DNS Service Names 8.6. DNS Service Names
skipping to change at page 93, line 38 skipping to change at page 94, line 46
members, including Adam Roach, Alexey Melnikov, Alissa Cooper, members, including Adam Roach, Alexey Melnikov, Alissa Cooper,
Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund. Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", Work in Progress, Internet-Draft, Control Plane (ACP)", Work in Progress, Internet-Draft,
draft-ietf-anima-autonomic-control-plane-28, 28 July 2020, draft-ietf-anima-autonomic-control-plane-29, 11 September
<http://www.ietf.org/internet-drafts/draft-ietf-anima- 2020, <http://www.ietf.org/internet-drafts/draft-ietf-
autonomic-control-plane-28.txt>. anima-autonomic-control-plane-29.txt>.
[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)", Work in Progress, Autonomic Signaling Protocol (GRASP)", Work in Progress,
Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017,
<http://www.ietf.org/internet-drafts/draft-ietf-anima- <http://www.ietf.org/internet-drafts/draft-ietf-anima-
grasp-15.txt>. grasp-15.txt>.
[IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009,
<http://standards.ieee.org/findstds/standard/802.1AR- <http://standards.ieee.org/findstds/standard/802.1AR-
skipping to change at page 98, line 29 skipping to change at page 99, line 40
[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", Work in Progress, Internet-Draft, draft-ietf- Networking", Work in Progress, Internet-Draft, draft-ietf-
anima-reference-model-10, 22 November 2018, anima-reference-model-10, 22 November 2018,
<http://www.ietf.org/internet-drafts/draft-ietf-anima- <http://www.ietf.org/internet-drafts/draft-ietf-anima-
reference-model-10.txt>. reference-model-10.txt>.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "A YANG Data Model for a Keystore", Work in Watsen, K., "A YANG Data Model for a Keystore", Work in
Progress, Internet-Draft, draft-ietf-netconf-keystore-19, Progress, Internet-Draft, draft-ietf-netconf-keystore-20,
10 July 2020, <http://www.ietf.org/internet-drafts/draft- 20 August 2020, <http://www.ietf.org/internet-drafts/
ietf-netconf-keystore-19.txt>. draft-ietf-netconf-keystore-20.txt>.
[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", Work in Progress, join router in ANIMA bootstrap", Work in Progress,
Internet-Draft, draft-richardson-anima-state-for- Internet-Draft, draft-richardson-anima-state-for-
joinrouter-02, 25 January 2018, <http://www.ietf.org/ joinrouter-02, 25 January 2018, <http://www.ietf.org/
internet-drafts/draft-richardson-anima-state-for- internet-drafts/draft-richardson-anima-state-for-
joinrouter-02.txt>. joinrouter-02.txt>.
[imprinting] [imprinting]
skipping to change at page 100, line 46 skipping to change at page 102, line 9
duckling.pdf>. duckling.pdf>.
[TR069] "TR-69: CPE WAN Management Protocol", February 2018, [TR069] "TR-69: CPE WAN Management Protocol", February 2018,
<https://www.broadband-forum.org/standards-and-software/ <https://www.broadband-forum.org/standards-and-software/
technical-specifications/tr-069-files-tools>. technical-specifications/tr-069-files-tools>.
[W3C.WD-capability-urls-20140218] [W3C.WD-capability-urls-20140218]
Tennison, J., "Good Practices for Capability URLs", World Tennison, J., "Good Practices for Capability URLs", World
Wide Web Consortium WD WD-capability-urls-20140218, 18 Wide Web Consortium WD WD-capability-urls-20140218, 18
February 2014, February 2014,
<http://www.w3.org/TR/2014/WD-capability-urls-20140218>. <https://www.w3.org/TR/2014/WD-capability-urls-20140218>.
Appendix A. IPv4 and non-ANI operations Appendix A. IPv4 and non-ANI operations
The specification of BRSKI in Section 4 intentionally only covers the The specification 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
 End of changes. 47 change blocks. 
141 lines changed or deleted 196 lines changed or added

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