draft-ietf-anima-bootstrapping-keyinfra-26.txt   draft-ietf-anima-bootstrapping-keyinfra-27.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: February 15, 2020 Sandelman Expires: March 18, 2020 Sandelman
T. Eckert T. Eckert
Futurewei USA Futurewei USA
M. Behringer M. Behringer
K. Watsen K. Watsen
Watsen Networks Watsen Networks
August 14, 2019 September 15, 2019
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-26 draft-ietf-anima-bootstrapping-keyinfra-27
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 certificates, in is created using manufacturer installed X.509 certificates, 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 February 15, 2020. This Internet-Draft will expire on March 18, 2020.
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 2, line 37 skipping to change at page 2, line 37
1.3.2. Constrained environments . . . . . . . . . . . . . . 11 1.3.2. Constrained environments . . . . . . . . . . . . . . 11
1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12
1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12 1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12
1.4. Leveraging the new key infrastructure / next steps . . . 12 1.4. Leveraging the new key infrastructure / next steps . . . 12
1.5. Requirements for Autonomic Network Infrastructure (ANI) 1.5. Requirements for Autonomic Network Infrastructure (ANI)
devices . . . . . . . . . . . . . . . . . . . . . . . . . 12 devices . . . . . . . . . . . . . . . . . . . . . . . . . 12
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13
2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17
2.3.1. Identification of the Pledge . . . . . . . . . . . . 17 2.3.1. Identification of the Pledge . . . . . . . . . . . . 18
2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 18 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 18
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 20 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 20
2.5. Architectural Components . . . . . . . . . . . . . . . . 23 2.5. Architectural Components . . . . . . . . . . . . . . . . 23
2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23
2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23
2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23
2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 23 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 24
2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24
2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24
2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24
2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 24 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 25
2.8. Determining the MASA to contact . . . . . . . . . . . . . 25 2.8. Determining the MASA to contact . . . . . . . . . . . . . 25
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26
3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 26 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 26
3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 26 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 29
4. Proxying details (Pledge - Proxy - 4. Proxying details (Pledge - Proxy -
Registrar) . . . . . . . . . . . . . . . . . . . . . . . . . 32 Registrar) . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 33 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 33
4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 34 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 35
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 35 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 36
4.3. Proxy discovery and communication of Registrar . . . . . 36 4.3. Proxy discovery and communication of Registrar . . . . . 36
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 37 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 37
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 39 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 39
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 40 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 40
5.3. Registrar Authorization of 5.3. Registrar Authorization of
Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 41 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 41 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 42
5.4.1. MASA authentication of 5.4.1. MASA authentication of
customer Registrar . . . . . . . . . . . . . . . . . 42 customer Registrar . . . . . . . . . . . . . . . . . 42
5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 43 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 43
5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 45 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 45
5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 45 5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 45
5.5.3. MASA checking of voucher request signature . . . . . 45 5.5.3. MASA checking of voucher request signature . . . . . 45
5.5.4. MASA verification of domain registrar . . . . . . . . 46 5.5.4. MASA verification of domain registrar . . . . . . . . 46
5.5.5. MASA verification of pledge prior-signed-voucher- 5.5.5. MASA verification of pledge prior-signed-voucher-
request . . . . . . . . . . . . . . . . . . . . . . . 46 request . . . . . . . . . . . . . . . . . . . . . . . 47
5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 47 5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 47
5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 47 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 47
5.6.1. Pledge voucher verification . . . . . . . . . . . . . 50 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 50
5.6.2. Pledge authentication of provisional TLS connection . 50 5.6.2. Pledge authentication of provisional TLS connection . 51
5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 51 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 52
5.8. Registrar audit-log request . . . . . . . . . . . . . . . 52 5.8. Registrar audit-log request . . . . . . . . . . . . . . . 53
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 54 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 54
5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 55 5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 56
5.8.3. Registrar audit log verification . . . . . . . . . . 56 5.8.3. Registrar audit log verification . . . . . . . . . . 57
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 57 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 58
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 57 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 58
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 58 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 59
5.9.3. EST Client Certificate Request . . . . . . . . . . . 59 5.9.3. EST Client Certificate Request . . . . . . . . . . . 60
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 59 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 60
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 60 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 61
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 60 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 61
6. Clarification of transfer-encoding . . . . . . . . . . . . . 60 6. Clarification of transfer-encoding . . . . . . . . . . . . . 61
7. Reduced security operational modes . . . . . . . . . . . . . 60 7. Reduced security operational modes . . . . . . . . . . . . . 61
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 61 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 62
7.2. Pledge security reductions . . . . . . . . . . . . . . . 61 7.2. Pledge security reductions . . . . . . . . . . . . . . . 62
7.3. Registrar security reductions . . . . . . . . . . . . . . 62 7.3. Registrar security reductions . . . . . . . . . . . . . . 63
7.4. MASA security reductions . . . . . . . . . . . . . . . . 63 7.4. MASA security reductions . . . . . . . . . . . . . . . . 64
7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 63 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 64
7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 64 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 65
7.4.3. Updating or extending voucher trust anchors . . . . . 65 7.4.3. Updating or extending voucher trust anchors . . . . . 66
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 66 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 67
8.2. Well-known EST registration . . . . . . . . . . . . . . . 66 8.2. Well-known EST registration . . . . . . . . . . . . . . . 67
8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 66 8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 67
8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 66 8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 67
8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 67 8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 68
8.6. MUD File Extension for the MASA . . . . . . . . . . . . . 67 8.6. MUD File Extension for the MASA . . . . . . . . . . . . . 68
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 67 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 68
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 68 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 70
10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 68 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 70
10.2. What BRSKI-EST reveals to the registrar . . . . . . . . 69 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 70
10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 69 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 71
10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 71 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 73
10.5. Manufacturers and Grey market equipment . . . . . . . . 72 10.5. Manufacturers and Grey market equipment . . . . . . . . 74
10.6. Some mitigations for meddling by manufacturers . . . . . 73 10.6. Some mitigations for meddling by manufacturers . . . . . 75
11. Security Considerations . . . . . . . . . . . . . . . . . . . 74 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 76
11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 76
11.2. Availability of good random numbers . . . . . . . . . . 76 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 77
11.3. Freshness in Voucher-Requests . . . . . . . . . . . . . 76 11.2. Availability of good random numbers . . . . . . . . . . 78
11.4. Trusting manufacturers . . . . . . . . . . . . . . . . . 77 11.3. Freshness in Voucher-Requests . . . . . . . . . . . . . 78
11.5. Manufacturer Maintenance of trust anchors . . . . . . . 78 11.4. Trusting manufacturers . . . . . . . . . . . . . . . . . 79
11.5.1. Compromise of Manufacturer IDevID signing keys . . . 79 11.5. Manufacturer Maintenance of trust anchors . . . . . . . 81
11.5.2. Compromise of MASA signing keys . . . . . . . . . . 80 11.5.1. Compromise of Manufacturer IDevID signing keys . . . 82
11.5.3. Compromise of MASA web service . . . . . . . . . . . 82 11.5.2. Compromise of MASA signing keys . . . . . . . . . . 82
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82 11.5.3. Compromise of MASA web service . . . . . . . . . . . 84
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 85
13.1. Normative References . . . . . . . . . . . . . . . . . . 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.2. Informative References . . . . . . . . . . . . . . . . . 86 13.1. Normative References . . . . . . . . . . . . . . . . . . 85
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 89 13.2. Informative References . . . . . . . . . . . . . . . . . 89
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 90 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 92
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 90 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 92
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 90 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 92
Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 91 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 93
Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 93 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 93
D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 93 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 96
D.1.1. MASA key pair for voucher signatures . . . . . . . . 93 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 96
D.1.2. Manufacturer key pair for IDevID signatures . . . . . 93 D.1.1. MASA key pair for voucher signatures . . . . . . . . 96
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 94 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 96
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 96 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 97
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 97 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 99
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 98 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 100
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 101 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 101
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 106 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 104
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 109
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113
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]. This bootstrap process [I-D.ietf-anima-autonomic-control-plane]. This bootstrap process
skipping to change at page 16, line 21 skipping to change at page 16, line 21
included ensuring that any responses can be associated with this included ensuring that any responses can be associated with this
particular bootstrapping attempt. particular bootstrapping attempt.
4. Imprint on the registrar. This requires verification of the 4. Imprint on the registrar. This requires verification of the
manufacturer service provided voucher. A voucher contains manufacturer service provided voucher. A voucher contains
sufficient information for the pledge to complete authentication sufficient information for the pledge to complete authentication
of a registrar. This document details this step in depth. of a registrar. This document details this step in depth.
5. Enroll. After imprint an authenticated TLS (HTTPS) connection 5. Enroll. After imprint an authenticated TLS (HTTPS) connection
exists between pledge and registrar. Enrollment over Secure exists between pledge and registrar. Enrollment over Secure
Transport (EST) [RFC7030] can then used to obtain a domain Transport (EST) [RFC7030] can then be used to obtain a domain
certificate from a registrar. certificate from a registrar.
The pledge is now a member of, and can be managed by, the domain and The pledge is now a member of, and can be managed by, the domain and
will only repeat the discovery aspects of bootstrapping if it is will only repeat the discovery aspects of bootstrapping if it is
returned to factory default settings. returned to factory default settings.
This specification details integration with EST enrollment so that This specification details integration with EST enrollment so that
pledges can optionally obtain a locally issued certificate, although pledges can optionally obtain a locally issued certificate, although
any REST interface could be integrated in future work. any REST interface could be integrated in future work.
skipping to change at page 17, line 25 skipping to change at page 17, line 25
PKIX-shaped certificate installed during the manufacturing process. PKIX-shaped certificate installed during the manufacturing process.
This is the 802.1AR Initial Device Identifier (IDevID), and it This is the 802.1AR Initial Device Identifier (IDevID), and it
provides a basis for authenticating the pledge during the protocol provides a basis for authenticating the pledge during the protocol
exchanges described here. There is no requirement for a common root exchanges described here. There is no requirement for a common root
PKI hierarchy. Each device manufacturer can generate its own root PKI hierarchy. Each device manufacturer can generate its own root
certificate. Specifically, the IDevID enables: certificate. Specifically, the IDevID enables:
1. Uniquely identifying the pledge by the Distinguished Name (DN) 1. Uniquely identifying the pledge by the Distinguished Name (DN)
and subjectAltName (SAN) parameters in the IDevID. The unique and subjectAltName (SAN) parameters in the IDevID. The unique
identification of a pledge in the voucher objects are derived identification of a pledge in the voucher objects are derived
from those parameters as described below. Section 10.3 discussed from those parameters as described below. Section 10.3 discusses
privacy implications. privacy implications of the identifier.
2. Provides a cryptographic authentication of the pledge to the 2. Provides a cryptographic authentication of the pledge to the
Registrar (see Section 5.3). Registrar (see Section 5.3).
3. Secure auto-discovery of the pledge's MASA by the registrar (see 3. Secure auto-discovery of the pledge's MASA by the registrar (see
Section 2.8). Section 2.8).
4. Signing of voucher-request by the pledge's IDevID (see 4. Signing of voucher-request by the pledge's IDevID (see
Section 3). Section 3).
5. Provides a cryptographic authentication of the pledge to the MASA 5. Provides a cryptographic authentication of the pledge to the MASA
(see Section 5.5.5). (see Section 5.5.5).
Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of
[IDevID] discusses keyUsage and extendedKeyUsage extensions in the [IDevID] discusses keyUsage and extendedKeyUsage extensions in the
IDevID certificate. Any restrictions included reduce the utility of IDevID certificate. [IDevID] acknowledges that adding restrictions
the IDevID and so this specification RECOMMENDS that no key usage in the certificate limits applicability of these long-lived
restrictions be included. Additionally, [RFC5280] section 4.2.1.3 certificates. This specification emphasizes this point, and
does not require key usage restrictions for end entity certificates. therefore RECOMMENDS that no key usage restrictions be included.
This is consistent with [RFC5280] section 4.2.1.3, which does not
require key usage restrictions for end entity certificates.
2.3.1. Identification of the Pledge 2.3.1. Identification of the Pledge
In the context of BRSKI, pledges have a 1:1 relationship with a In the context of BRSKI, pledges have a 1:1 relationship with a
"serial-number". This serial-number is used both in the "serial- "serial-number". This serial-number is used both in the "serial-
number" field of voucher or voucher-requests (see Section 3) and in number" field of voucher or voucher-requests (see Section 3) and in
local policies on registrar or MASA (see Section 5). local policies on registrar or MASA (see Section 5).
The serialNumber fields is defined in [RFC5280], and is a SHOULD The serialNumber fields is defined in [RFC5280], and is a SHOULD
field in [IDevID]. IDevID certificates for use with this protocol field in [IDevID]. IDevID certificates for use with this protocol
skipping to change at page 21, line 13 skipping to change at page 21, line 13
A representative flow is shown in Figure 4 A representative flow is shown in Figure 4
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| Pledge | | Circuit | | Domain | | Vendor | | Pledge | | Circuit | | Domain | | Vendor |
| | | Join | | Registrar | | Service | | | | Join | | Registrar | | Service |
| | | Proxy | | (JRC) | | (MASA) | | | | Proxy | | (JRC) | | (MASA) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| | | Internet | | | | Internet |
[discover] | | | [discover] | | |
|<-RFC4862 IPv6 addr | | | |<-RFC4862 IPv6 addr | | |
|<-RFC3927 IPv4 addr | Appendix A | Legend | |<-RFC3927 IPv4 addr | Appendix A | Legend |
|-------------------->| | C - circuit | |-++++++++++++++++++->| | C - circuit |
| optional: mDNS query| Appendix B | join proxy | | optional: mDNS query| Appendix B | join proxy |
| RFC6763/RFC6762 | | P - provisional | | RFC6763/RFC6762 (+) | | P - provisional |
|<--------------------| | TLS connection | |<-++++++++++++++++++-| | TLS connection |
| GRASP M_FLOOD | | | | GRASP M_FLOOD | | |
| periodic broadcast| | | | periodic broadcast| | |
[identity] | | | [identity] | | |
|<------------------->C<----------------->| | |<------------------->C<----------------->| |
| TLS via the Join Proxy | | | TLS via the Join Proxy | |
|<--Registrar TLS server authentication---| | |<--Registrar TLS server authentication---| |
[PROVISIONAL accept of server cert] | | [PROVISIONAL accept of server cert] | |
P---X.509 client authentication---------->| | P---X.509 client authentication---------->| |
[request join] | | [request join] | |
P---Voucher Request(w/nonce for voucher)->| | P---Voucher Request(w/nonce for voucher)->| |
skipping to change at page 23, line 9 skipping to change at page 23, line 9
When BRSKI is followed with EST this single footprint is further When BRSKI is followed with EST this single footprint is further
leveraged into the full owner's PKI and a LDevID for the device. leveraged into the full owner's PKI and a LDevID for the device.
Subsequent reporting steps provide flows of information to indicate Subsequent reporting steps provide flows of information to indicate
success/failure of the process. success/failure of the process.
2.5. Architectural Components 2.5. Architectural Components
2.5.1. Pledge 2.5.1. Pledge
The pledge is the device that is attempting to join. Until the The pledge is the device that is attempting to join. The pledge can
pledge completes the enrollment process, it has link-local network talk to the Join Proxy using link-local network connectivity. In
connectivity only to the proxy. most cases, the pledge has no other connectivity until the pledge
completes the enrollment process and receives some kind of network
credential.
2.5.2. Join Proxy 2.5.2. Join Proxy
The join proxy provides HTTPS connectivity between the pledge and the The join proxy provides HTTPS connectivity between the pledge and the
registrar. A circuit proxy mechanism is described in Section 4. registrar. A circuit proxy mechanism is described in Section 4.
Additional mechanisms, including a CoAP mechanism and a stateless Additional mechanisms, including a CoAP mechanism and a stateless
IPIP mechanism are the subject of future work. IPIP mechanism are the subject of future work.
2.5.3. Domain Registrar 2.5.3. Domain Registrar
skipping to change at page 23, line 36 skipping to change at page 23, line 38
"Registration Authority" if the pledge requests an end entity "Registration Authority" if the pledge requests an end entity
certificate over the BRSKI-EST connection (see Section 5.9). certificate over the BRSKI-EST connection (see Section 5.9).
The registrar uses an Implicit Trust Anchor database for The registrar uses an Implicit Trust Anchor database for
authenticating the BRSKI-MASA TLS connection MASA certificate. The authenticating the BRSKI-MASA TLS connection MASA certificate. The
registrar uses a different Implicit Trust Anchor database for registrar uses a different Implicit Trust Anchor database for
authenticating the BRSKI-EST TLS connection pledge client authenticating the BRSKI-EST TLS connection pledge client
certificate. Configuration or distribution of these trust anchor certificate. Configuration or distribution of these trust anchor
databases is out-of-scope of this specification. databases is out-of-scope of this specification.
Configuration or distribution of this trust anchor databases is out-
of-scope of this specification. Note that the trust anchors in/
excluded from the database will affect which manufacturers' devices
are acceptable to the registrar as pledges, and can also be used to
limit the set of MASAs that are trusted for enrollment.
2.5.4. Manufacturer Service 2.5.4. Manufacturer Service
The Manufacturer Service provides two logically separate functions: The Manufacturer Service provides two logically separate functions:
the Manufacturer Authorized Signing Authority (MASA) described in the Manufacturer Authorized Signing Authority (MASA) described in
Section 5.5 and Section 5.6, and an ownership tracking/auditing Section 5.5 and Section 5.6, and an ownership tracking/auditing
function described in Section 5.7 and Section 5.8. function described in Section 5.7 and Section 5.8.
2.5.5. Public Key Infrastructure (PKI) 2.5.5. Public Key Infrastructure (PKI)
The Public Key Infrastructure (PKI) administers certificates for the The Public Key Infrastructure (PKI) administers certificates for the
skipping to change at page 38, line 49 skipping to change at page 39, line 7
o Client authentication is automated using Initial Device Identity o Client authentication is automated using Initial Device Identity
(IDevID) as per the EST certificate based client authentication. (IDevID) as per the EST certificate based client authentication.
The subject field's DN encoding MUST include the "serialNumber" The subject field's DN encoding MUST include the "serialNumber"
attribute with the device's unique serial number as explained in attribute with the device's unique serial number as explained in
Section 2.3.1 Section 2.3.1
o The registrar requests and validates the voucher from the MASA. o The registrar requests and validates the voucher from the MASA.
o The registrar forwards the voucher to the pledge when requested. o The registrar forwards the voucher to the pledge when requested.
o The registrar performs log verifications in addition to local o The registrar performs log verifications (described in
authorization checks before accepting optional pledge device Section 5.8.3) in addition to local authorization checks before
enrollment requests. accepting optional pledge device enrollment requests.
5.1. BRSKI-EST TLS establishment details 5.1. BRSKI-EST TLS establishment details
The pledge establishes the TLS connection with the registrar through The pledge establishes the TLS connection with the registrar through
the circuit proxy (see Section 4) but the TLS handshake is with the the circuit proxy (see Section 4) but the TLS handshake is with the
registrar. The BRSKI-EST pledge is the TLS client and the BRSKI-EST registrar. The BRSKI-EST pledge is the TLS client and the BRSKI-EST
registrar is the TLS server. All security associations established registrar is the TLS server. All security associations established
are between the pledge and the registrar regardless of proxy are between the pledge and the registrar regardless of proxy
operations. operations.
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED.
Establishment of the BRSKI-EST TLS connection is as specified in EST Establishment of the BRSKI-EST TLS connection is as specified in EST
[RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates"
[RFC7030] wherein the client is authenticated with the IDevID [RFC7030] wherein the client is authenticated with the IDevID
certificate, and the EST server (the registrar) is provisionally certificate, and the EST server (the registrar) is provisionally
authenticated with an unverified server certificate. Configuration authenticated with an unverified server certificate. Configuration
or distribution of the trust anchor database used for validating the or distribution of the trust anchor database used for validating the
IDevID certificate is out-of-scope of this specification. Note that IDevID certificate is out-of-scope of this specification. Note that
the trust anchors in/excluded from the database will affect which the trust anchors in/excluded from the database will affect which
manufacturers' devices are acceptable to the registrar as pledges, manufacturers' devices are acceptable to the registrar as pledges,
and can also be used to limit the set of MASAs that are trusted for and can also be used to limit the set of MASAs that are trusted for
skipping to change at page 42, line 9 skipping to change at page 42, line 19
5.4. BRSKI-MASA TLS establishment details 5.4. BRSKI-MASA TLS establishment details
The BRSKI-MASA TLS connection is a 'normal' TLS connection The BRSKI-MASA TLS connection is a 'normal' TLS connection
appropriate for HTTPS REST interfaces. The registrar initiates the appropriate for HTTPS REST interfaces. The registrar initiates the
connection and uses the MASA URL obtained as described in connection and uses the MASA URL obtained as described in
Section 2.8. The mechanisms in [RFC6125] SHOULD be used Section 2.8. The mechanisms in [RFC6125] SHOULD be used
authentication of the MASA. Some vendors will establish explicit (or authentication of the MASA. Some vendors will establish explicit (or
private) trust anchors for validating their MASA; this will typically private) trust anchors for validating their MASA; this will typically
done as part of a sales channel integration. done as part of a sales channel integration.
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED.
As described in [RFC7030], the MASA and the registrars SHOULD be As described in [RFC7030], the MASA and the registrars SHOULD be
prepared to support TLS client certificate authentication and/or HTTP prepared to support TLS client certificate authentication and/or HTTP
Basic or Digest authentication. This connection MAY also have no Basic or Digest authentication. This connection MAY also have no
client authentication at all. client authentication at all.
Registars SHOULD permit trust anchors to be pre-configured on a per- Registrars SHOULD permit trust anchors to be pre-configured on a per-
vendor(MASA) basis. Registrars SHOULD include the ability to vendor(MASA) basis. Registrars SHOULD include the ability to
configure a TLS ClientCertificate on a per-MASA basis, or to use no configure a TLS ClientCertificate on a per-MASA basis, or to use no
client certificate. Registrars SHOULD also permit an HTTP Basic and client certificate. Registrars SHOULD also permit an HTTP Basic and
Digest authentication to be configured. Digest authentication to be configured.
The authentication of the BRSKI-MASA connection does not change the The authentication of the BRSKI-MASA connection does not change 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 as described in Section 5.8. to the audit-log as described in Section 5.8.
skipping to change at page 54, line 17 skipping to change at page 55, line 9
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 device selected by the IDevID presented in the request. The with the device selected by the IDevID presented in the request. The
audit log may be abridged by removal of old or repeated values as audit log may be abridged by removal of old or repeated values as
explained below. The returned data is in JSON format ([RFC8259]), explained below. The returned data is in JSON format ([RFC8259]),
and the Content-Type SHOULD be "application/json". For example: and the Content-Type SHOULD be "application/json". For example:
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"<date/time of the entry>", "date":"<date and time as per RFC3339 section 5.6>",
"domainID":"<domainID extracted from voucher-request>", "domainID":"<domainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or NULL)>", "nonce":"<nonce as supplied (or NULL)>",
"assertion":"<the value from the voucher assertion leaf>", "assertion":"<the value from the voucher assertion leaf>",
"truncated":"<the number of domainID entries truncated>" "truncated":"<the number of domainID entries truncated>"
}, },
{ {
"date":"<date/time of the entry>", "date":"<date and time as per RFC3339 section 5.6>",
"domainID":"<anotherDomainID extracted from voucher-request>", "domainID":"<anotherDomainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or NULL)>", "nonce":"<nonce as supplied (or NULL)>",
"assertion":"<the value from the voucher assertion leaf>" "assertion":"<the value from the voucher assertion leaf>"
} }
], ],
"truncation": { "truncation": {
"nonced duplicates": "<total number of entries truncated>", "nonced duplicates": "<total number of entries truncated>",
"nonceless duplicates": "<total number of entries truncated>", "nonceless duplicates": "<total number of entries truncated>",
"arbitrary": "<number of domainID entries removed entirely>" "arbitrary": "<number of domainID entries removed entirely>"
} }
} }
Figure 16: Example of audit-log response Figure 16: Example of audit-log response
The domainID is a binary value calculated SubjectKeyIdentifier The domainID is a binary value calculated SubjectKeyIdentifier
according to Section 5.8.2. It is encoded once in base64 in order to according to Section 5.8.2. It is encoded once in base64 in order to
be transported in this JSON container. be transported in this JSON container.
The date is in [RFC3339] format, which is consistent with typical
JavaScript usage of JSON.
The nonce is a string, as provided in the voucher-request, and used
in the voucher. If no nonce was placed in the resulting voucher,
then a value of null SHOULD be used in preference to omitting the
entry. While the nonce is often created as a base64 encoded random
series of bytes, this should not be assumed.
Distribution of a large log is less than ideal. This structure can Distribution of a large log is less than ideal. This structure can
be optimized as follows: Nonced or Nonceless entries for the same be optimized as follows: Nonced or Nonceless entries for the same
domainID MAY be abridged from the log leaving only the single most domainID MAY be abridged from the log leaving only the single most
recent nonced or nonceless entry for that domainID. In the case of recent nonced or nonceless entry for that domainID. In the case of
truncation the 'event' truncation value SHOULD contain a count of the truncation the 'event' truncation value SHOULD contain a count of the
number of events for this domainID that were omitted. The log SHOULD number of events for this domainID that were omitted. The log SHOULD
NOT be further reduced but there could exist operational situation NOT be further reduced but there could exist operational situation
where maintaining the full log is not possible. In such situations where maintaining the full log is not possible. In such situations
the log MAY be arbitrarily abridged for length, with the number of the log MAY be arbitrarily abridged for length, with the number of
removed entries indicated as 'arbitrary'. removed entries indicated as 'arbitrary'.
skipping to change at page 65, line 4 skipping to change at page 66, line 4
information is reported.) The MASA SHOULD verify the 'prior-signed- information is reported.) The MASA SHOULD verify the 'prior-signed-
voucher-request' information for pledges that support that voucher-request' information for pledges that support that
functionality. This provides a proof-of-proximity check that reduces functionality. This provides a proof-of-proximity check that reduces
the need for ownership verification. the need for ownership verification.
A MASA that practices Trust-on-First-Use (TOFU) for Registrar A MASA that practices Trust-on-First-Use (TOFU) for Registrar
identity may wish to annotate the origin of the connection by IP identity may wish to annotate the origin of the connection by IP
address or netblock, and restrict future use of that identity from address or netblock, and restrict future use of that identity from
other locations. A MASA that does this SHOULD take care to not other locations. A MASA that does this SHOULD take care to not
create nuissance situations for itself when a customer has multiple create nuissance situations for itself when a customer has multiple
registrars, or uses outgoing IPv6 NAT44 connections that change registrars, or uses outgoing IPv4 NAT44 connections that change
frequently. frequently.
7.4.3. Updating or extending voucher trust anchors 7.4.3. Updating or extending voucher trust anchors
A manufacturer could offer a management mechanism that allows the A manufacturer could offer a management mechanism that allows the
list of voucher verification trust anchors to be extended. list of voucher verification trust anchors to be extended.
[I-D.ietf-netconf-keystore] is one such interface that could be [I-D.ietf-netconf-keystore] is one such interface that could be
implemented using YANG. Pretty much any configuration mechanism used implemented using YANG. Pretty much any configuration mechanism used
today could be extended to provide the needed additional update. A today could be extended to provide the needed additional update. A
manufacturer could even decide to install the domain CA trust anchors manufacturer could even decide to install the domain CA trust anchors
skipping to change at page 68, line 14 skipping to change at page 69, line 14
The autonomic control plane (ACP) that is bootstrapped by the BRSKI The autonomic control plane (ACP) that is bootstrapped by the BRSKI
protocol is typically used in medium to large Internet Service protocol is typically used in medium to large Internet Service
Provider organizations. Equivalent enterprises that has significant Provider organizations. Equivalent enterprises that has significant
layer-3 router connectivity also will find significant benefit, layer-3 router connectivity also will find significant benefit,
particularly if the Enterprise has many sites. (A network consisting particularly if the Enterprise has many sites. (A network consisting
of primarily layer-2 is not excluded, but the adjacencies that the of primarily layer-2 is not excluded, but the adjacencies that the
ACP will create and maintain will not reflect the topology until all ACP will create and maintain will not reflect the topology until all
devices participate in the ACP). devices participate in the ACP).
In the ACP, the Join Proxy is found to be proximal because
communication between the pledge and the join proxy is exclusively on
IPv6 Link-Local addresses. The proximity of the Join Proxy to the
Registrar is validated by the Registrar using ANI ACP IPv6 Unique
Local Addresses (ULA). ULAs are not routable over the Internet, so
as long as the Join Proxy is operating correctly the proximity
asssertion is satisfied. Other uses of BRSKI will need make similar
analysis if they use proximity.
As specified in the ANIMA charter, this work "..focuses on As specified in the ANIMA charter, this work "..focuses on
professionally-managed networks." Such a network has an operator and professionally-managed networks." Such a network has an operator and
can do things like install, configure and operate the Registrar can do things like install, configure and operate the Registrar
function. The operator makes purchasing decisions and is aware of function. The operator makes purchasing decisions and is aware of
what manufacturers it expects to see on its network. what manufacturers it expects to see on its network.
Such an operator is also capable of performing bootstrapping of a Such an operator is also capable of performing bootstrapping of a
device using a serial-console (craft console). The zero-touch device using a serial-console (craft console). The zero-touch
mechanism presented in this and the ACP document mechanism presented in this and the ACP document
[I-D.ietf-anima-autonomic-control-plane] represents a significiant [I-D.ietf-anima-autonomic-control-plane] represents a significiant
skipping to change at page 69, line 18 skipping to change at page 70, line 31
Additionally the domainID captures only the unauthenticated subject Additionally the domainID captures only the unauthenticated subject
key identifier of the domain. A privacy sensitive domain could key identifier of the domain. A privacy sensitive domain could
theoretically generate a new domainID for each device being deployed. theoretically generate a new domainID for each device being deployed.
Similarly a privacy sensitive domain would likely purchase devices Similarly a privacy sensitive domain would likely purchase devices
that support proximity assertions from a manufacturer that does not that support proximity assertions from a manufacturer that does not
require sales channel integrations. This would result in a require sales channel integrations. This would result in a
significant level of privacy while maintaining the security significant level of privacy while maintaining the security
characteristics provided by Registrar based audit log inspection. characteristics provided by Registrar based audit log inspection.
10.2. What BRSKI-EST reveals to the registrar 10.2. What BRSKI-EST reveals
During the provisional phase of the BRSKI-EST connection between the During the provisional phase of the BRSKI-EST connection between the
Pledge and the Registrar, each party reveals its certificates to each Pledge and the Registrar, each party reveals its certificates to each
other. For the Pledge, this includes the serialNumber attribute, the other. For the Pledge, this includes the serialNumber attribute, the
MASA URL, and the identity that signed the IDevID certificate. MASA URL, and the identity that signed the IDevID certificate.
TLS 1.2 reveals the certificate identities to on-path observers, TLS 1.2 reveals the certificate identities to on-path observers,
including the Join Proxy. including the Join Proxy.
TLS 1.3 reveals the certificate identities only to the end parties, TLS 1.3 reveals the certificate identities only to the end parties,
but as the connection is provisional, an on-path attacker will see but as the connection is provisional, an on-path attacker (MTIM) can
the certificates. This includes not just malicious attackers, but see the certificates. This includes not just malicious attackers,
also Registrars that are visible to the Pledge, but which are not but also Registrars that are visible to the Pledge, but which are not
part of the the intended domain. part of the the intended domain.
The certificate of the Registrar is rather arbtirary from the point
of view of the BRSKI protocol. As no [RFC6125] validations are
expected to be done, the contents could be easily pseudonymized. Any
device that can see a join proxy would be able to connect to the
Registrar and learn the identity of the network in question. Even if
the contents of the certificate are pseudonymized, it would be
possible to coorelate different connections in different locations
belong to the same entity. This is unlikely to present a significant
privacy concern to ANIMA ACP uses of BRSKI, but may be a concern to
other users of BRSKI.
The certificate of the Pledge could be revealed by a malicious Join
Proxy that performed a MITM attack on the provisional TLS connection.
Such an attacker would be able to reveal the identity of the Pledge
to third parties if it chose to so.
Research into a mechanism to do multi-step, multi-party authenticated
key agreement, incorporating some kind of zero-knowledge proof would
be valuable. Such a mechanism would ideally avoid disclosing
identities until pledge, registrar and MASA agree to the transaction.
Such a mechanism would need to discover the location of the MASA
without knowing the identity of the pledge, or the identity of the
MASA. This part of the problem may be unsolveable.
10.3. What BRSKI-MASA reveals to the manufacturer 10.3. What BRSKI-MASA reveals to the manufacturer
The so-called "call-home" mechanism that occurs as part of the BRSKI- The so-called "call-home" mechanism that occurs as part of the BRSKI-
MASA connection standardizes what has been deemed by some as a MASA connection standardizes what has been deemed by some as a
sinister mechanism for corporate oversight of individuals. sinister mechanism for corporate oversight of individuals.
([livingwithIoT] and [IoTstrangeThings] for a small sample). ([livingwithIoT] and [IoTstrangeThings] for a small sample).
As the Autonomic Control Plane (ACP) usage of BRSKI is not targeted As the Autonomic Control Plane (ACP) usage of BRSKI is not targeted
at individual usage of IoT devices, but rather at the Enterprise and at individual usage of IoT devices, but rather at the Enterprise and
ISP creation of networks in a zero-touch fashion, the "call-home" ISP creation of networks in a zero-touch fashion, the "call-home"
represents a different kind of concern. represents a different kind of concern.
It needs to be re-iterated that the BRSKI-MASA mechanism only occurs It needs to be re-iterated that the BRSKI-MASA mechanism only occurs
once during the commissioning of the device. It is well defined, and once during the commissioning of the device. It is well defined, and
although encrypted with TLS, it could in theory be made auditable as although encrypted with TLS, it could in theory be made auditable as
the contents are well defined. This connection does not occur when the contents are well defined. This connection does not occur when
the device powers on or is restarted for normal routines. It is the device powers on or is restarted for normal routines. (It is
conceivable that a device could be forced to go through a full conceivable, but remarkably unusual, that a device could be forced to
factory reset during an exceptional firmware update situation, after go through a full factory reset during an exceptional firmware update
which enrollment would have be repeated. situation, after which enrollment would have be repeated, and a new
connection would occur)
The BRSKI call-home mechanism is mediated via the owner's Registrar, The BRSKI call-home mechanism is mediated via the owner's Registrar,
and the information that is transmitted is directly auditable by the and the information that is transmitted is directly auditable by the
device owner. This is in stark contrast to many "call-home" device owner. This is in stark contrast to many "call-home"
protocols where the device autonomously calls home and uses an protocols where the device autonomously calls home and uses an
undocumented protocol. undocumented protocol.
While the contents of the signed part of the pledge voucher request While the contents of the signed part of the pledge voucher request
can not be changed, they are not encrypted at the registrar. The can not be changed, they are not encrypted at the registrar. The
ability to audit the messages by the owner of the network a mechanism ability to audit the messages by the owner of the network a mechanism
to defend against exfiltration of data by a nefarious pledge. Both to defend against exfiltration of data by a nefarious pledge. Both
are, to re-iterate, encrypted by TLS while in transit. are, to re-iterate, encrypted by TLS while in transit.
The BRSKI-MASA exchange reveals the following information to the The BRSKI-MASA exchange reveals the following information to the
manufacturer: manufacturer:
o the identity of the device being enrolled (down to the serial- o the identity of the device being enrolled. This is revealed by
number!). transmission of a signed voucher-request containing the serial-
number. The manufacturer can usually link the serial number to a
device model.
o an identity of the domain owner in the form of the domain trust o an identity of the domain owner in the form of the domain trust
anchor. However, this is not a global PKI anchored name within anchor. However, this is not a global PKI anchored name within
the WebPKI, so this identity could be pseudonymous. If there is the WebPKI, so this identity could be pseudonymous. If there is
sales channel integration, then the MASA will have authenticated sales channel integration, then the MASA will have authenticated
the domain owner, either via pinned certificate, or perhaps the domain owner, either via pinned certificate, or perhaps
another HTTP authentication method, as per Section 5.5.4. another HTTP authentication method, as per Section 5.5.4.
o the time the device is activated, o the time the device is activated,
skipping to change at page 70, line 49 skipping to change at page 72, line 40
attacker who observes the connection definitely may conclude that attacker who observes the connection definitely may conclude that
the given enterprise/ISP is a customer of the particular equipment the given enterprise/ISP is a customer of the particular equipment
vendor. The precise model that is being enrolled will remain vendor. The precise model that is being enrolled will remain
private. private.
Based upon the above information, the manufacturer is able to track a Based upon the above information, the manufacturer is able to track a
specific device from pseudonymous domain identity to the next specific device from pseudonymous domain identity to the next
pseudonymous domain identity. If there is sales-channel integration, pseudonymous domain identity. If there is sales-channel integration,
then the identities are not pseudonymous. then the identities are not pseudonymous.
The above situation is to be distinguished from a residential/ The manufacturer knows the IP address of the Registrar, but it can
individual person who registers a device from a manufacturer: that an not see the IP address of the device itself. The manufacturer can
enterprise/ISP purchases routing products is hardly worth mentioning. not track the device to a detailed physical or network location, only
to the the location of the Registrar itself. That is likely to be at
the Enterprise or ISPs headquarters.
Deviations from a historical trend or an establish baseline would, The above situation is to be distinguished from a residential/
however, be notable. individual person who registers a device from a manufacturer.
Individuals do not tend to have multiple offices, and their registrar
is likely on the same network as the device. A manufacturer that
sells switching/routing products to enterprises should hardly be
surprised if additional purchases switching/routing products are
purchased. Deviations from a historical trend or an establish
baseline would, however, be notable.
The situation is not improved by the enterprise/ISP using The situation is not improved by the enterprise/ISP using
anonymization services such as ToR [Dingledine2004], as a TLS 1.2 anonymization services such as ToR [Dingledine2004], as a TLS 1.2
connection will reveal the ClientCertificate used, clearly connection will reveal the ClientCertificate used, clearly
identifying the enterprise/ISP involved. TLS 1.3 is better in this identifying the enterprise/ISP involved. TLS 1.3 is better in this
regard, but an active attacker can still discover the parties regard, but an active attacker can still discover the parties
involved by performing a Man-In-The-Middle-Attack on the first involved by performing a Man-In-The-Middle-Attack on the first
attempt (breaking/killing it with a TCP RST), and then letting attempt (breaking/killing it with a TCP RST), and then letting
subsequent connection pass through. subsequent connection pass through.
skipping to change at page 74, line 19 skipping to change at page 76, line 19
may wish to consider replacement of the IDevID as an indication that may wish to consider replacement of the IDevID as an indication that
the device's warrantee is terminated. For others, the privacy the device's warrantee is terminated. For others, the privacy
requirements of some deployments might consider this a standard requirements of some deployments might consider this a standard
operating practice. operating practice.
As discussed at the end of Section 5.8.1, new work could be done to As discussed at the end of Section 5.8.1, new work could be done to
use a distributed consensus technology for the audit log. This would use a distributed consensus technology for the audit log. This would
permit the audit log to continue to be useful, even when there is a permit the audit log to continue to be useful, even when there is a
chain of MASA due to changes of ownership. chain of MASA due to changes of ownership.
10.7. Death of a manufacturer
A common concern has been that a manufacturer could go out of
business, leaving owners of devices unable to get new vouchers for
existing products. Said products might be previous deployed and need
to be re-initialized, purchased used, or just kept in a warehouse as
long-term spares.
The MASA was named the Manufacturer *Authorized* Signing Authority to
emphasize that it need not be the manufacturer itself that performs
this. It is anticipated that specialist service providers will come
to exist that deal with the creation of vouchers in much the same way
that many companies have outsourced email, advertising and janitorial
services.
Further, it is expected that as part of any service agreement that
the manufacturer would arrange to escrow appropriate private keys
such that a MASA service could be provided by a third party. This
has routinely been done for source code for decades.
11. Security Considerations 11. Security Considerations
This document details a protocol for bootstrapping that balances This document details a protocol for bootstrapping that balances
operational concerns against security concerns. As detailed in the operational concerns against security concerns. As detailed in the
introduction, and touched on again in Section 7, the protocol allows introduction, and touched on again in Section 7, the protocol allows
for reduced security modes. These attempt to deliver additional for reduced security modes. These attempt to deliver additional
control to the local administrator and owner in cases where less control to the local administrator and owner in cases where less
security provides operational benefits. This section goes into more security provides operational benefits. This section goes into more
detail about a variety of specific considerations. detail about a variety of specific considerations.
skipping to change at page 83, line 46 skipping to change at page 86, line 24
[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>.
[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>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[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,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
skipping to change at page 87, line 13 skipping to change at page 89, line 36
<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-12 (work in progress), June 2019. est-13 (work in progress), September 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-05 (work in progress), July ietf-anima-constrained-voucher-05 (work in progress), July
2019. 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
skipping to change at page 88, line 11 skipping to change at page 90, line 36
privacy update (accessed 2018-12-02)", March 2017, privacy update (accessed 2018-12-02)", March 2017,
<https://www.welivesecurity.com/2017/03/03/ <https://www.welivesecurity.com/2017/03/03/
internet-of-things-security-privacy-iot-update/>. internet-of-things-security-privacy-iot-update/>.
[livingwithIoT] [livingwithIoT]
"What is it actually like to live in a house filled with "What is it actually like to live in a house filled with
IoT devices? (accessed 2018-12-02)", February 2018, IoT devices? (accessed 2018-12-02)", February 2018,
<https://www.siliconrepublic.com/machines/ <https://www.siliconrepublic.com/machines/
iot-smart-devices-reality>. iot-smart-devices-reality>.
[openssl] "OpenSSL X509 utility", September 2019,
<https://www.openssl.org/docs/man1.1.1/man1/
openssl-x509.html/>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999, RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>. <https://www.rfc-editor.org/info/rfc2663>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/info/rfc5209>. <https://www.rfc-editor.org/info/rfc5209>.
skipping to change at page 96, line 33 skipping to change at page 99, line 33
zj0DAQcDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8 zj0DAQcDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8
KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6T6OBhzCBhDAdBgNVHQ4EFgQUj8KYdUoE KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6T6OBhzCBhDAdBgNVHQ4EFgQUj8KYdUoE
OvJ0kcOIbjEWwgWdDYkwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S OvJ0kcOIbjEWwgWdDYkwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S
AaATDBEwMC1EMC1FNS0wMi0wMC0yRDArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l AaATDBEwMC1EMC1FNS0wMi0wMC0yRDArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l
eWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNnADBkAjAmvMjmNgjypDhc eWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNnADBkAjAmvMjmNgjypDhc
fynMV3kMuIpSKrYzRWr4g3PtTwXDsAe0oitTTj4QtU1bajhOfTkCMGMNbsW2Q41F fynMV3kMuIpSKrYzRWr4g3PtTwXDsAe0oitTTj4QtU1bajhOfTkCMGMNbsW2Q41F
z9t6PDVdtOKabBbAP1RVoFTlDQuO9nmLzb5kU+cUqCtPRFZBUXP3kg== z9t6PDVdtOKabBbAP1RVoFTlDQuO9nmLzb5kU+cUqCtPRFZBUXP3kg==
-----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. There is a second Custom Extension that the extensions can be seen. This was version 1.1.1c of the
is included to provided to contain the EUI48/EUI64 that the pledge [openssl] library and utility. There is a second Custom Extension is
will configure as it's layer-2 address (this is non-normative). included to provided to contain the EUI48/EUI64 that the pledge will
configure as it's layer-2 address (this is non-normative).
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 166573225 (0x9edb4a9) 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: Apr 24 02:16:58 2019 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
 End of changes. 44 change blocks. 
119 lines changed or deleted 218 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/