draft-ietf-anima-bootstrapping-keyinfra-19.txt   draft-ietf-anima-bootstrapping-keyinfra-20.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: September 8, 2019 Sandelman Expires: November 12, 2019 Sandelman
M. Behringer M. Behringer
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
K. Watsen K. Watsen
Juniper Networks Juniper Networks
March 7, 2019 May 11, 2019
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-19 draft-ietf-anima-bootstrapping-keyinfra-20
Abstract Abstract
This document specifies automated bootstrapping of an Autonomic This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a remote secure key infrastructure (BRSKI) Control Plane. To do this a remote secure key infrastructure (BRSKI)
is created using manufacturer installed X.509 certificate, in is created using manufacturer installed X.509 certificate, in
combination with a manufacturer's authorizing service, both online combination with a manufacturer's authorizing service, both online
and offline. Bootstrapping a new device can occur using a routable and offline. Bootstrapping a new device can occur using a routable
address and a cloud service, or using only link-local connectivity, address and a cloud service, or using only link-local connectivity,
or on limited/disconnected networks. Support for lower security or on limited/disconnected networks. Support for lower security
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 September 8, 2019. This Internet-Draft will expire on November 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 6 skipping to change at page 3, line 6
2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 21 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 21
2.6. Certificate Time Validation . . . . . . . . . . . . . . . 22 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 22
2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 22 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 22
2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 22 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 22
2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 22 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 22
2.8. Determining the MASA to contact . . . . . . . . . . . . . 23 2.8. Determining the MASA to contact . . . . . . . . . . . . . 23
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 23 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 23
3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 24 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 24
3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 24 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 24
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 26
4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 30 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 29
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 31 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 30
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 and communication of Registrar . . . . . 33 4.3. Proxy discovery and communication of Registrar . . . . . 33
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 35 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 34
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 37 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 36
5.3. Registrar Authorization of 5.3. Registrar Authorization of
Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 38 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 39 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 38
5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 39 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 39
5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 41 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 40
5.5.2. MASA verification of voucher-request signature 5.5.2. MASA verification of voucher-request signature
consistency . . . . . . . . . . . . . . . . . . . . . 41 consistency . . . . . . . . . . . . . . . . . . . . . 41
5.5.3. MASA authentication of registrar (certificate) . . . 41 5.5.3. MASA authentication of registrar (certificate) . . . 41
5.5.4. MASA revocation checking of registrar (certificate) . 42 5.5.4. MASA revocation checking of registrar (certificate) . 41
5.5.5. MASA verification of pledge prior-signed-voucher- 5.5.5. MASA verification of pledge prior-signed-voucher-
request . . . . . . . . . . . . . . . . . . . . . . . 42 request . . . . . . . . . . . . . . . . . . . . . . . 41
5.5.6. MASA pinning of registrar . . . . . . . . . . . . . . 42 5.5.6. MASA pinning of registrar . . . . . . . . . . . . . . 42
5.5.7. MASA nonce handling . . . . . . . . . . . . . . . . . 42 5.5.7. MASA nonce handling . . . . . . . . . . . . . . . . . 42
5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 43 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 42
5.6.1. Pledge voucher verification . . . . . . . . . . . . . 45 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 45
5.6.2. Pledge authentication of provisional TLS connection . 46 5.6.2. Pledge authentication of provisional TLS connection . 45
5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 47 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 46
5.8. Registrar audit log request . . . . . . . . . . . . . . . 47 5.8. Registrar audit log request . . . . . . . . . . . . . . . 47
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 49 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 48
5.8.2. Registrar audit log verification . . . . . . . . . . 50 5.8.2. Registrar audit log verification . . . . . . . . . . 49
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 51 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 50
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 52 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 51
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 52 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51
5.9.3. EST Client Certificate Request . . . . . . . . . . . 53 5.9.3. EST Client Certificate Request . . . . . . . . . . . 52
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 53 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 54 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 53
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 54 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53
6. Reduced security operational modes . . . . . . . . . . . . . 54 6. Reduced security operational modes . . . . . . . . . . . . . 54
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 55 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 54
6.2. Pledge security reductions . . . . . . . . . . . . . . . 55 6.2. Pledge security reductions . . . . . . . . . . . . . . . 55
6.3. Registrar security reductions . . . . . . . . . . . . . . 56 6.3. Registrar security reductions . . . . . . . . . . . . . . 55
6.4. MASA security reductions . . . . . . . . . . . . . . . . 57 6.4. MASA security reductions . . . . . . . . . . . . . . . . 56
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
7.1. Well-known EST registration . . . . . . . . . . . . . . . 58 7.1. Well-known EST registration . . . . . . . . . . . . . . . 57
7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 58 7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 57
7.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 58 7.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 58
7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 59 7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 58
7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 59 7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 58
8. Applicability to the Autonomic 8. Applicability to the Autonomic
Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 59 Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 59
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60
9.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 60 9.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 60
9.2. What BRSKI-MASA reveals to the manufacturer . . . . . . . 61 9.2. What BRSKI-MASA reveals to the manufacturer . . . . . . . 60
9.3. Manufacturers and Used or Stolen Equipment . . . . . . . 63 9.3. Manufacturers and Used or Stolen Equipment . . . . . . . 62
9.4. Manufacturers and Grey market equipment . . . . . . . . . 64 9.4. Manufacturers and Grey market equipment . . . . . . . . . 63
9.5. Some mitigations for meddling by manufacturers . . . . . 64 9.5. Some mitigations for meddling by manufacturers . . . . . 64
10. Security Considerations . . . . . . . . . . . . . . . . . . . 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65
10.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 66 10.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 66
10.2. Freshness in Voucher-Requests . . . . . . . . . . . . . 67 10.2. Freshness in Voucher-Requests . . . . . . . . . . . . . 66
10.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 68 10.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 68
10.4. Manufacturer Maintainance of trust anchors . . . . . . . 69 10.4. Manufacturer Maintainance of trust anchors . . . . . . . 69
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
12.1. Normative References . . . . . . . . . . . . . . . . . . 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 70
12.2. Informative References . . . . . . . . . . . . . . . . . 73 12.2. Informative References . . . . . . . . . . . . . . . . . 72
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 76 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 76
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 76 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 76
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 77 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 76
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 77 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 76
Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 78 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 77
Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 80 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 79
D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 80 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 79
D.1.1. MASA key pair for voucher signatures . . . . . . . . 80 D.1.1. MASA key pair for voucher signatures . . . . . . . . 79
D.1.2. Manufacturer key pair for IDevID signatures . . . . . 80 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 79
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 81 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 80
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 83 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 82
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 85 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 83
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 85 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 83
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 91 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 89
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 96 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
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 new (unconfigured) devices that are called pledges in this of new (unconfigured) devices that are called pledges in this
document. document.
This document primarily provides for the needs of the ISP and This document primarily provides for the needs of the ISP and
Enterprise focused ANIMA Autonomic Control Plane (ACP) Enterprise focused ANIMA Autonomic Control Plane (ACP)
[I-D.ietf-anima-autonomic-control-plane]. Other users of the BRSKI [I-D.ietf-anima-autonomic-control-plane]. Other users of the BRSKI
skipping to change at page 17, line 34 skipping to change at page 17, line 34
1. [RFC4519] section 2.31 provides an example ("WI-3005") of the 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the
Distinguished Name "serialNumber" attribute. [RFC4514] indicates Distinguished Name "serialNumber" attribute. [RFC4514] indicates
this is a printable string so no encoding is necessary. this is a printable string so no encoding is necessary.
2. The HardwareModuleName hwSerialNum OCTET STRING. This value is 2. The HardwareModuleName hwSerialNum OCTET STRING. This value is
base64 encoded to convert it to a printable string format. base64 encoded to convert it to a printable string format.
The above process to locate the serial-number MUST be performed by The above process to locate the serial-number MUST be performed by
the pledge when filling out the voucher-request. Signed voucher- the pledge when filling out the voucher-request. Signed voucher-
requests are always passed up to the MASA, and the connection between requests are always passed up to the MASA.
the serial-number in the voucher-request and the serial number in the
IDevID certificate.
As explained in Section 5.5 the Registrar MUST extract the serial- As explained in Section 5.5 the Registrar MUST extract the serial-
number again itself from the pledge's TLS certificate. It may number again itself from the pledge's TLS certificate. It can
consult the serial-number in the pledge-request if there are any consult the serial-number in the pledge-request if there are any
possible confusion about the source of the serial-number (hwSerialNum possible confusion about the source of the serial-number (hwSerialNum
vs serialNumber). vs serialNumber).
2.3.2. MASA URI extension 2.3.2. MASA URI extension
This docucment defines a new PKIX non-critical certificate extension This docucment defines a new PKIX non-critical certificate extension
to carry the MASA URI. This extension is intended to be used in the to carry the MASA URI. This extension is intended to be used in the
IDevID certificate. The URI is represented as described in IDevID certificate. The URI is represented as described in
Section 7.4 of [RFC5280]. Section 7.4 of [RFC5280].
skipping to change at page 24, line 13 skipping to change at page 24, line 13
registrar. registrar.
The registrar in turn forms the "registrar voucher-request", and The registrar in turn forms the "registrar voucher-request", and
submits it to the MASA. submits it to the MASA.
The "proximity-registrar-cert" leaf is used in the pledge voucher- The "proximity-registrar-cert" leaf is used in the pledge voucher-
requests. This provides a method for the pledge to assert the requests. This provides a method for the pledge to assert the
registrar's proximity. registrar's proximity.
The "prior-signed-voucher-request" leaf is used in registrar voucher- The "prior-signed-voucher-request" leaf is used in registrar voucher-
requests. If present, it is the encoded (signed form) of the pledge requests. If present, it is the signed pledge voucher-request. This
voucher-request. This provides a method for the registrar to forward provides a method for the registrar to forward the pledge's signed
the pledge's signed request to the MASA. This completes transmission request to the MASA. This completes transmission of the signed
of the signed "proximity-registrar-cert" leaf. "proximity-registrar-cert" leaf.
Unless otherwise signaled (outside the voucher-request artifact), the Unless otherwise signaled (outside the voucher-request artifact), the
signing structure is as defined for vouchers, see [RFC8366]. signing structure is as defined for vouchers, see [RFC8366].
3.1. Nonceless Voucher Requests 3.1. Nonceless Voucher Requests
A registrar MAY also retrieve nonceless vouchers by sending nonceless A registrar MAY also retrieve nonceless vouchers by sending nonceless
voucher-requests to the MASA in order to obtain vouchers for use when voucher-requests to the MASA in order to obtain vouchers for use when
the registrar does not have connectivity to the MASA. No "prior- the registrar does not have connectivity to the MASA. No "prior-
signed-voucher-request" leaf would be included. The registrar will signed-voucher-request" leaf would be included. The registrar will
skipping to change at page 25, line 8 skipping to change at page 25, line 8
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
3.3. Examples 3.3. Examples
This section provides voucher-request examples for illustration This section provides voucher-request examples for illustration
purposes. For detailed examples, see Appendix D.2. These examples purposes. For detailed examples, see Appendix D.2. These examples
conform to the encoding rules defined in [RFC7951]. conform to the encoding rules defined in [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 25, line 44 skipping to change at page 25, line 44
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:00.000Z", "created-on": "2017-01-01T00:00:00.000Z",
"proximity-registrar-cert": "base64encodedvalue==" "proximity-registrar-cert": "base64encodedvalue=="
} }
} }
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 is a
signed artifact with a CMS format signature is a binary binary object. In the JSON encoding used here it must
object. In the JSON encoding used here it must be be base64 encoded. The nonce, created-on and assertion
base64 encoded. The nonce, created-on and assertion is 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.5. 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",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
"prior-signed-voucher-request": "base64encodedvalue==" "prior-signed-voucher-request": "base64encodedvalue=="
skipping to change at page 26, line 34 skipping to change at page 26, line 34
during deployment. See Section 5.5. 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",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
Example (4) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is not
populated with the pledge voucher-request because the
pledge did not sign its own request. This form might be
used when more constrained pledges are being deployed.
The nonce is populated from the pledge's request. See
Section 5.5.
{
"ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:02.000Z",
"idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789"
}
}
3.4. YANG Module 3.4. YANG Module
Following is a YANG [RFC7950] module formally extending the [RFC8366] Following is a YANG [RFC7950] module formally extending the [RFC8366]
voucher into a voucher-request. voucher into a voucher-request.
<CODE BEGINS> file "ietf-voucher-request@2018-02-14.yang" <CODE BEGINS> file "ietf-voucher-request@2018-02-14.yang"
module ietf-voucher-request { module ietf-voucher-request {
yang-version 1.1; yang-version 1.1;
namespace namespace
skipping to change at page 28, line 4 skipping to change at page 27, line 32
<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 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.
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
authors of the code. All rights reserved. authors of the code. All rights reserved.
skipping to change at page 33, line 5 skipping to change at page 32, line 21
[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 [I-D.ietf-cbor-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
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 1 ; one hop only loop-count = 1 ; one hop only
objective-value = any ; none objective-value = any ; none
locator-option = [ O_IPv6_LOCATOR, ipv6-address, locator-option = [ O_IPv6_LOCATOR, ipv6-address,
transport-proto, port-number ] transport-proto, port-number ]
ipv6-address = the v6 LL of the Proxy ipv6-address = the v6 LL of the Proxy
transport-proto /= IPPROTO_TCP ; note this can be any value from the $transport-proto /= IPPROTO_TCP ; note this can be any value from the
; 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
Figure 6c: AN_Proxy CDDL Figure 6c: AN_Proxy CDDL
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
skipping to change at page 34, line 37 skipping to change at page 34, line 6
; protocols: "EST-TLS" for RFC7030. ; protocols: "EST-TLS" for RFC7030.
Figure 7: AN_join_registrar CDDL Figure 7: AN_join_registrar CDDL
The M_FLOOD message MUST be sent periodically. The period is subject The M_FLOOD message MUST be sent periodically. The period is subject
to network administrator policy (EST server configuration). It must to network administrator policy (EST server configuration). It must
be sufficiently low that the aggregate amount of periodic M_FLOODs be sufficiently low that the aggregate amount of periodic M_FLOODs
from all EST servers causes negligible traffic across the ACP. from all EST servers causes negligible traffic across the ACP.
Here are some examples of locators for illustrative purposes. Only Here are some examples of locators for illustrative purposes. Only
the first one (transport-protocol = 6, TCP) is defined in this the first one ($transport-protocol = 6, TCP) is defined in this
document and is mandatory to implement. document and is mandatory to implement.
locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443]
locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
A protocol of 6 indicates that TCP proxying on the indicated port is A protocol of 6 indicates that TCP proxying on the indicated port is
desired. desired.
Registrars MUST announce the set of protocols that they support. Registrars MUST announce the set of protocols that they support.
skipping to change at page 37, line 31 skipping to change at page 36, line 50
proxy announcements. 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/est/requestvoucher".
The request media types are: The pledge voucher-request Content-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 encoding described in [RFC7951]. The in Section 3 using the JSON encoding described in [RFC7951]. This
pledge SHOULD sign the request using the Section 2.3 credential. voucher media type is defined in [RFC8366] and is also used for
the pledge voucher-request. The pledge SHOULD sign the request
using the Section 2.3 credential.
application/json The request is the "YANG-defined JSON document" as Registrar impementations SHOULD anticipate future media types but of
described in Section 3 with the exception that it is not within a course will simply fail the request if those types are not yet known.
CMS structure. It is protected only by the TLS client
authentication. This reduces the cryptographic requirements on
the pledge.
For simplicity the term 'voucher-request' is used to refer to either The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header
of these media types. Registrar impementations SHOULD anticipate indicating the acceptable media type for the voucher response. The
future media types but of course will simply fail the request if "application/voucher-cms+json" media type is defined in [RFC8366] but
those types are not yet known. constrained voucher formats are expected in the future. Registrar's
and MASA's are expected to be flexible in what they accept.
The pledge populates the voucher-request fields as follows: The pledge populates the voucher-request fields as follows:
created-on: Pledges that have a realtime clock are RECOMMENDED to created-on: Pledges that have a realtime clock are RECOMMENDED to
populate this field. This provides additional information to the populate this field. This provides additional information to the
MASA. MASA.
nonce: The pledge voucher-request MUST contain a cryptographically nonce: The pledge voucher-request MUST contain a cryptographically
strong random or pseudo-random number nonce. (see [RFC4086]) Doing strong random or pseudo-random number nonce. (see [RFC4086]) Doing
so ensures Section 2.6.1 functionality. The nonce MUST NOT be so ensures Section 2.6.1 functionality. The nonce MUST NOT be
skipping to change at page 38, line 27 skipping to change at page 37, line 45
(see [RFC5246]) presented by the registrar to the pledge. This (see [RFC5246]) presented by the registrar to the pledge. This
MUST be populated in a pledge voucher-request if the "proximity" MUST be populated in a pledge voucher-request if the "proximity"
assertion is populated. assertion is populated.
All other fields MAY be omitted in the 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.3 An example JSON payload of a pledge voucher-request is in Section 3.3
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. The registrar confirms that the 'proximity'
confirms that the associated 'proximity-registrar-cert' is correct. assertion and associated 'proximity-registrar-cert' are correct.
5.3. Registrar Authorization of Pledge 5.3. Registrar Authorization of Pledge
In a fully automated network all devices must be securely identified In a fully automated network all devices must be securely identified
and authorized to join the domain. and authorized to join the domain.
A Registrar accepts or declines a request to join the domain, based A Registrar accepts or declines a request to join the domain, based
on the authenticated identity presented. Automated acceptance on the authenticated identity presented. Automated acceptance
criteria include: criteria include:
skipping to change at page 39, line 22 skipping to change at page 38, line 40
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.5. As detailed in Section 10 the MASA might detailed in Section 5.5. As detailed in Section 10 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.
skipping to change at page 39, line 46 skipping to change at page 39, line 16
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 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 voucher media type "application/voucher-cms+json" is defined in
voucher-cms+json. It is a JSON document that has been signed using a [RFC8366] and is also used for the registrar voucher-request. It is
CMS structure. The registrar MUST sign the registrar voucher- a JSON document that has been signed using a CMS structure. The
request. The entire registrar certificate chain, up to and including registrar MUST sign the registrar voucher-request. The entire
the Domain CA, MUST be included in the CMS structure. registrar certificate chain, up to and including the Domain CA, MUST
be included in the CMS structure.
MASA impementations SHOULD anticipate future media types but of MASA impementations SHOULD anticipate future media types but of
course will simply fail the request if those types are not yet known. course will simply fail the request if those types are not yet known.
The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept"
header indicating the response media types that are acceptable. This
list SHOULD be the entire list presented to the Registrar in the
Pledge's original request (see Section 5.2) but MAY be a subset.
MASA's are expected to be flexible in what they accept.
The registrar populates the voucher-request fields as follows: The registrar populates the voucher-request fields as follows:
created-on: Registrars are RECOMMENDED to populate this field. This created-on: Registrars are RECOMMENDED to populate this field. This
provides additional information to the MASA. provides additional information to the MASA.
nonce: This is the value from the pledge voucher-request. The nonce: This is the value from the pledge voucher-request. The
registrar voucher-request MAY omit the nonce as per Section 3.1) registrar voucher-request MAY omit the nonce as per Section 3.1)
serial-number: The serial number of the pledge the registrar would serial-number: The serial number of the pledge the registrar would
like a voucher for. The registrar determines this value by like a voucher for. The registrar determines this value by
skipping to change at page 40, line 29 skipping to change at page 40, line 5
Section 2.3. The registrar MUST verify that the serial number Section 2.3. The registrar MUST verify that the serial number
field it parsed matches the serial number field the pledge field it parsed matches the serial number field the pledge
provided in its voucher-request. This provides a sanity check provided in its voucher-request. This provides a sanity check
useful for detecting error conditions and logging. The registrar useful for detecting error conditions and logging. The registrar
MUST NOT simply copy the serial number field from a pledge voucher MUST NOT simply copy the serial number field from a pledge voucher
request as that field is claimed but not certified. request as that field is claimed but not certified.
idevid-issuer: The idevid-issuer value from the pledge certificate idevid-issuer: The idevid-issuer value from the pledge certificate
is included to ensure a statistically unique identity. is included to ensure a statistically unique identity.
prior-signed-voucher-request: If a signed pledge voucher-request was prior-signed-voucher-request: The signed pledge voucher-request
received then it SHOULD be included in the registrar voucher- SHOULD be included in the registrar voucher-request. (NOTE: what
request. (NOTE: what is included is the complete pledge voucher- is included is the complete pledge voucher-request, inclusive of
request, inclusive of the 'assertion', 'proximity-registrar-cert', the 'assertion', 'proximity-registrar-cert', etc wrapped by the
etc wrapped by the pledge's original signature). If a signed pledge's original signature). If a signed voucher-request was not
voucher-request was not recieved from the pledge then this leaf is recieved from the pledge then this leaf is omitted from the
omitted from the registrar voucher request. registrar voucher request.
A nonceless registrar voucher-request MAY be submitted to the MASA. A nonceless registrar voucher-request MAY be submitted to the MASA.
Doing so allows the registrar to request a voucher when the pledge is Doing so allows the registrar to request a voucher when the pledge is
offline, or when the registrar anticipates not being able to connect offline, or when the registrar anticipates not being able to connect
to the MASA while the pledge is being deployed. Some use cases to the MASA while the pledge is being deployed. Some use cases
require the registrar to learn the appropriate IDevID SerialNumber require the registrar to learn the appropriate IDevID SerialNumber
field from the physical device labeling or from the sales channel field and appropriate 'Accept header' field values from the physical
(out-of-scope for this document). device labeling or from the sales channel (out-of-scope for this
document).
All other fields MAY be omitted in the registrar voucher-request. All other fields MAY be omitted in the registrar voucher-request.
Example JSON payloads of registrar voucher-requests are in Example JSON payloads of registrar voucher-requests are in
Section 3.3 Examples 2 through 4. Section 3.3 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.5.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
skipping to change at page 43, line 12 skipping to change at page 42, line 40
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.6. 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). Registrar
evaluation of the voucher itself is purely for transparency and audit
purposes to further inform log verification (see Section 5.8.2) and
therefore a registrar could accept future voucher formats that are
opaque to the registrar.
If the voucher-request is successful, the server (MASA responding to If the voucher-request is successful, the server (MASA responding to
registrar or registrar responding to pledge) response MUST contain an registrar or registrar responding to pledge) response MUST contain an
HTTP 200 response code. The server MUST answer with a suitable 4xx HTTP 200 response code. The server MUST answer with a suitable 4xx
or 5xx HTTP [RFC2616] error code when a problem occurs. In this or 5xx HTTP [RFC2616] error code when a problem occurs. In this
case, the response data from the MASA MUST be a plaintext human- case, the response data from the MASA MUST be a plaintext human-
readable (ASCII, English) error message containing explanatory readable (ASCII, English) error message containing explanatory
information describing why the request was rejected. information describing why the request was rejected.
The registrar MAY respond with an HTTP 202 ("the request has been The registrar MAY respond with an HTTP 202 ("the request has been
skipping to change at page 44, line 17 skipping to change at page 43, line 49
A 406 (Not Acceptable) response is appropriate if a voucher of the A 406 (Not Acceptable) response is appropriate if a voucher of the
desired type or using the desired algorithms (as indicated by the desired type or using the desired algorithms (as indicated by the
Accept: headers, and algorithms used in the signature) cannot be Accept: headers, and algorithms used in the signature) cannot be
issued such as because the MASA knows the pledge cannot process that issued such as because the MASA knows the pledge cannot process that
type. The registrar SHOULD use this response if it determines the type. The registrar SHOULD use this response if it determines the
pledge is unacceptable due to inventory control, MASA audit logs, or pledge is unacceptable due to inventory control, MASA audit logs, or
any other reason. any other reason.
A 415 (Unsupported Media Type) response is approriate for a request A 415 (Unsupported Media Type) response is approriate for a request
that has a voucher encoding that is not understood. that has a voucher-request or accept encoding that is not understood.
The response media type is:
application/voucher-cms+json The response is a "YANG-defined JSON
document that has been signed using a CMS structure" as described
in [RFC8366] using the JSON encoded described in [RFC7951]. The
MASA MUST sign the response.
The syntactic details of vouchers are described in detail in The voucher response format is as indicated in the submitted accept
[RFC8366]. For example, the voucher consists of: header or based on the MASA's prior understanding of proper format
for this Pledge. Only the [RFC8366] "application/voucher-cms+json"
media type is defined at this time. The syntactic details of
vouchers are described in detail in [RFC8366]. For example, the
voucher consists of:
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"assertion": "logging" "assertion": "logging"
"pinned-domain-cert": "base64encodedvalue==" "pinned-domain-cert": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
skipping to change at page 48, line 6 skipping to change at page 47, line 33
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 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 (using the same Content-Type). It
/requestauditlog URI instead. The "idevid-issuer" and "serial- is posted to the /requestauditlog URI instead. The "idevid-issuer"
number" informs the MASA which log is requested so the appropriate and "serial-number" informs the MASA which log is requested so the
log can be prepared for the response. Using the same media type and appropriate log can be prepared for the response. Using the same
message minimizes cryptographic and message operations although it media type and message minimizes cryptographic and message operations
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
as to avoid an extra crypto validation. as to avoid an extra crypto validation.
A registrar MAY request logs at future times. If the registrar A registrar MAY request logs at future times. If the registrar
generates a new request then the MASA is forced to perform the generates a new request then the MASA is forced to perform the
additional cryptographic operations to verify the new request. additional cryptographic operations to verify the new request.
A MASA that receives a request for a device that does not exist, or A MASA that receives a request for a device that does not exist, or
for which the requesting owner was never an owner returns an HTTP 404 for which the requesting owner was never an owner returns an HTTP 404
skipping to change at page 48, line 40 skipping to change at page 48, line 18
URLs SHOULD take care to make the returned URL unguessable. For URLs SHOULD take care to make the returned URL unguessable. For
instance, rather than returning URLs containing a database number instance, rather than returning URLs containing a database number
such as https://example.com/auditlog/1234 or the EUI of the device such as https://example.com/auditlog/1234 or the EUI of the device
such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD
return a randomly generated value (a "slug" in web parlance). The return a randomly generated value (a "slug" in web parlance). The
value is used to find the relevant database entry. value is used to find the relevant database entry.
A MASA that returns a code 200 MAY also include a Location: header A MASA that returns a code 200 MAY also include a Location: header
for future reference by the registrar. for future reference by the registrar.
The request media type is:
application/voucher-cms+json The request is a "YANG-defined JSON
document that has been signed using a CMS structure" as described
in Section 3 using the JSON encoded described in [RFC7951]. The
registrar MUST sign the request. The entire registrar certificate
chain, up to and including the Domain CA, MUST be included in the
CMS structure.
5.8.1. MASA audit log response 5.8.1. MASA audit log response
A log data file is returned consisting of all log entries associated A log data file is returned consisting of all log entries associated
with the the device selected by the IDevID presented in the request. with the the device selected by the IDevID presented in the request.
The audit log may be truncated of old or repeated values as explained The audit log may be truncated of old or repeated values as explained
below. The returned data is in JSON format ([RFC7951]), and the below. The returned data is in JSON format ([RFC7951]), and the
Content-Type SHOULD be "application/json". For example: Content-Type SHOULD be "application/json". For example:
{ {
"version":"1", "version":"1",
skipping to change at page 57, line 22 skipping to change at page 56, line 35
are needed during bootstrapping operations. This is for use are needed during bootstrapping operations. This is for use
cases where the target network is protected by an air gap and cases where the target network is protected by an air gap and
therefore cannot contact the MASA service during pledge therefore cannot contact the MASA service during pledge
deployment. deployment.
4. A registrar MAY ignore unrecognized nonceless log entries. This 4. A registrar MAY ignore unrecognized nonceless log entries. This
could occur when used equipment is purchased with a valid history could occur when used equipment is purchased with a valid history
being deployed in air gap networks that required permanent being deployed in air gap networks that required permanent
vouchers. vouchers.
5. A registrar MAY accept voucher formats of future types that can
not be parsed by the Registrar. This reduces the Registrar's
visibility into the exact voucher contents but does not change
the protocol operations.
6.4. MASA security reductions 6.4. MASA security reductions
Lower security modes chosen by the MASA service affect all device Lower security modes chosen by the MASA service affect all device
deployments unless bound to the specific device identities. In which deployments unless bound to the specific device identities. In which
case these modes can be provided as additional features for specific case these modes can be provided as additional features for specific
customers. The MASA service can choose to run in less secure modes customers. The MASA service can choose to run in less secure modes
by: by:
1. Not enforcing that a nonce is in the voucher. This results in 1. Not enforcing that a nonce is in the voucher. This results in
distribution of a voucher that never expires and in effect makes distribution of a voucher that never expires and in effect makes
skipping to change at page 71, line 4 skipping to change at page 70, line 21
We would like to thank the various reviewers for their input, in We would like to thank the various reviewers for their input, in
particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu
Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg, Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg,
Peter van der Stok, and Thomas Werner Peter van der Stok, and Thomas Werner
Significant reviews were done by Jari Arko, Christian Huitema and Significant reviews were done by Jari Arko, Christian Huitema and
Russ Housley. Russ Housley.
12. References 12. References
12.1. Normative References 12.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-18 (work in progress), August 2018. plane-19 (work in progress), March 2019.
[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 802.1AR Secure Device Identifier", December 2009, [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
skipping to change at page 73, line 48 skipping to change at page 73, line 18
<https://spec.torproject.org/tor-spec>. <https://spec.torproject.org/tor-spec>.
[docsisroot] [docsisroot]
"CableLabs Digital Certificate Issuance Service", February "CableLabs Digital Certificate Issuance Service", February
2018, <https://www.cablelabs.com/resources/ 2018, <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., Richardson, M., and S. Raza, Stok, P., Kampanakis, P., Richardson, M., and S. Raza,
"EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap-
est-09 (work in progress), February 2019. est-10 (work in progress), March 2019.
[I-D.ietf-anima-constrained-voucher] [I-D.ietf-anima-constrained-voucher]
Richardson, M., Stok, P., and P. Kampanakis, "Constrained Richardson, M., Stok, P., and P. Kampanakis, "Constrained
Voucher Artifacts for Bootstrapping Protocols", draft- Voucher Artifacts for Bootstrapping Protocols", draft-
ietf-anima-constrained-voucher-02 (work in progress), ietf-anima-constrained-voucher-03 (work in progress),
September 2018. March 2019.
[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-10 (work in Networking", draft-ietf-anima-reference-model-10 (work in
progress), November 2018. progress), November 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] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor- express CBOR and JSON data structures", draft-ietf-cbor-
cddl-07 (work in progress), February 2019. cddl-08 (work in progress), March 2019.
[I-D.ietf-netconf-zerotouch] [I-D.ietf-netconf-zerotouch]
Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero
Touch Provisioning (SZTP)", draft-ietf-netconf- Touch Provisioning (SZTP)", draft-ietf-netconf-
zerotouch-29 (work in progress), January 2019. zerotouch-29 (work in progress), January 2019.
[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.
skipping to change at page 83, line 10 skipping to change at page 82, line 10
c3: c3:
ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53: ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53:
4b: 4b:
83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a 83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a
D.1.4. Pledge key pair D.1.4. Pledge key pair
The pledge has an IDevID key pair built in at manufacturing time: The pledge has an IDevID key pair built in at manufacturing time:
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIL+ue8PQcN+M7LFBGPsompYwobI/rsoHnTb2a+0hO+8joAoGCCqGSM49 MHcCAQEEIBgR6SV+uEvWfl5zCQWZxWjYbMhXPyNqdHJ3KPh11mm4oAoGCCqGSM49
AwEHoUQDQgAEumBVaDlX87WyME8CJToyt9NWy6sYw0DTbjjJIn79pgr7ALa//Y8p AwEHoUQDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8
r70WpK1SIaiUeeFw7e+lCzTp1Z+wJu14Bg== KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6Tw==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
The public key is used by the registrar to find the MASA. The MASA The public key is used by the registrar to find the MASA. The MASA
URL is in an extension described in Section 2.3. RFC-EDITOR: Note URL is in an extension described in Section 2.3.
that these certificates are using a Private Enterprise Number for the
not-yet-assigned by IANA MASA URL, and need to be replaced before
AUTH48.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIICMjCCAbegAwIBAgIBDDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC MIICBDCCAYugAwIBAgIECe20qTAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQB
Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3Ry
IEhpZ2h3YXkgQ0EwIBcNMTcxMDEyMTM1MjUyWhgPMjk5OTEyMzEwMDAwMDBaMEsx dW5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa
EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEa MBwxGjAYBgNVBAUMETAwLWQwLWU1LTAyLTAwLTJkMFkwEwYHKoZIzj0CAQYIKoZI
MBgGA1UEAwwRMDAtRDAtRTUtRjItMDAtMDIwWTATBgcqhkjOPQIBBggqhkjOPQMB zj0DAQcDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8
BwNCAARJp5i0dU1aUnR2u8wMRwgkNupNbNM7m1n0mj+0KJZjcPIqID+trPjTSobt KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6T6OBhzCBhDAdBgNVHQ4EFgQUj8KYdUoE
uIdpRPfGZ8hU/nIUveqwyoYI8BPbo4GHMIGEMB0GA1UdDgQWBBQdMRZhthFQmzz6 OvJ0kcOIbjEWwgWdDYkwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S
E7YVXzkL7XZDKjAJBgNVHRMEAjAAMCsGA1UdEQQkMCKgIAYJKwYBBAGC7lIBoBMM AaATDBEwMC1EMC1FNS0wMi0wMC0yRDArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l
ETAwLUQwLUU1LUYyLTAwLTAyMCsGCSsGAQQBgu5SAgQeDBxodHRwczovL2hpZ2h3 eWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNnADBkAjAmvMjmNgjypDhc
YXkuc2FuZGVsbWFuLmNhMAoGCCqGSM49BAMCA2kAMGYCMQDhJ1N+eanW1U/e5qoM fynMV3kMuIpSKrYzRWr4g3PtTwXDsAe0oitTTj4QtU1bajhOfTkCMGMNbsW2Q41F
SGvUvWHR7uic8cJbh7vXy580nBs8bpNn60k/+IzvEUetMzICMQCr1uxvdYeKq7mb z9t6PDVdtOKabBbAP1RVoFTlDQuO9nmLzb5kU+cUqCtPRFZBUXP3kg==
RXCR4ZCJsw67fJ7jyXZbCUSir+3wBT2+lWggzPDRgYB5ABb7sAw=
-----END CERTIFICATE----- -----END CERTIFICATE-----
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. There is a second Custom Extension
included to provided to contain the EUI48/EUI64 that the pledge will is included to provided to contain the EUI48/EUI64 that the pledge
configure. will configure as it's layer-2 address (this is non-normative).
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 12 (0xc) Serial Number: 166573225 (0x9edb4a9)
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 Highway CA
Validity Validity
Not Before: Oct 12 13:52:52 2017 GMT Not Before: Apr 24 02:16:58 2019 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: serialNumber = 00-d0-e5-02-00-2d
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:5a:2f:e3:a8:fa:51:27:42:60:5a:08:59:46:07:
c:47: 99:94:b2:ae:b5:b5:d5:8e:69:c7:6f:ed:40:61:a1:
08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b 05:fd:84:23:13:68:39:15:95:7c:2a:38:91:fd:b9:
4:28: 04:97:e9:7c:33:8a:27:20:2e:ca:1d:a5:ca:2a:4b:
96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e 9a:83:d4:ba:4f
d:b8: ASN1 OID: prime256v1
87:69:44:f7:c6:67:c8:54:fe:72:14:bd:ea:b NIST CURVE: P-256
0:ca: X509v3 extensions:
86:08:f0:13:db X509v3 Subject Key Identifier:
ASN1 OID: prime256v1 8F:C2:98:75:4A:04:3A:F2:74:91:C3:88:6E:31:16:C2:05:9D:0D:89
X509v3 extensions: X509v3 Basic Constraints:
X509v3 Subject Key Identifier: CA:FALSE
1D:31:16:61:B6:11:50:9B:3C:FA:13:B6:15:5F:39 X509v3 Subject Alternative Name:
:0B:ED:76:43:2A othername:<unsupported>
X509v3 Basic Constraints: 1.3.6.1.4.1.46930.2:
CA:FALSE ..masa.honeydukes.sandelman.ca
X509v3 Subject Alternative Name: Signature Algorithm: ecdsa-with-SHA256
othername:<unsupported> 30:64:02:30:26:bc:c8:e6:36:08:f2:a4:38:5c:7f:29:cc:57:
1.3.6.1.4.1.46930.2: 79:0c:b8:8a:52:2a:b6:33:45:6a:f8:83:73:ed:4f:05:c3:b0:
..https://highway.sandelman.ca 07:b4:a2:2b:53:4e:3e:10:b5:4d:5b:6a:38:4e:7d:39:02:30:
Signature Algorithm: ecdsa-with-SHA256 63:0d:6e:c5:b6:43:8d:45:cf:db:7a:3c:35:5d:b4:e2:9a:6c:
30:66:02:31:00:e1:27:53:7e:79:a9:d6:d5:4f:de:e6:aa: 16:c0:3f:54:55:a0:54:e5:0d:0b:8e:f6:79:8b:cd:be:64:53:
0c: e7:14:a8:2b:4f:44:56:41:51:73:f7:92
48:6b:d4:bd:61:d1:ee:e8:9c:f1:c2:5b:87:bb:d7:cb:9f:
34:
9c:1b:3c:6e:93:67:eb:49:3f:f8:8c:ef:11:47:ad:33:32:
02:
31:00:ab:d6:ec:6f:75:87:8a:ab:b9:9b:45:70:91:e1:90:
89:
b3:0e:bb:7c:9e:e3:c9:76:5b:09:44:a2:af:ed:f0:05:3d:
be:
95:68:20:cc:f0:d1:81:80:79:00:16:fb:b0:0c
D.2. Example process D.2. Example process
RFC-EDITOR: these examples will need to be replaced with CMS versions RFC-EDITOR: these examples will need to be replaced with CMS versions
once IANA has assigned the eContentType in [RFC8366]. once IANA has assigned the eContentType in [RFC8366].
D.2.1. Pledge to Registrar D.2.1. Pledge to Registrar
As described in Section 5.2, the pledge will sign a pledge voucher- As described in Section 5.2, the pledge will sign a pledge voucher-
request containing the registrar's public key in the proximity- request containing the registrar's public key in the proximity-
 End of changes. 61 change blocks. 
245 lines changed or deleted 215 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/