| < 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/ | ||||