draft-ietf-anima-bootstrapping-keyinfra-17.txt   draft-ietf-anima-bootstrapping-keyinfra-18.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: May 9, 2019 Sandelman Expires: July 21, 2019 Sandelman
M. Behringer M. Behringer
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
K. Watsen K. Watsen
Juniper Networks Juniper Networks
November 5, 2018 January 17, 2019
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-17 draft-ietf-anima-bootstrapping-keyinfra-18
Abstract Abstract
This document specifies automated bootstrapping of a remote secure This document specifies automated bootstrapping of an Autonomic
key infrastructure (BRSKI) using manufacturer installed X.509 Control Plane. To do this a remote secure key infrastructure (BRSKI)
certificate, in combination with a manufacturer's authorizing is created using manufacturer installed X.509 certificate, in
service, both online and offline. Bootstrapping a new device can combination with a manufacturer's authorizing service, both online
occur using a routable address and a cloud service, or using only and offline. Bootstrapping a new device can occur using a routable
link-local connectivity, or on limited/disconnected networks. address and a cloud service, or using only link-local connectivity,
Support for lower security models, including devices with minimal or on limited/disconnected networks. Support for lower security
identity, is described for legacy reasons but not encouraged. models, including devices with minimal identity, is described for
Bootstrapping is complete when the cryptographic identity of the new legacy reasons but not encouraged. Bootstrapping is complete when
key infrastructure is successfully deployed to the device but the the cryptographic identity of the new key infrastructure is
established secure connection can be used to deploy a locally issued successfully deployed to the device but the established secure
certificate to the device as well. connection can be used to deploy a locally issued certificate to the
device as well.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 9, 2019. This Internet-Draft will expire on July 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 5 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 9 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 10
1.3.1. Support environment . . . . . . . . . . . . . . . . . 9 1.3.1. Support environment . . . . . . . . . . . . . . . . . 10
1.3.2. Constrained environments . . . . . . . . . . . . . . 10 1.3.2. Constrained environments . . . . . . . . . . . . . . 10
1.3.3. Network Access Controls . . . . . . . . . . . . . . . 11 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 11
1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 11 1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 11
1.4. Leveraging the new key infrastructure / next steps . . . 11 1.4. Leveraging the new key infrastructure / next steps . . . 11
1.5. Requirements for Autonomic Network Infrastructure (ANI) 1.5. Requirements for Autonomic Network Infrastructure (ANI)
devices . . . . . . . . . . . . . . . . . . . . . . . . . 11 devices . . . . . . . . . . . . . . . . . . . . . . . . . 12
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 12 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 12
2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 14 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 14
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 15 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 15
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 16 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 16
2.3.1. Identification of the Pledge . . . . . . . . . . . . 16 2.3.1. Identification of the Pledge . . . . . . . . . . . . 16
2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 17 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 17
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 18 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 19
2.5. Architectural Components . . . . . . . . . . . . . . . . 20 2.5. Architectural Components . . . . . . . . . . . . . . . . 21
2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 20 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 21
2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 20 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 21
2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 20 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 21
2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 20 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 21
2.6. Certificate Time Validation . . . . . . . . . . . . . . . 21 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 22
2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 21 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 22
2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 23 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24
2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 23 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 24
2.8. Determining the MASA to contact . . . . . . . . . . . . . 23 2.8. Determining the MASA to contact . . . . . . . . . . . . . 24
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 24 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 25
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 25 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 26
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28
4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 30 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 31
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 31 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 32
4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 32 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 33
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 33 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 34
4.3. Proxy discovery of Registrar . . . . . . . . . . . . . . 33 4.3. Proxy discovery of Registrar . . . . . . . . . . . . . . 34
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 34 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 35
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 37
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 36 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 37
5.3. Registrar Authorization of 5.3. Registrar Authorization of
Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 38 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 38 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 39
5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 39 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 40
5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 40 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 41
5.5.2. MASA verification of voucher-request signature 5.5.2. MASA verification of voucher-request signature
consistency . . . . . . . . . . . . . . . . . . . . . 40 consistency . . . . . . . . . . . . . . . . . . . . . 41
5.5.3. MASA authentication of registrar (certificate) . . . 41 5.5.3. MASA authentication of registrar (certificate) . . . 42
5.5.4. MASA revocation checking of registrar (certificate) . 41 5.5.4. MASA revocation checking of registrar (certificate) . 42
5.5.5. MASA verification of pledge prior-signed-voucher- 5.5.5. MASA verification of pledge prior-signed-voucher-
request . . . . . . . . . . . . . . . . . . . . . . . 41 request . . . . . . . . . . . . . . . . . . . . . . . 42
5.5.6. MASA pinning of registrar . . . . . . . . . . . . . . 42 5.5.6. MASA pinning of registrar . . . . . . . . . . . . . . 43
5.5.7. MASA nonce handling . . . . . . . . . . . . . . . . . 42 5.5.7. MASA nonce handling . . . . . . . . . . . . . . . . . 43
5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 42 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 43
5.6.1. Pledge voucher verification . . . . . . . . . . . . . 45 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 46
5.6.2. Pledge authentication of provisional TLS connection . 45 5.6.2. Pledge authentication of provisional TLS connection . 46
5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 46 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 47
5.8. Registrar audit log request . . . . . . . . . . . . . . . 47 5.8. Registrar audit log request . . . . . . . . . . . . . . . 48
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 48 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 49
5.8.2. Registrar audit log verification . . . . . . . . . . 49 5.8.2. Registrar audit log verification . . . . . . . . . . 50
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 50 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 51
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 51 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 52
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 52
5.9.3. EST Client Certificate Request . . . . . . . . . . . 52 5.9.3. EST Client Certificate Request . . . . . . . . . . . 53
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 53
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 53 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 54
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 54
6. Reduced security operational modes . . . . . . . . . . . . . 54 6. Reduced security operational modes . . . . . . . . . . . . . 55
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 54 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 55
6.2. Pledge security reductions . . . . . . . . . . . . . . . 55 6.2. Pledge security reductions . . . . . . . . . . . . . . . 56
6.3. Registrar security reductions . . . . . . . . . . . . . . 55 6.3. Registrar security reductions . . . . . . . . . . . . . . 56
6.4. MASA security reductions . . . . . . . . . . . . . . . . 56 6.4. MASA security reductions . . . . . . . . . . . . . . . . 57
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
7.1. Well-known EST registration . . . . . . . . . . . . . . . 57 7.1. Well-known EST registration . . . . . . . . . . . . . . . 58
7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 57 7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 58
7.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 57 7.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 58
7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 58 7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 59
7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 58 7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 59
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 58 8. Applicability to the Autonomic
8.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 58 Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 59
9. Security Considerations . . . . . . . . . . . . . . . . . . . 59 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60
9.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 60 9.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 60
9.2. Freshness in Voucher-Requests . . . . . . . . . . . . . . 60 9.2. Used, Stolen or Grey Market equipment . . . . . . . . . . 61
9.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 62 9.2.1. What BRSKI-MASA reveals to the manufacturer . . . . . 61
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 9.2.2. Manufacturers and Used or Stolen Equipment . . . . . 63
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.2.3. Manufacturers and Grey market equipment . . . . . . . 64
11.1. Normative References . . . . . . . . . . . . . . . . . . 63 9.2.4. Some mitigations for meddling by manufacturers . . . 65
11.2. Informative References . . . . . . . . . . . . . . . . . 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 66
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 68 10.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 67
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 68 10.2. Freshness in Voucher-Requests . . . . . . . . . . . . . 67
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 68 10.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 69
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70
Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 70
D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 71 12.2. Informative References . . . . . . . . . . . . . . . . . 72
D.1.1. MASA key pair for voucher signatures . . . . . . . . 71 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 75
D.1.2. Manufacturer key pair for IDevID signatures . . . . . 71 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 75
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 72 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 76
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 74 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 76
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 75 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 77
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 75 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 79
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 81 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 79
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 87 D.1.1. MASA key pair for voucher signatures . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 79
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 80
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 82
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 84
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 84
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 90
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
1. Introduction 1. Introduction
BRSKI provides a solution for secure zero-touch (automated) bootstrap BRSKI provides a solution for secure zero-touch (automated) bootstrap
of virgin (untouched) devices that are called pledges in this of virgin (untouched) devices that are called pledges in this
document. These pledges need to discover (or be discovered by) an document.
This document primarily provides for the needs of the ISP and
Enterprise focused ANIMA Autonomic Control Plane (ACP)
[I-D.ietf-anima-autonomic-control-plane]. Other users of the BRSKI
protocol will need to provide separate applicability statements that
include privacy and security considerations appropriate to that
deployment. Section Section 8 explains the details applicability for
this the ACP usage.
This document describes how pledges discover (or be discovered by) an
element of the network domain to which the pledge belongs to perform element of the network domain to which the pledge belongs to perform
the bootstrap. This element (device) is called the registrar. the bootstrap. This element (device) is called the registrar.
Before any other operation, pledge and registrar need to establish Before any other operation, pledge and registrar need to establish
mutual trust: mutual trust:
1. Registrar authenticating the pledge: "Who is this device? What 1. Registrar authenticating the pledge: "Who is this device? What
is its identity?" is its identity?"
2. Registrar authorizing the pledge: "Is it mine? Do I want it? 2. Registrar authorizing the pledge: "Is it mine? Do I want it?
What are the chances it has been compromised?" What are the chances it has been compromised?"
skipping to change at page 17, line 24 skipping to change at page 17, line 24
rather than the device's serial number. If both fields are rather than the device's serial number. If both fields are
present, then the subject field takes precedence. present, then the subject field takes precedence.
and they are used as follows by the pledge to build the "serial- and they are used as follows by the pledge to build the "serial-
number" that is placed in the voucher-request. In order to build it, number" that is placed in the voucher-request. In order to build it,
the fields need to be converted into a serial-number of "type the fields need to be converted into a serial-number of "type
string". The following methods are used depending on the first string". The following methods are used depending on the first
available IDevID certificate field (attempted in this order): available IDevID certificate field (attempted in this order):
1. [RFC4519] section 2.31 provides an example ("WI-3005") of the 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the
Distinguished Name "serialNumber" attribute, formatted according Distinguished Name "serialNumber" attribute. [RFC4514] indicates
to RFC4514 rules. this is a printable string so no encoding is necessary.
2. The HardwareModuleName hwSerialNum OCTET STRING, base64 encoded. 2. The HardwareModuleName hwSerialNum OCTET STRING. This value is
base64 encoded to convert it to a printable string format.
The above process to locate the serial-number MUST be performed by
the pledge when filling out the voucher-request. Signed voucher-
requests are always passed up to the MASA, and the connection between
the serial-number in the voucher-request and the serial number in the
IDevID certificate.
As explained in Section 5.5 the Registrar MUST extract the serial-
number again itself from the pledge's TLS certificate. It may
consult the serial-number in the pledge-request if there are any
possible confusion about the source of the serial-number (hwSerialNum
vs serialNumber).
2.3.2. MASA URI extension 2.3.2. MASA URI extension
The following newly defined field SHOULD be in the PKIX IDevID The following newly defined field SHOULD be in the PKIX IDevID
certificate: A PKIX non-critical certificate extension that contains certificate: A PKIX non-critical certificate extension that contains
a single Uniform Resource Identifier (URI) that points to an on-line a single Uniform Resource Identifier (URI) that points to an on-line
Manufacturer Authorized Signing Authority. The URI is represented as Manufacturer Authorized Signing Authority. The URI is represented as
described in Section 7.4 of [RFC5280]. described in Section 7.4 of [RFC5280].
Any Internationalized Resource Identifiers (IRIs) MUST be mapped to Any Internationalized Resource Identifiers (IRIs) MUST be mapped to
skipping to change at page 22, line 28 skipping to change at page 23, line 28
can not in general be validated as the pledge has no certain real can not in general be validated as the pledge has no certain real
time clock. There are some reasonable assumptions that can be time clock. There are some reasonable assumptions that can be
made: the voucher's expires-on time can not be prior to the made: the voucher's expires-on time can not be prior to the
pledge's current reasonable date. For nonceless vouchers, the pledge's current reasonable date. For nonceless vouchers, the
voucher's created-on time COULD be earlier if the as well if a voucher's created-on time COULD be earlier if the as well if a
long-lived voucher was obtained some time in the past, and the long-lived voucher was obtained some time in the past, and the
pledge has since gone through a firmware update and factory reset. pledge has since gone through a firmware update and factory reset.
o If the voucher contains a nonce then the pledge MUST confirm the o If the voucher contains a nonce then the pledge MUST confirm the
nonce matches the original pledge voucher-request. This ensures nonce matches the original pledge voucher-request. This ensures
the voucher is fresh. See / (Section 5.2). In that case, the the voucher is fresh. See Section 5.2. In that case, the
voucher's created-on date MUST NOT be prior to the pledge's voucher's created-on date MUST NOT be prior to the pledge's
current reasonable date. In addition, when there is a valid current reasonable date. In addition, when there is a valid
nonce, the current reasonable date MAY be incremented to that of nonce, the current reasonable date MAY be incremented to that of
the CMS signingTime. the CMS signingTime.
o Once the voucher is accepted the validity period of the pinned- o Once the voucher is accepted the validity period of the pinned-
domain-cert in the voucher now serves as a valid time window. As domain-cert in the voucher now serves as a valid time window. As
explained in Section 5.5.4, the MASA has checked the registrar's explained in Section 5.5.4, the MASA has checked the registrar's
certificate against real clocks , the endorsement of the MASA certificate against real clocks , the endorsement of the MASA
allows the pledge to treat the notBefore and notAfter dates as allows the pledge to treat the notBefore and notAfter dates as
skipping to change at page 25, line 8 skipping to change at page 26, line 8
does not provide a mechanism for the registrar to learn that in an does not provide a mechanism for the registrar to learn that in an
automated fashion. Typically this will be done via scanning of bar- automated fashion. Typically this will be done via scanning of bar-
code or QR-code on packaging, or via some sales channel integration. code or QR-code on packaging, or via some sales channel integration.
Unless otherwise signaled (outside the voucher-request artifact), the Unless otherwise signaled (outside the voucher-request artifact), the
signing structure is as defined for vouchers, see [RFC8366]. signing structure is as defined for vouchers, see [RFC8366].
3.1. Tree Diagram 3.1. Tree Diagram
The following tree diagram illustrates a high-level view of a The following tree diagram illustrates a high-level view of a
voucher-request document. The notation used in this diagram is voucher-request document. The voucher-request builds upon the
described in [RFC8366]. Each node in the diagram is fully described voucher artifact described in [RFC8366]. The tree diagram is
described in [RFC8340]. Each node in the diagram is fully described
by the YANG module in Section 3.3. Please review the YANG module for by the YANG module in Section 3.3. Please review the YANG module for
a detailed description of the voucher-request format. a detailed description of the voucher-request format.
module: ietf-voucher-request module: ietf-voucher-request
grouping voucher-request-grouping grouping voucher-request-grouping
+-- voucher +-- voucher
+-- created-on? yang:date-and-time +-- created-on? yang:date-and-time
+-- expires-on? yang:date-and-time +-- expires-on? yang:date-and-time
+-- assertion enumeration +-- assertion enumeration
skipping to change at page 38, line 40 skipping to change at page 39, line 40
voucher to the pledge as described in Section 5.6. voucher to the pledge as described in Section 5.6.
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 Section 2.8 connection and uses the MASA URL obtained as described in Section 2.8
for [RFC6125] authentication of the MASA. for [RFC6125] authentication of the MASA.
The primary method of registrar "authentication" by the MASA is The primary method of registrar "authentication" by the MASA is
detailed in Section 5.5. As detailed in Section 9 the MASA might detailed in Section 5.5. As detailed in Section 10 the MASA might
find it necessary to request additional registrar authentication. find it necessary to request additional registrar authentication.
The MASA and the registrars SHOULD be prepared to support TLS client The MASA and the registrars SHOULD be prepared to support TLS client
certificate authentication and/or HTTP Basic or Digest authentication certificate authentication and/or HTTP Basic or Digest authentication
as described in RFC7030 for EST clients. This connection MAY also as described in RFC7030 for EST clients. This connection MAY also
have no client authentication at all (Section 6.4) have no client authentication at all (Section 6.4)
The authentication of the BRSKI-MASA connection does not affect the The authentication of the BRSKI-MASA connection does not affect the
voucher-request process, as voucher-requests are already signed by voucher-request process, as voucher-requests are already signed by
the registrar. Instead, this authentication provides access control the registrar. Instead, this authentication provides access control
skipping to change at page 48, line 19 skipping to change at page 49, line 19
application/voucher-cms+json The request is a "YANG-defined JSON application/voucher-cms+json The request is a "YANG-defined JSON
document that has been signed using a CMS structure" as described document that has been signed using a CMS structure" as described
in Section 3 using the JSON encoded described in [RFC7951]. The in Section 3 using the JSON encoded described in [RFC7951]. The
registrar MUST sign the request. The entire registrar certificate registrar MUST sign the request. The entire registrar certificate
chain, up to and including the Domain CA, MUST be included in the chain, up to and including the Domain CA, MUST be included in the
CMS structure. CMS structure.
5.8.1. MASA audit log response 5.8.1. MASA audit log response
A log data file is returned consisting of all log entries. The A log data file is returned consisting of all log entries associated
returned data is in JSON format ([RFC7951]), and the Content-Type with the the device selected by the IDevID presented in the request.
SHOULD be "application/json". For example: The audit log may be truncated of old or repeated values as explained
below. The returned data is in JSON format ([RFC7951]), and the
Content-Type SHOULD be "application/json". For example:
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"<date/time of the entry>", "date":"<date/time of the entry>",
"domainID":"<domainID extracted from voucher-request>", "domainID":"<domainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or the exact string 'NULL')>" "nonce":"<any nonce if supplied (or the exact string '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>"
skipping to change at page 54, line 18 skipping to change at page 55, line 18
operational modes for support specific use cases. The following operational modes for support specific use cases. The following
sections detail specific ways that the pledge, registrar and MASA can sections detail specific ways that the pledge, registrar and MASA can
be configured to run in a less secure mode for the indicated reasons. be configured to run in a less secure mode for the indicated reasons.
This section is considered non-normative: use suggested methods MUST This section is considered non-normative: use suggested methods MUST
be detailed in specific profiles of BRSKI. This is the subject for be detailed in specific profiles of BRSKI. This is the subject for
future work. future work.
6.1. Trust Model 6.1. Trust Model
This section explains the trust relationships detailed in
Section 2.4:
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| Pledge | | Join | | Domain | |Manufacturer| | Pledge | | Join | | Domain | |Manufacturer|
| | | Proxy | | Registrar | | Service | | | | Proxy | | Registrar | | Service |
| | | | | | | (Internet) | | | | | | | | (Internet) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
Figure 10 Figure 10
Pledge: The pledge could be compromised and providing an attack Pledge: The pledge could be compromised and providing an attack
vector for malware. The entity is trusted to only imprint using vector for malware. The entity is trusted to only imprint using
skipping to change at page 57, line 40 skipping to change at page 58, line 40
o add /.well-known/est/requestvoucher (see Section 5.5 ) o add /.well-known/est/requestvoucher (see Section 5.5 )
o add /.well-known/est/requestauditlog (see Section 5.7) o add /.well-known/est/requestauditlog (see Section 5.7)
7.2. PKIX Registry 7.2. PKIX Registry
IANA is requested to register the following: IANA is requested to register the following:
This document requests a number for id-mod-MASAURLExtn2016(TBD) from This document requests a number for id-mod-MASAURLExtn2016(TBD) from
the pkix(7) id-mod(0) Registry. [[EDNOTE: fix names]] the pkix(7) id-mod(0) Registry.
This document requests a number from the id-pe registry for id-pe- This document requests a number from the id-pe registry (SMI Security
masa-url. XXX for PKIX Certificate Extension) for id-pe-masa-url.
7.3. Pledge BRSKI Status Telemetry 7.3. Pledge BRSKI Status Telemetry
IANA is requested to create a new Registry entitled: "BRSKI IANA is requested to create a new Registry entitled: "BRSKI
Parameters", and within that Registry to create a table called: Parameters", and within that Registry to create a table called:
"Pledge BRSKI Status Telemetry Attributes". New items can be added "Pledge BRSKI Status Telemetry Attributes". New items can be added
using the Specification Required. The following items are to be in using the Specification Required. The following items are to be in
the initial registration, with this document (Section 5.7) as the the initial registration, with this document (Section 5.7) as the
reference: reference:
skipping to change at page 58, line 22 skipping to change at page 59, line 22
o reason-context o reason-context
7.4. DNS Service Names 7.4. DNS Service Names
IANA is requested to register the following Service Names: IANA is requested to register the following Service Names:
Service Name: _brski-proxy Service Name: _brski-proxy
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>. Assignee: IESG <iesg@ietf.org>.
Contact: IETF Chair <chair@ietf.org> Contact: IESG <iesg@ietf.org>
Description: The Bootstrapping Remote Secure Key Description: The Bootstrapping Remote Secure Key
Infrastructures Proxy Infrastructures Proxy
Reference: [This document] Reference: [This document]
Service Name: _brski-registrar Service Name: _brski-registrar
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>. Assignee: IESG <iesg@ietf.org>.
Contact: IETF Chair <chair@ietf.org> Contact: IESG <iesg@ietf.org>
Description: The Bootstrapping Remote Secure Key Description: The Bootstrapping Remote Secure Key
Infrastructures Registrar Infrastructures Registrar
Reference: [This document] Reference: [This document]
7.5. MUD File Extension for the MASA 7.5. MUD File Extension for the MASA
The IANA is requested to list the name "masa" in the MUD extensions The IANA is requested to list the name "masa" in the MUD extensions
registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in
Appendix C. Appendix C.
8. Privacy Considerations 8. Applicability to the Autonomic Control Plane
8.1. MASA audit log This document provides a solution to the requirements for secure
bootstrap set out in Using an Autonomic Control Plane for Stable
Connectivity of Network Operations, Administration, and Maintenance
[RFC8368], A Reference Model for Autonomic Networking
[I-D.ietf-anima-reference-model] and specifically the An Autonomic
Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section
3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and
Network).
The protocol described in this document has appeal in a number of
other non-ANIMA use cases. Such uses of the protocol will be
deploying into other environments with different tradeoffs of
privacy, security, reliability and autonomy from manufacturers. As
such those use cases will need to provide their own applicability
statements, and will need to address unique privacy and security
considerations for the environments in which they are used.
The autonomic control plane that this document provides bootstrap for
is typically a medium to large Internet Service Provider
organization, or an equivalent Enterprise that has signficant layer-3
router connectivity. (A network consistenting of primarily layer-2
is not excluded, but the adjacencies that the ACP will create and
maintain will not reflect the topology until all devices participate
in the ACP).
As specified in the ANIMA charter, this work "..focuses on
professionally-managed networks." Such a network has an operator and
can do things like like install, configure and operate the Registrar
function. The operator makes purchasing decisions and is aware of
what manufacturers it expects to see on it's network.
Such an operator also is capable of performing the traditional (craft
serial-console) based bootstrap of devices. The zero-touch mechanism
presented in this and the ACP document represents a signficiant
efficiency: in particular it reduces the need to put senior experts
on airplanes to configure devices in person. There is a recognition
as the technology evolves that not every situation may work out, and
occasionally a human still still have to visit.
The BRSKI protocol is going into environments where there have
already been quite a number of vendor proprietary management systems.
Those are not expected to go away quickly, but rather to leverage the
secure credentials that are provisioned by BRSKI. The connectivity
requirements of said management systems are provided by the ACP.
9. Privacy Considerations
9.1. MASA audit log
The MASA audit log includes a hash of the domainID for each Registrar The MASA audit log includes a hash of the domainID for each Registrar
a voucher has been issued to. This information is closely related to a voucher has been issued to. This information is closely related to
the actual domain identity, especially when paired with the anti-DDoS the actual domain identity, especially when paired with the anti-DDoS
authentication information the MASA might collect. This could authentication information the MASA might collect. This could
provide sufficient information for the MASA service to build a provide sufficient information for the MASA service to build a
detailed understanding the devices that have been provisioned within detailed understanding the devices that have been provisioned within
a domain. a domain.
There are a number of design choices that mitigate this risk. The There are a number of design choices that mitigate this risk. The
skipping to change at page 59, line 18 skipping to change at page 61, line 18
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.
9. Security Considerations 9.2. Used, Stolen or Grey Market equipment
9.2.1. What BRSKI-MASA reveals to the manufacturer
The so-called "call-home" mechanism that occurs as part of the BRSKI-
MASA connection standardizes what has been deemed by some as a
sinister mechanism for corporate oversight of individuals.
([livingwithIoT] and [IoTstrangeThings] for a small sample).
As the Autonomic Control Plane (ACP) usage of BRSKI is not targetted
at individual usage of IoT devices, but rather at the Enterprise and
ISP creation of networks in a zero-touch fashion, the "call-home"
represents a different kind of concern.
First, it needs to be re-iterated that the BRSKI-MASA mechanism only
occurs once during the comissioning of the device. It is well
defined, and although encrypted with TLS, it could in theory be made
auditable as the contents are well defined.
This connection does not occur when the device powers on or is
restarted for normal routines. It is possible with low-quality
implementations that it might occur after certain firmware upgrades,
for instance if the upgrade requires repartitoning of firmware space
and this affects the credential storage. The usage of a Trusted
Platform Module (TPM) to store credentials should completely
eliminate this fault, however. Therefore this situation is clearly a
quality of implementation issue, and even in the worse case, it
results in additional enrollments being recorded when the significant
firmware update occurs.
(Some manufacturers might regard such an additional call-home a
significant feature as it might tell them how many of their customers
have performed this major upgrade, and therefore how many are still
vulnerable to some serious issue)
Second, the BRSKI call-home mechanism is mediated via the owner's
Registrar, and the information that is transmitted is directly
auditable by the device owner. This is in stark constrast to many
"call-home" protocols where the device autonomously calls home and
uses an undocumented protocol. While the contents of the signed part
of the pledge voucher request can not be changed, they are not
encrypted at the registrar. The contents of an unsigned voucher
request are, however, completely changeable by the Registrar. Both
are, to re-iterate, encrypted by TLS while in transit.
The BRSKI-MASA exchange reveals the following information to the
manufacturer:
o the identity of the device being enrolled (down to the serial-
number!).
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
the WebPKI, so this identity could be pseudonymous. If there is
sales channel integration, then the MASA will have authenticated
the domain owner, either via pinned certificate, or perhaps
another HTTP authentication method, as per Section 5.5.3.
o the time the device is activated,
o the IP address of the domain Owner's Registrar. For ISPs and
Enterprises, the IP address provides very clear geolocation of the
owner. No amount of IP address privacy extensions ([RFC4941]) can
do anything about this, as a simple whois lookup likely identifies
the ISP or Enterprise from the upper bits anyway. A passive
attacker who observes the connection definitely may conclude that
the given enterprise/ISP is a customer of the particular equipment
vendor. The precise model that is being enrolled will remain
private.
The above situation is to be distinguished from a residential/
individual person who registers a device from a manufacturer: that an
enterprise/ISP purchases routing products is hardly worth mentioning.
Deviations would, however, be notable.
The situation is not improved by the enterprise/ISP using
anonymization services such as ToR [Dingledine2004], as a TLS 1.2
connection will reveal the ClientCertificate used, clearly
identifying the enterprise/ISP involved. TLS 1.3 is better in this
regard, but an active attacker can still discover the parties
involved by performing a Man-In-The-Middle-Attack on the first
attempt (breaking/killing it with a TCP RST), and then letting
subsequent connection pass through.
A manufacturer could attempt to mix the BRSKI-MASA traffic in with
general traffic their site by hosting the MASA behind the same (set)
of load balancers that the companies normal marketing site is hosted
behind. This makes lots of sense from a straight capacity planning
point of view as the same set of services (and the same set of
Distributed Denial of Service mitigations) may be used.
Unfortunately, as the BRSKI-MASA connections include TLS
ClientCertificate exchanges, this may easily be observed in TLS 1.2,
and a traffic analysis may reveal it even in TLS 1.3. This does not
make such a plan irrelevant. There may be other organizational
reasons to keep the marketing site (which is often subject to
frequent redesigs, outsourcing, etc.) seperate from the MASA, which
may need to operate reliably for decades.
9.2.2. Manufacturers and Used or Stolen Equipment
As explained above, the manufacturer receives information each time
that a device which is in factory-default mode does a zero-touch
bootstrap, and attempts to enroll into a domain owner's registrar.
The manufacturer is therefore in a position to decline to issue a
voucher if it detects that the new owner is not the same as the
previous owner.
1. This can be seen as a feature if the equipment is believed to
have been stolen. If the legitimate owner notifies the
manufacturer of the theft, then when the new owner brings the
device up, if they use the zero-touch mechanism, the new
(illegitimate) owner reveals their location and identity.
2. In the case of Used equipment, the initial owner could inform the
manufacturer of the sale, or the manufacturer may just permit
resales unless told otherwise. In which case, the transfer of
ownership simply occurs.
3. A manufacturer could however decide not to issue a new voucher in
response to a transfer of ownership. This is essentially the
same as the stolen case, with the manufacturer having decided
that the sale was not legitimate.
4. There is a fourth case, if the manufacturer is providing
protection against stolen devices. The manufacturer then has a
responsability to protect the legitimate owner against fraudulent
claims that the the equipment was stolen. Such a claim would
cause the manufacturer to refuse to issue a new voucher. Should
the device go through a deep factory reset (for instance,
replacement of a damaged main board component, the device would
not bootstrap.
5. Finally, there is a fifth case: the manufacturer has decided to
end-of-line the device, or the owner has not paid a yearly
support amount, and the manufacturer refuses to issue new
vouchers at that point. This last case is not new to the
industry: many license systems are already deployed that have
significantly worse effect.
This section has outlined five situations in which a manufacturer
could use the voucher system to enforce what are clearly license
terms. A manufacturer that attempted to enforce license terms via
vouchers would find it rather ineffective as the terms would only be
enforced when the device is enrolled, and this is not (to repeat), a
daily or even monthly occurrance.
9.2.3. Manufacturers and Grey market equipment
Manufacturers of devices often sell different products into different
regional markets. Which product is available in which market can be
driven by price differentials, support issues (some markets may
require manuals and tech-support to be done in the local language),
government export regulation (such as whether strong crypto is
permitted to be exported, or permitted to be used in a particular
market). When an domain owner obtains a device from a different
market (they can be new) and transfers it to a different location,
this is called a Grey Market.
A manufacturer could decide not to issue a voucher to an enterprise/
ISP based upon their location. There are a number of ways which this
could be determined: from the geolocation of the registrar, from
sales channel knowledge about the customer, and what products are
(un-)available in that market. If the device has a GPS the
coordinates of the device could even be placed into an extension of
the voucher.
The above actions are not illegal, and not new. Many manufacturers
have shipped crypto-weak (exportable) versions of firmware as the
default on equipment for decades. The first task of an enterprise/
ISP has always been to login to a manufacturer system, show one's
"entitlement" (country informatin, proof that support payments have
been made), and receive either a new updated firmware, or a license
key that will activate the correct firmware.
BRSKI permits the above process to automated (in an autonomic
fashion), and therefore perhaps encourages this kind of
differentiation by reducing the cost of doing it.
An issue that manufacturers will need to deal with in the above
automated process is when a device is shipped to one country with one
set of rules (or laws or entitlements), but the domain registry is in
another one. Which rules apply is something will have to be worked
out: the manufacturer could come to believe they are dealing with
Grey market equipment, when it is simply dealing with a global
enterprise.
9.2.4. Some mitigations for meddling by manufacturers
The most obvious mitigation is not to buy the product. Pick
manufacturers that are up-front about their policies, who do not
change them gratutiously.
A manufacturer could provide a mechanism to manage the trust anchors
and built-in certificates (IDevID) as an extension. This is a
substantial amount of work, and may be an area for future
standardization work.
Replacement of the voucher validation anchors (usually pointing to
the original manufacturer's MASA) with those of the new owner permits
the new owner to issue vouchers to subsequent owners. This would be
done by having the selling (old) owner to run a MASA.
In order to automatically find the new MASA, the mechanism describe
in this document is to look for the MASA URL extension in the IDevID.
A new owner could override this in their Registrar, or the
manufacturer could provide a mechanism to update or replace the
IDevID prior to sale.
Once the voucher trust anchor and the IDevID is replaced, then the
device will no longer trust the manufacturer in any way. When a new
owner performs a bootstrap, the device will point to a MASA that has
been chosen, and will validate vouchers from this new entity.
The BRSKI protocol depends upon a trust anchor on the device and an
identity on the device. Management of these these entities
facilitiates a few new operatonal modes without making any changes to
the BRSKI protocol. Those modes include: offline modes where the
domain owner operates an internal MASA for all devices, resell modes
where the first domain owner becomes the MASA for the next (resold-
to) domain owner, and services where an aggregator acquires a large
variety of devices, and then acts as a pseudonymized MASA for a
variety of devices from a variety of manufacturers.
Some manufacturers may wish to consider replacement of the IDevID as
an indication that the device's warantee is terminated. For others,
the privacy requiments of some deployments might consider this a
standard operating practice.
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
permit the audit log to continue to be useful, even when there is a
chain of MASA due to changes of ownership.
10. 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 6, the protocol allows introduction, and touched on again in Section 6, 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.
To facilitate logging and administrative oversight, in addition to To facilitate logging and administrative oversight, in addition to
skipping to change at page 60, line 9 skipping to change at page 67, line 5
Pledges might chose to engage in protocol operations with multiple Pledges might chose to engage in protocol operations with multiple
discovered registrars in parallel. As noted above they will only do discovered registrars in parallel. As noted above they will only do
so with distinct nonce values, but the end result could be multiple so with distinct nonce values, but the end result could be multiple
vouchers issued from the MASA if all registrars attempt to claim the vouchers issued from the MASA if all registrars attempt to claim the
device. This is not a failure and the pledge choses whichever device. This is not a failure and the pledge choses whichever
voucher to accept based on internal logic. The registrars verifying voucher to accept based on internal logic. The registrars verifying
log information will see multiple entries and take this into account log information will see multiple entries and take this into account
for their analytics purposes. for their analytics purposes.
9.1. DoS against MASA 10.1. DoS against MASA
There are uses cases where the MASA could be unavailable or There are uses cases where the MASA could be unavailable or
uncooperative to the Registrar. They include active DoS attacks, uncooperative to the Registrar. They include active DoS attacks,
planned and unplanned network partitions, changes to MASA policy, or planned and unplanned network partitions, changes to MASA policy, or
other instances where MASA policy rejects a claim. These introduce other instances where MASA policy rejects a claim. These introduce
an operational risk to the Registrar owner in that MASA behavior an operational risk to the Registrar owner in that MASA behavior
might limit the ability to bootstrap a pledge device. For example might limit the ability to bootstrap a pledge device. For example
this might be an issue during disaster recovery. This risk can be this might be an issue during disaster recovery. This risk can be
mitigated by Registrars that request and maintain long term copies of mitigated by Registrars that request and maintain long term copies of
"nonceless" vouchers. In that way they are guaranteed to be able to "nonceless" vouchers. In that way they are guaranteed to be able to
skipping to change at page 60, line 47 skipping to change at page 67, line 43
of a valid manufacturer customer, even without validating ownership of a valid manufacturer customer, even without validating ownership
of specific pledge devices, helps to mitigate this. Pledge of specific pledge devices, helps to mitigate this. Pledge
signatures on the pledge voucher-request, as forwarded by the signatures on the pledge voucher-request, as forwarded by the
registrar in the prior-signed-voucher-request field of the registrar registrar in the prior-signed-voucher-request field of the registrar
voucher-request, significantly reduce this risk by ensuring the MASA voucher-request, significantly reduce this risk by ensuring the MASA
can confirm proximity between the pledge and the registrar making the can confirm proximity between the pledge and the registrar making the
request. This mechanism is optional to allow for constrained request. This mechanism is optional to allow for constrained
devices. Supply chain integration ("know your customer") is an devices. Supply chain integration ("know your customer") is an
additional step that MASA providers and device vendors can explore. additional step that MASA providers and device vendors can explore.
9.2. Freshness in Voucher-Requests 10.2. Freshness in Voucher-Requests
A concern has been raised that the pledge voucher-request should A concern has been raised that the pledge voucher-request should
contain some content (a nonce) provided by the registrar and/or MASA contain some content (a nonce) provided by the registrar and/or MASA
in order for those actors to verify that the pledge voucher-request in order for those actors to verify that the pledge voucher-request
is fresh. is fresh.
There are a number of operational problems with getting a nonce from There are a number of operational problems with getting a nonce from
the MASA to the pledge. It is somewhat easier to collect a random the MASA to the pledge. It is somewhat easier to collect a random
value from the registrar, but as the registrar is not yet vouched value from the registrar, but as the registrar is not yet vouched
for, such a registrar nonce has little value. There are privacy and for, such a registrar nonce has little value. There are privacy and
skipping to change at page 62, line 15 skipping to change at page 69, line 9
but if this is a consideration the target network is RECOMMENDED to but if this is a consideration the target network is RECOMMENDED to
take the following steps: take the following steps:
o Ongoing network monitoring for unexpected bootstrapping attempts o Ongoing network monitoring for unexpected bootstrapping attempts
by pledges. by pledges.
o Retreival and examination of MASA log information upon the o Retreival and examination of MASA log information upon the
occurance of any such unexpected events. Rm will be listed in the occurance of any such unexpected events. Rm will be listed in the
logs along with nonce information for analysis. logs along with nonce information for analysis.
9.3. Trusting manufacturers 10.3. Trusting manufacturers
The BRSKI extensions to EST permit a new pledge to be completely The BRSKI extensions to EST permit a new pledge to be completely
configured with domain specific trust anchors. The link from built- configured with domain specific trust anchors. The link from built-
in manufacturer-provided trust anchors to domain-specific trust in manufacturer-provided trust anchors to domain-specific trust
anchors is mediated by the signed voucher artifact. anchors is mediated by the signed voucher artifact.
If the manufacturer's IDevID signing key is not properly validated, If the manufacturer's IDevID signing key is not properly validated,
then there is a risk that the network will accept a pledge that then there is a risk that the network will accept a pledge that
should not be a member of the network. As the address of the should not be a member of the network. As the address of the
manufacturer's MASA is provided in the IDevID using the extension manufacturer's MASA is provided in the IDevID using the extension
skipping to change at page 63, line 20 skipping to change at page 70, line 10
device category (e.g, a light bulb, or a cable-modem) are signed device category (e.g, a light bulb, or a cable-modem) are signed
by an certificate authority specifically for this. This is done by an certificate authority specifically for this. This is done
by CableLabs today. It is used for authentication and by CableLabs today. It is used for authentication and
authorization as part of TR-79: [docsisroot] and [TR069]. authorization as part of TR-79: [docsisroot] and [TR069].
The existing WebPKI provides a reasonable anchor between manufacturer The existing WebPKI provides a reasonable anchor between manufacturer
name and public key. It authenticates the key. It does not provide name and public key. It authenticates the key. It does not provide
a reasonable authorization for the manufacturer, so it is not a reasonable authorization for the manufacturer, so it is not
directly useable on it's own. directly useable on it's own.
10. Acknowledgements 11. Acknowledgements
We would like to thank the various reviewers for their input, in We would like to thank the various reviewers for their input, in
particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu
Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg, Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg,
and Peter van der Stok and Peter van der Stok
11. References 12. References
11.1. Normative References 12.1. Normative References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-18 (work in progress), August 2018. plane-18 (work in progress), August 2018.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
skipping to change at page 65, line 46 skipping to change at page 72, line 42
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
11.2. Informative References [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/info/rfc8368>.
12.2. Informative References
[Dingledine2004]
Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the
second-generation onion router", 2004,
<https://spec.torproject.org/tor-spec>.
[docsisroot] [docsisroot]
CableLabs, "CableLabs Digital Certificate Issuance CableLabs, "CableLabs Digital Certificate Issuance
Service", February 2018, Service", February 2018,
<https://www.cablelabs.com/resources/ <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., Kumar, S., Richardson, M., Stok, P., Kampanakis, P., Richardson, M., and S. Raza,
Furuhed, M., and S. Raza, "EST over secure CoAP (EST- "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap-
coaps)", draft-ietf-ace-coap-est-06 (work in progress), est-07 (work in progress), January 2019.
October 2018.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
Networking", draft-ietf-anima-reference-model-08 (work in Networking", draft-ietf-anima-reference-model-10 (work in
progress), October 2018. progress), November 2018.
[I-D.ietf-anima-stable-connectivity] [I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf- Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-10 (work in progress), February anima-stable-connectivity-10 (work in progress), February
2018. 2018.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor- express CBOR and JSON data structures", draft-ietf-cbor-
cddl-05 (work in progress), August 2018. cddl-06 (work in progress), November 2018.
[I-D.ietf-netconf-zerotouch] [I-D.ietf-netconf-zerotouch]
Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero
Provisioning for Networking Devices", draft-ietf-netconf- Touch Provisioning (SZTP)", draft-ietf-netconf-
zerotouch-25 (work in progress), September 2018. zerotouch-29 (work in progress), January 2019.
[I-D.ietf-opsawg-mud] [I-D.ietf-opsawg-mud]
Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", draft-ietf-opsawg-mud-25 (work Description Specification", draft-ietf-opsawg-mud-25 (work
in progress), June 2018. in progress), June 2018.
[I-D.richardson-anima-state-for-joinrouter] [I-D.richardson-anima-state-for-joinrouter]
Richardson, M., "Considerations for stateful vs stateless Richardson, M., "Considerations for stateful vs stateless
join router in ANIMA bootstrap", draft-richardson-anima- join router in ANIMA bootstrap", draft-richardson-anima-
state-for-joinrouter-02 (work in progress), January 2018. state-for-joinrouter-02 (work in progress), January 2018.
[imprinting] [imprinting]
Wikipedia, "Wikipedia article: Imprinting", July 2015, Wikipedia, "Wikipedia article: Imprinting", July 2015,
<https://en.wikipedia.org/wiki/Imprinting_(psychology)>. <https://en.wikipedia.org/wiki/Imprinting_(psychology)>.
[IoTstrangeThings]
Internet, "IoT of toys stranger than fiction:
Cybersecurity and data privacy update (accessed
2018-12-02)", March 2017,
<https://www.welivesecurity.com/2017/03/03/
internet-of-things-security-privacy-iot-update/>.
[livingwithIoT]
Internet, "What is it actually like to live in a house
filled with IoT devices? (accessed 2018-12-02)", February
2018, <https://www.siliconrepublic.com/machines/
iot-smart-devices-reality>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[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>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
skipping to change at page 68, line 5 skipping to change at page 75, line 25
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[Stajano99theresurrecting] [Stajano99theresurrecting]
Stajano, F. and R. Anderson, "The resurrecting duckling: Stajano, F. and R. Anderson, "The resurrecting duckling:
security issues for ad-hoc wireless networks", 1999, security issues for ad-hoc wireless networks", 1999,
<https://www.cl.cam.ac.uk/~fms27/ <https://www.cl.cam.ac.uk/~fms27/
papers/1999-StajanoAnd-duckling.pdf>. papers/1999-StajanoAnd-duckling.pdf>.
[TR069] Broadband Forum, "TR-69: CPE WAN Management Protocol", [TR069] Broadband Forum, "TR-69: CPE WAN Management Protocol",
February 2018, <https://www.broadband-forum.org/ February 2018, <https://www.broadband-forum.org/
standards-and-software/technical-specifications/ standards-and-software/technical-specifications/
tr-069-files-tools>. tr-069-files-tools>.
skipping to change at page 73, line 12 skipping to change at page 81, line 12
c3o= c3o=
-----END CERTIFICATE----- -----END CERTIFICATE-----
The registrar public certificate as decoded by openssl's x509 The registrar public certificate as decoded by openssl's x509
utility. Note that the registrar certificate is marked with the utility. Note that the registrar certificate is marked with the
cmcRA extension. cmcRA extension.
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 3 (0x3) Serial Number: 3 (0x3)
Signature Algorithm: ecdsa-with-SHA384 Signature Algorithm: ecdsa-with-SHA384
Issuer: DC = ca, DC = sandelman, CN = Unstrung Fount Issuer: DC=ca, DC=sandelman, CN=Unstrung Fountain CA
ain CA
Validity Validity
Not Before: Sep 5 01:12:45 2017 GMT Not Before: Sep 5 01:12:45 2017 GMT
Not After : Sep 5 01:12:45 2019 GMT Not After : Sep 5 01:12:45 2019 GMT
Subject: DC = ca, DC = sandelman, CN = localhost Subject: DC=ca, DC=sandelman, CN=localhost
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7
8:17: 8:17:
34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5
3:3e: 3:3e:
03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e
9:ba: 9:ba:
13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2
f:96: f:96:
e9:9d:e2:bc:b2 e9:9d:e2:bc:b2
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Basic Constraints: X509v3 Basic Constraints:
CA:FALSE CA:FALSE
Signature Algorithm: ecdsa-with-SHA384 Signature Algorithm: ecdsa-with-SHA384
30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78: 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78:
5b: 5b:
9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e: 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e:
b6: b6:
9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21: 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21:
02: 02:
skipping to change at page 74, line 45 skipping to change at page 83, line 9
The pledge public certificate as decoded by openssl's x509 utility so The pledge public certificate as decoded by openssl's x509 utility so
that the extensions can be seen. A second custom Extension is that the extensions can be seen. A second custom Extension is
included to provided to contain the EUI48/EUI64 that the pledge will included to provided to contain the EUI48/EUI64 that the pledge will
configure. configure.
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 12 (0xc) Serial Number: 12 (0xc)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: DC = ca, DC = sandelman, CN = Unstrung Highw Issuer: DC=ca, DC=sandelman, CN=Unstrung Highway CA
ay CA
Validity Validity
Not Before: Oct 12 13:52:52 2017 GMT Not Before: Oct 12 13:52:52 2017 GMT
Not After : Dec 31 00:00:00 2999 GMT Not After : Dec 31 00:00:00 2999 GMT
Subject: DC = ca, DC = sandelman, CN = 00-D0-E5-F2-0 Subject: DC=ca, DC=sandelman, CN=00-D0-E5-F2-00-02
0-02
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:49:a7:98:b4:75:4d:5a:52:74:76:bb:cc:0 04:49:a7:98:b4:75:4d:5a:52:74:76:bb:cc:0
c:47: c:47:
08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b 08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b
4:28: 4:28:
96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e 96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e
d:b8: d:b8:
87:69:44:f7:c6:67:c8:54:fe:72:14:bd:ea:b 87:69:44:f7:c6:67:c8:54:fe:72:14:bd:ea:b
0:ca: 0:ca:
86:08:f0:13:db 86:08:f0:13:db
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Subject Key Identifier: X509v3 Subject Key Identifier:
1D:31:16:61:B6:11:50:9B:3C:FA:13:B6:15:5F:39 1D:31:16:61:B6:11:50:9B:3C:FA:13:B6:15:5F:39
:0B:ED:76:43:2A :0B:ED:76:43:2A
X509v3 Basic Constraints: X509v3 Basic Constraints:
CA:FALSE CA:FALSE
X509v3 Subject Alternative Name: X509v3 Subject Alternative Name:
othername:<unsupported> othername:<unsupported>
1.3.6.1.4.1.46930.2: 1.3.6.1.4.1.46930.2:
..https://highway.sandelman.ca ..https://highway.sandelman.ca
 End of changes. 47 change blocks. 
154 lines changed or deleted 493 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/