< draft-ietf-anima-constrained-voucher-16.txt   draft-ietf-anima-constrained-voucher-17.txt >
anima Working Group M. Richardson anima Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Updates: 8366, 8995 (if approved) P. van der Stok Updates: 8366, 8995 (if approved) P. van der Stok
Intended status: Standards Track vanderstok consultancy Intended status: Standards Track vanderstok consultancy
Expires: 18 August 2022 P. Kampanakis Expires: 9 October 2022 P. Kampanakis
Cisco Systems Cisco Systems
E. Dijk E. Dijk
IoTconsultancy.nl IoTconsultancy.nl
14 February 2022 7 April 2022
Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI) Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)
draft-ietf-anima-constrained-voucher-16 draft-ietf-anima-constrained-voucher-17
Abstract Abstract
This document defines the Constrained Bootstrapping Remote Secure Key This document defines the Constrained Bootstrapping Remote Secure Key
Infrastructure (Constrained BRSKI) protocol, which provides a Infrastructure (Constrained BRSKI) protocol, which provides a
solution for secure zero-touch bootstrapping of resource-constrained solution for secure zero-touch bootstrapping of resource-constrained
(IoT) devices into the network of a domain owner. This protocol is (IoT) devices into the network of a domain owner. This protocol is
designed for constrained networks, which may have limited data designed for constrained networks, which may have limited data
throughput or may experience frequent packet loss. Constrained BRSKI throughput or may experience frequent packet loss. Constrained BRSKI
is a variant of the BRSKI protocol, which uses an artifact signed by is a variant of the BRSKI protocol, which uses an artifact signed by
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 August 2022. This Internet-Draft will expire on 9 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 26 skipping to change at page 2, line 26
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . 6
5. Updates to RFC8366 and RFC8995 . . . . . . . . . . . . . . . 7 5. Updates to RFC8366 and RFC8995 . . . . . . . . . . . . . . . 7
6. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 7 6. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 8
6.1. Registrar and the Server Name Indicator (SNI) . . . . . . 8 6.1. Registrar and the Server Name Indicator (SNI) . . . . . . 8
6.2. TLS Client Certificates: IDevID authentication . . . . . 9 6.2. TLS Client Certificates: IDevID authentication . . . . . 9
6.3. Discovery, URIs and Content Formats . . . . . . . . . . . 9 6.3. Discovery, URIs and Content Formats . . . . . . . . . . . 10
6.3.1. RFC8995 Telemetry Returns . . . . . . . . . . . . . . 12 6.3.1. RFC8995 Telemetry Returns . . . . . . . . . . . . . . 12
6.4. Join Proxy options . . . . . . . . . . . . . . . . . . . 12 6.4. Join Proxy options . . . . . . . . . . . . . . . . . . . 13
6.5. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 12 6.5. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 13
6.5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 12 6.5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 13
6.5.2. CoAP responses . . . . . . . . . . . . . . . . . . . 13 6.5.2. CoAP responses . . . . . . . . . . . . . . . . . . . 13
6.6. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 13 6.6. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 14
6.6.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 14 6.6.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 15
6.6.2. EST-client Extensions . . . . . . . . . . . . . . . . 15 6.6.2. EST-client Extensions . . . . . . . . . . . . . . . . 16
6.6.3. Registrar Extensions . . . . . . . . . . . . . . . . 18 6.6.3. Registrar Extensions . . . . . . . . . . . . . . . . 18
6.7. DTLS handshake fragmentation Considerations . . . . . . . 18 6.7. DTLS handshake fragmentation Considerations . . . . . . . 19
7. BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . . 19 7. BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . . 19
7.1. Protocol and Formats . . . . . . . . . . . . . . . . . . 19 7.1. Protocol and Formats . . . . . . . . . . . . . . . . . . 19
7.2. Registrar Voucher Request . . . . . . . . . . . . . . . . 20 7.2. Registrar Voucher Request . . . . . . . . . . . . . . . . 20
7.3. MASA and the Server Name Indicator (SNI) . . . . . . . . 20 7.3. MASA and the Server Name Indicator (SNI) . . . . . . . . 20
7.3.1. Registrar Certificate Requirement . . . . . . . . . . 21 7.3.1. Registrar Certificate Requirement . . . . . . . . . . 21
8. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 21 8. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 21
8.1. Registrar Identity Selection and Encoding . . . . . . . . 21 8.1. Registrar Identity Selection and Encoding . . . . . . . . 21
8.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 22 8.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 23
8.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 23 8.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 24
8.4. Considerations for use of IDevID-Issuer . . . . . . . . . 24 8.4. Considerations for use of IDevID-Issuer . . . . . . . . . 25
9. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Voucher Request artifact . . . . . . . . . . . . . . . . 25 9.1. Voucher Request artifact . . . . . . . . . . . . . . . . 26
9.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 25 9.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 26
9.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 26 9.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 27
9.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 27 9.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 28
9.1.4. Example voucher request artifact . . . . . . . . . . 31 9.1.4. Example voucher request artifact . . . . . . . . . . 32
9.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 31 9.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 32
9.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 31 9.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 32
9.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 32 9.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 33
9.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 32 9.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 33
9.2.4. Example voucher artifacts . . . . . . . . . . . . . . 35 9.2.4. Example voucher artifacts . . . . . . . . . . . . . . 36
9.3. Signing voucher and voucher-request artifacts with 9.3. Signing voucher and voucher-request artifacts with
COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 36 COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. Deployment-specific Discovery Considerations . . . . . . . . 37 10. Deployment-specific Discovery Considerations . . . . . . . . 38
10.1. 6TSCH Deployments . . . . . . . . . . . . . . . . . . . 38 10.1. 6TSCH Deployments . . . . . . . . . . . . . . . . . . . 39
10.2. Generic networks using GRASP . . . . . . . . . . . . . . 38 10.2. Generic networks using GRASP . . . . . . . . . . . . . . 39
10.3. Generic networks using mDNS . . . . . . . . . . . . . . 38 10.3. Generic networks using mDNS . . . . . . . . . . . . . . 39
10.4. Thread networks using Mesh Link Establishment (MLE) . . 38 10.4. Thread networks using Mesh Link Establishment (MLE) . . 39
10.5. Non-mesh networks using CoAP Discovery . . . . . . . . . 39 10.5. Non-mesh networks using CoAP Discovery . . . . . . . . . 40
11. Design Considerations . . . . . . . . . . . . . . . . . . . . 39 11. Design Considerations . . . . . . . . . . . . . . . . . . . . 40
12. Raw Public Key Use Considerations . . . . . . . . . . . . . . 39 12. Raw Public Key Use Considerations . . . . . . . . . . . . . . 40
12.1. The Registrar Trust Anchor . . . . . . . . . . . . . . . 39 12.1. The Registrar Trust Anchor . . . . . . . . . . . . . . . 40
12.2. The Pledge Voucher Request . . . . . . . . . . . . . . . 40 12.2. The Pledge Voucher Request . . . . . . . . . . . . . . . 41
12.3. The Voucher Response . . . . . . . . . . . . . . . . . . 40 12.3. The Voucher Response . . . . . . . . . . . . . . . . . . 41
13. Use of constrained vouchers with HTTPS . . . . . . . . . . . 40 13. Use of constrained vouchers with HTTPS . . . . . . . . . . . 41
14. Security Considerations . . . . . . . . . . . . . . . . . . . 41 14. Security Considerations . . . . . . . . . . . . . . . . . . . 42
14.1. Duplicate serial-numbers . . . . . . . . . . . . . . . . 41 14.1. Duplicate serial-numbers . . . . . . . . . . . . . . . . 42
14.2. IDevID security in Pledge . . . . . . . . . . . . . . . 42 14.2. IDevID security in Pledge . . . . . . . . . . . . . . . 43
14.3. Security of CoAP and UDP protocols . . . . . . . . . . . 42 14.3. Security of CoAP and UDP protocols . . . . . . . . . . . 44
14.4. Registrar Certificate may be self-signed . . . . . . . . 42 14.4. Registrar Certificate may be self-signed . . . . . . . . 45
14.5. Use of RPK alternatives to proximity-registrar-cert . . 43 14.5. Use of RPK alternatives to proximity-registrar-cert . . 45
14.6. MASA support of CoAPS . . . . . . . . . . . . . . . . . 43 14.6. MASA support of CoAPS . . . . . . . . . . . . . . . . . 46
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
15.1. Resource Type Registry . . . . . . . . . . . . . . . . . 43 15.1. Resource Type Registry . . . . . . . . . . . . . . . . . 46
15.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 44 15.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 47
15.3. The YANG Module Names Registry . . . . . . . . . . . . . 44 15.3. The YANG Module Names Registry . . . . . . . . . . . . . 47
15.4. The RFC SID range assignment sub-registry . . . . . . . 45 15.4. The RFC SID range assignment sub-registry . . . . . . . 47
15.5. Media Types Registry . . . . . . . . . . . . . . . . . . 45 15.5. Media Types Registry . . . . . . . . . . . . . . . . . . 48
15.5.1. application/voucher-cose+cbor . . . . . . . . . . . 45 15.5.1. application/voucher-cose+cbor . . . . . . . . . . . 48
15.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 46 15.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 48
15.7. Update to BRSKI Parameters Registry . . . . . . . . . . 46 15.7. Update to BRSKI Parameters Registry . . . . . . . . . . 49
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
17. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 48 17. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 50
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
18.1. Normative References . . . . . . . . . . . . . . . . . . 48 18.1. Normative References . . . . . . . . . . . . . . . . . . 50
18.2. Informative References . . . . . . . . . . . . . . . . . 52 18.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Library Support for BRSKI . . . . . . . . . . . . . 54 Appendix A. Library Support for BRSKI . . . . . . . . . . . . . 56
A.1. OpensSSL . . . . . . . . . . . . . . . . . . . . . . . . 54 A.1. OpensSSL . . . . . . . . . . . . . . . . . . . . . . . . 57
A.2. mbedTLS . . . . . . . . . . . . . . . . . . . . . . . . . 55 A.2. mbedTLS . . . . . . . . . . . . . . . . . . . . . . . . . 58
Appendix B. Constrained BRSKI-EST Message Examples . . . . . . . 56 Appendix B. Constrained BRSKI-EST Message Examples . . . . . . . 59
B.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 56 B.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 59
B.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 57 B.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 60
Appendix C. COSE-signed Voucher (Request) Examples . . . . . . . 58 Appendix C. COSE-signed Voucher (Request) Examples . . . . . . . 61
C.1. Pledge, Registrar and MASA Keys . . . . . . . . . . . . . 58 C.1. Pledge, Registrar and MASA Keys . . . . . . . . . . . . . 61
C.1.1. Pledge IDevID private key . . . . . . . . . . . . . . 58 C.1.1. Pledge IDevID private key . . . . . . . . . . . . . . 61
C.1.2. Registrar private key . . . . . . . . . . . . . . . . 58 C.1.2. Registrar private key . . . . . . . . . . . . . . . . 61
C.1.3. MASA private key . . . . . . . . . . . . . . . . . . 59 C.1.3. MASA private key . . . . . . . . . . . . . . . . . . 62
C.2. Pledge, Registrar and MASA Certificates . . . . . . . . . 59 C.2. Pledge, Registrar and MASA Certificates . . . . . . . . . 62
C.2.1. Pledge IDevID Certificate . . . . . . . . . . . . . . 59 C.2.1. Pledge IDevID Certificate . . . . . . . . . . . . . . 62
C.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 61 C.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 64
C.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 63 C.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 66
C.3. COSE-signed Pledge Voucher Request (PVR) . . . . . . . . 65 C.3. COSE-signed Pledge Voucher Request (PVR) . . . . . . . . 68
C.4. COSE-signed Registrar Voucher Request (RVR) . . . . . . . 67 C.4. COSE-signed Registrar Voucher Request (RVR) . . . . . . . 70
C.5. COSE-signed Voucher from MASA . . . . . . . . . . . . . . 69 C.5. COSE-signed Voucher from MASA . . . . . . . . . . . . . . 72
Appendix D. Generating Certificates with OpenSSL . . . . . . . . 71 Appendix D. Generating Certificates with OpenSSL . . . . . . . . 74
Appendix E. Pledge Device Class Profiles . . . . . . . . . . . . 74 Appendix E. Pledge Device Class Profiles . . . . . . . . . . . . 77
E.1. Minimal Pledge . . . . . . . . . . . . . . . . . . . . . 75 E.1. Minimal Pledge . . . . . . . . . . . . . . . . . . . . . 78
E.2. Typical Pledge . . . . . . . . . . . . . . . . . . . . . 75 E.2. Typical Pledge . . . . . . . . . . . . . . . . . . . . . 78
E.3. Full-featured Pledge . . . . . . . . . . . . . . . . . . 75 E.3. Full-featured Pledge . . . . . . . . . . . . . . . . . . 78
E.4. Comparison Chart of Pledge Classes . . . . . . . . . . . 75 E.4. Comparison Chart of Pledge Classes . . . . . . . . . . . 78
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
Secure enrollment of new nodes into constrained networks with Secure enrollment of new nodes into constrained networks with
constrained nodes presents unique challenges. As explained in constrained nodes presents unique challenges. As explained in
[RFC7228], the networks are challenged and the nodes are constrained [RFC7228], the networks are challenged and the nodes are constrained
by energy, memory space, and code size. by energy, memory space, and code size.
The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
described in [RFC8995] provides a solution for secure zero-touch described in [RFC8995] provides a solution for secure zero-touch
skipping to change at page 7, line 41 skipping to change at page 7, line 41
Registrar identity. This is described in more detail in Registrar identity. This is described in more detail in
Section 9.2.3, Section 8 and Section 8.3 (for RPK specifically). Section 9.2.3, Section 8 and Section 8.3 (for RPK specifically).
5. Updates to RFC8366 and RFC8995 5. Updates to RFC8366 and RFC8995
This section details the ways in which this document updates other This section details the ways in which this document updates other
RFCs. The terminology for Updates is taken from RFCs. The terminology for Updates is taken from
[I-D.kuehlewind-update-tag]. [I-D.kuehlewind-update-tag].
This document Updates [RFC8366]. It Extends [RFC8366] by creating a This document Updates [RFC8366]. It Extends [RFC8366] by creating a
new serialization format. new serialization format, and creates a mechanism to pin Raw Public
Key (RPK).
This document Updates [RFC8995]. It Amends [RFC8995] by clarifying This document Updates [RFC8995]. It Amends [RFC8995]
how pinning is done, and ???.
* by clarifying how pinning is done,
* adopts clearer explanation of the TLS Server Name Indicator (SNI),
see Section 6.1 and Section 7.3
* clarifies when new trust anchors should be retrieved
(Section 6.6.1),
* clarified what kinds of Extended Key Usage attributes are
appropriate for each certificate (Section 7.3.1)
It Extends [RFC8995] as follows: * defines the CoAP version of the
BRSKI protocol
* makes some messages optional if the results can be inferred from
other validations (Section 6.6),
* provides the option to return trust anchors in a simpler format
(Section 6.6.3)
* extends the BRSKI-MASA protocol to carry the new voucher-cose+cbor
format.
6. BRSKI-EST Protocol 6. BRSKI-EST Protocol
This section describes the constrained BRSKI extensions to EST-coaps This section describes the constrained BRSKI extensions to EST-coaps
[I-D.ietf-ace-coap-est] to transport the voucher between Registrar [I-D.ietf-ace-coap-est] to transport the voucher between Registrar
and Pledge (optionally via a Join Proxy) over CoAP. The extensions and Pledge (optionally via a Join Proxy) over CoAP. The extensions
are targeting low-resource networks with small packets. are targeting low-resource networks with small packets.
The constrained BRSKI-EST protocol described in this section is The constrained BRSKI-EST protocol described in this section is
between the Pledge and the Registrar only. between the Pledge and the Registrar only.
skipping to change at page 26, line 47 skipping to change at page 27, line 42
2506 data .../idevid-issuer 2506 data .../idevid-issuer
2507 data .../last-renewal-date 2507 data .../last-renewal-date
2508 data /ietf-voucher-request-constrained:voucher/nonce 2508 data /ietf-voucher-request-constrained:voucher/nonce
2509 data .../pinned-domain-cert 2509 data .../pinned-domain-cert
2510 data .../prior-signed-voucher-request 2510 data .../prior-signed-voucher-request
2511 data .../proximity-registrar-cert 2511 data .../proximity-registrar-cert
2513 data .../proximity-registrar-pubk 2513 data .../proximity-registrar-pubk
2512 data .../proximity-registrar-pubk-sha256 2512 data .../proximity-registrar-pubk-sha256
2514 data .../serial-number 2514 data .../serial-number
WARNING, obsolete definitions
The "assertion" attribute is an enumerated type [RFC8366], and the The "assertion" attribute is an enumerated type [RFC8366], and the
current PYANG tooling does not document the valid values for this current PYANG tooling does not document the valid values for this
attribute. In the JSON serialization, the literal strings from the attribute. In the JSON serialization, the literal strings from the
enumerated types are used so there is no ambiguity. In the CBOR enumerated types are used so there is no ambiguity. In the CBOR
serialization, a small integer is used. This following values are serialization, a small integer is used. This following values are
documented here, but the YANG module should be considered documented here, but the YANG module should be considered
authoritative. No IANA registry is provided or necessary because the authoritative. No IANA registry is provided or necessary because the
YANG module provides for extensions. YANG module provides for extensions.
+=========+================+ +=========+================+
skipping to change at page 32, line 38 skipping to change at page 33, line 38
2454 data .../domain-cert-revocation-checks 2454 data .../domain-cert-revocation-checks
2455 data /ietf-voucher-constrained:voucher/expires-on 2455 data /ietf-voucher-constrained:voucher/expires-on
2456 data /ietf-voucher-constrained:voucher/idevid-issuer 2456 data /ietf-voucher-constrained:voucher/idevid-issuer
2457 data .../last-renewal-date 2457 data .../last-renewal-date
2458 data /ietf-voucher-constrained:voucher/nonce 2458 data /ietf-voucher-constrained:voucher/nonce
2459 data .../pinned-domain-cert 2459 data .../pinned-domain-cert
2460 data .../pinned-domain-pubk 2460 data .../pinned-domain-pubk
2461 data .../pinned-domain-pubk-sha256 2461 data .../pinned-domain-pubk-sha256
2462 data /ietf-voucher-constrained:voucher/serial-number 2462 data /ietf-voucher-constrained:voucher/serial-number
WARNING, obsolete definitions
The "assertion" enumerated attribute is numbered as per The "assertion" enumerated attribute is numbered as per
Section 9.1.2. Section 9.1.2.
9.2.3. YANG Module 9.2.3. YANG Module
In the voucher-constrained YANG module, the voucher is "augmented" In the voucher-constrained YANG module, the voucher is "augmented"
within the "used" grouping statement such that one continuous set of within the "used" grouping statement such that one continuous set of
SID values is generated for the voucher-constrained module name, all SID values is generated for the voucher-constrained module name, all
voucher attributes, and the voucher-constrained attributes. Two voucher attributes, and the voucher-constrained attributes. Two
attributes of the voucher are "refined" to be optional. attributes of the voucher are "refined" to be optional.
skipping to change at page 42, line 16 skipping to change at page 43, line 16
operation. operation.
This attack is prevented by the mechanism of having the Registrar This attack is prevented by the mechanism of having the Registrar
include the idevid-issuer in the RVR, and the MASA including it in include the idevid-issuer in the RVR, and the MASA including it in
the resulting voucher. The idevid-issuer is not included by default: the resulting voucher. The idevid-issuer is not included by default:
a MASA needs to be aware if there are parts of the organization which a MASA needs to be aware if there are parts of the organization which
duplicates serial numbers, and if so, include it. duplicates serial numbers, and if so, include it.
14.2. IDevID security in Pledge 14.2. IDevID security in Pledge
TBD. The security of this protocol depends upon the Pledge identifying
itself to the Registrar using it's manufacturer installed
certificate: the IDevID certificate. Associated with this
certificate is the IDevID private key, known only to the Pledge.
Disclosure of this private key to an attacker would permit the
attacker to impersonate the Pledge towards the Registrar, probably
gaining access credentials to that Registrar's network.
If the IDevID private key disclosure is known to the manufacturer,
there is little recourse other than recall of the relevant part
numbers. The process for communicating this recall would be within
the BRSKI-MASA protocol. Neither this specification nor [RFC8995]
provides for consultation of a Certification Revocation List (CRL) or
Open Certificate Status Protocol (OCSP) by a Registrar when
evaluating an IDevID certificate. However, the BRSKI-MASA protocol
submits the IDevID from the Registrar to the manufacturer's MASA and
a manufacturer would have an opportunity to decline to issue a
voucher for a device which they believe has become compromised.
It may be difficult for a manufacturer to determine when an IDevID
private key has been disclosed. Two situations present themselves:
in the first situation a compromised private key might be reused in a
counterfeit device, which is sold to another customer. This would
present itself as an onboarding of the same device in two different
networks. The manufacturer may become suspicious seeing two voucher
requests for the same device from different Registrars. Such
activity could be indistinguishable from a device which has been
resold from one operator to another, or re-deployed by an operator
from one location to another.
In the second situation, an attacker having compromised the IDevID
private key of a device might then install malware into the same
device and attempt to return it to service. The device, now blank,
would go through a second onboarding process with the original
Registrar. Such a Registrar could notice that the device has been
"factory reset" and alert the operator to this situation. One remedy
against the presence of malware is through the use of Remote
Attestation such as described in [I-D.ietf-rats-architecture].
Future work will need to specify a background-check Attestation flow
as part of the voucher-request/voucher-response process. Attestation
may still require access to a private key (e.g. IDevID private key)
in order to sign Evidence, so a primary goal should be to keep any
private key safe within the Pledge.
In larger, more expensive, systems there is budget (power, space, and
bill of materials) to include more specific defenses for a private
key. For instance, this includes putting the IDevID private key in a
Trusted Platform Module (TPM), or use of Trusted Execution
Environments (TEE) for access to the key. On smaller IoT devices,
the cost and power budget for an extra part is often prohibitive.
It is becoming more and more common for CPUs to have an internal set
of one-time fuses that can be programmed (often they are "burnt" by a
laser) at the factory. This section of memory is only accessible in
some priviledged CPU state. The use of this kind of CPU is
appropriate as it provides significant resistance against key
disclosure even when the device can be disassembled by an attacker.
In a number of industry verticals, there is increasing concern about
counterfeit parts. These may be look-alike parts created in a
different factory, or parts which are created in the same factory
during an illegal night-shift, but which are not subject to the
appropriate level of quality control. The use of a manufacturer-
signed IDevID certificate provides for discovery of the pedigree of
each part, and this often justifies the cost of the security measures
associated with storing the private key.
14.3. Security of CoAP and UDP protocols 14.3. Security of CoAP and UDP protocols
Section 7.1 explains that no CoAPS version of the BRSKI-MASA protocol Section 7.1 explains that no CoAPS version of the BRSKI-MASA protocol
is proposed. The connection from the Registrar to the MASA continues is proposed. The connection from the Registrar to the MASA continues
to be HTTPS as in [RFC8995]. This has been done to simplify the MASA to be HTTPS as in [RFC8995]. This has been done to simplify the MASA
deployment for the manufacturer, because no new protocol needs to be deployment for the manufacturer, because no new protocol needs to be
enabled on the server. enabled on the server.
The use of UDP protocols across the open Internet is sometimes The use of UDP protocols across the open Internet is sometimes
skipping to change at page 49, line 16 skipping to change at page 51, line 23
Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M.
Richardson, "YANG Schema Item iDentifier (YANG SID)", Work Richardson, "YANG Schema Item iDentifier (YANG SID)", Work
in Progress, Internet-Draft, draft-ietf-core-sid-18, 18 in Progress, Internet-Draft, draft-ietf-core-sid-18, 18
November 2021, <https://www.ietf.org/archive/id/draft- November 2021, <https://www.ietf.org/archive/id/draft-
ietf-core-sid-18.txt>. ietf-core-sid-18.txt>.
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Petrov, I., Pelov, A., Bormann, C., and M. Veillette, M., Petrov, I., Pelov, A., Bormann, C., and M.
Richardson, "CBOR Encoding of Data Modeled with YANG", Richardson, "CBOR Encoding of Data Modeled with YANG",
Work in Progress, Internet-Draft, draft-ietf-core-yang- Work in Progress, Internet-Draft, draft-ietf-core-yang-
cbor-18, 19 December 2021, cbor-19, 20 March 2022, <https://www.ietf.org/archive/id/
<https://www.ietf.org/archive/id/draft-ietf-core-yang- draft-ietf-core-yang-cbor-19.txt>.
cbor-18.txt>.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", Work in Progress, Internet-Draft, Initial Algorithms", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020,
<https://www.ietf.org/archive/id/draft-ietf-cose- <https://www.ietf.org/archive/id/draft-ietf-cose-
rfc8152bis-algs-12.txt>. rfc8152bis-algs-12.txt>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
skipping to change at page 50, line 6 skipping to change at page 52, line 14
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021, dtls13-43, 30 April 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls- <https://www.ietf.org/archive/id/draft-ietf-tls-
dtls13-43.txt>. dtls13-43.txt>.
[ieee802-1AR] [ieee802-1AR]
IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", IEEE Standard, "IEEE 802.1AR Secure Device Identifier",
2009, <http://standards.ieee.org/findstds/ 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
skipping to change at page 52, line 18 skipping to change at page 54, line 23
<https://www.rfc-editor.org/info/rfc9031>. <https://www.rfc-editor.org/info/rfc9031>.
[RFC9032] Dujovne, D., Ed. and M. Richardson, "Encapsulation of [RFC9032] Dujovne, D., Ed. and M. Richardson, "Encapsulation of
6TiSCH Join and Enrollment Information Elements", 6TiSCH Join and Enrollment Information Elements",
RFC 9032, DOI 10.17487/RFC9032, May 2021, RFC 9032, DOI 10.17487/RFC9032, May 2021,
<https://www.rfc-editor.org/info/rfc9032>. <https://www.rfc-editor.org/info/rfc9032>.
18.2. Informative References 18.2. Informative References
[COSE-registry] [COSE-registry]
IANA, ., "CBOR Object Signing and Encryption (COSE) IANA, "CBOR Object Signing and Encryption (COSE)
registry", 2017, registry", 2017,
<https://www.iana.org/assignments/cose/cose.xhtml>. <https://www.iana.org/assignments/cose/cose.xhtml>.
[I-D.ietf-6lo-mesh-link-establishment] [I-D.ietf-6lo-mesh-link-establishment]
Kelsey, R., "Mesh Link Establishment", Work in Progress, Kelsey, R., "Mesh Link Establishment", Work in Progress,
Internet-Draft, draft-ietf-6lo-mesh-link-establishment-00, Internet-Draft, draft-ietf-6lo-mesh-link-establishment-00,
1 December 2015, <https://www.ietf.org/archive/id/draft- 1 December 2015, <https://www.ietf.org/archive/id/draft-
ietf-6lo-mesh-link-establishment-00.txt>. ietf-6lo-mesh-link-establishment-00.txt>.
[I-D.ietf-anima-constrained-join-proxy] [I-D.ietf-anima-constrained-join-proxy]
Richardson, M., Stok, P. V. D., and P. Kampanakis, Richardson, M., Stok, P. V. D., and P. Kampanakis,
"Constrained Join Proxy for Bootstrapping Protocols", Work "Constrained Join Proxy for Bootstrapping Protocols", Work
in Progress, Internet-Draft, draft-ietf-anima-constrained- in Progress, Internet-Draft, draft-ietf-anima-constrained-
join-proxy-06, 3 December 2021, join-proxy-09, 25 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-anima- <https://www.ietf.org/archive/id/draft-ietf-anima-
constrained-join-proxy-06.txt>. constrained-join-proxy-09.txt>.
[I-D.ietf-anima-jws-voucher] [I-D.ietf-anima-jws-voucher]
Richardson, M. and T. Werner, "JWS signed Voucher Richardson, M. and T. Werner, "JWS signed Voucher
Artifacts for Bootstrapping Protocols", Work in Progress, Artifacts for Bootstrapping Protocols", Work in Progress,
Internet-Draft, draft-ietf-anima-jws-voucher-01, 25 Internet-Draft, draft-ietf-anima-jws-voucher-03, 7 March
October 2021, <https://www.ietf.org/archive/id/draft-ietf- 2022, <https://www.ietf.org/archive/id/draft-ietf-anima-
anima-jws-voucher-01.txt>. jws-voucher-03.txt>.
[I-D.ietf-lake-edhoc] [I-D.ietf-lake-edhoc]
Selander, G., Mattsson, J. P., and F. Palombini, Selander, G., Mattsson, J. P., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20
October 2021, <https://www.ietf.org/archive/id/draft-ietf- October 2021, <https://www.ietf.org/archive/id/draft-ietf-
lake-edhoc-12.txt>. lake-edhoc-12.txt>.
[I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", Work
in Progress, Internet-Draft, draft-ietf-rats-architecture-
15, 8 February 2022, <https://www.ietf.org/archive/id/
draft-ietf-rats-architecture-15.txt>.
[I-D.kuehlewind-update-tag] [I-D.kuehlewind-update-tag]
Kuehlewind, M. and S. Krishnan, "Definition of new tags Kuehlewind, M. and S. Krishnan, "Definition of new tags
for relations between RFCs", Work in Progress, Internet- for relations between RFCs", Work in Progress, Internet-
Draft, draft-kuehlewind-update-tag-04, 12 July 2021, Draft, draft-kuehlewind-update-tag-04, 12 July 2021,
<https://www.ietf.org/archive/id/draft-kuehlewind-update- <https://www.ietf.org/archive/id/draft-kuehlewind-update-
tag-04.txt>. tag-04.txt>.
[I-D.richardson-anima-masa-considerations] [I-D.richardson-anima-masa-considerations]
Richardson, M. and W. Pan, "Operatonal Considerations for Richardson, M. and W. Pan, "Operatonal Considerations for
Voucher infrastructure for BRSKI MASA", Work in Progress, Voucher infrastructure for BRSKI MASA", Work in Progress,
skipping to change at page 54, line 5 skipping to change at page 56, line 19
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
Autonomic Signaling Protocol (GRASP)", RFC 8990, Autonomic Signaling Protocol (GRASP)", RFC 8990,
DOI 10.17487/RFC8990, May 2021, DOI 10.17487/RFC8990, May 2021,
<https://www.rfc-editor.org/info/rfc8990>. <https://www.rfc-editor.org/info/rfc8990>.
[Thread] Thread Group, Inc, ., "Thread support page, White Papers", [Thread] Thread Group, Inc, "Thread support page, White Papers",
November 2021, November 2021,
<https://www.threadgroup.org/support#Whitepapers>. <https://www.threadgroup.org/support#Whitepapers>.
Appendix A. Library Support for BRSKI Appendix A. Library Support for BRSKI
For the implementation of BRSKI, the use of a software library to For the implementation of BRSKI, the use of a software library to
manipulate certificates and use crypto algorithms is often manipulate certificates and use crypto algorithms is often
beneficial. Two C-based examples are OpenSSL and mbedtls. Others beneficial. Two C-based examples are OpenSSL and mbedtls. Others
more targeted to specific platforms or languages exist. It is more targeted to specific platforms or languages exist. It is
important to realize that the library interfaces differ significantly important to realize that the library interfaces differ significantly
 End of changes. 24 change blocks. 
102 lines changed or deleted 200 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/