draft-ietf-anima-bootstrapping-keyinfra-29.txt   draft-ietf-anima-bootstrapping-keyinfra-30.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: April 30, 2020 Sandelman Expires: May 20, 2020 Sandelman
T. Eckert T. Eckert
Futurewei USA Futurewei USA
M. Behringer M. Behringer
K. Watsen K. Watsen
Watsen Networks Watsen Networks
October 28, 2019 November 17, 2019
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-29 draft-ietf-anima-bootstrapping-keyinfra-30
Abstract Abstract
This document specifies automated bootstrapping of an Autonomic This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Secure Key Infrastructure is Control Plane. To do this a Secure Key Infrastructure is
bootstrapped. This is done using manufacturer-installed X.509 bootstrapped. This is done using manufacturer-installed X.509
certificates, in combination with a manufacturer's authorizing certificates, in combination with a manufacturer's authorizing
service, both online and offline. We call this process the service, both online and offline. We call this process the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
Bootstrapping a new device can occur using a routable address and a Bootstrapping a new device can occur using a routable address and a
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 April 30, 2020. This Internet-Draft will expire on May 20, 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 10 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 10
1.3.1. Support environment . . . . . . . . . . . . . . . . . 10 1.3.1. Support environment . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 devices . . . . . . . . . . . . . . . . . . . . . . . . . 13
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
skipping to change at page 3, line 46 skipping to change at page 3, line 46
5.8. Registrar audit-log request . . . . . . . . . . . . . . . 54 5.8. Registrar audit-log request . . . . . . . . . . . . . . . 54
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 55 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 55
5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 58 5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 58
5.8.3. Registrar audit log verification . . . . . . . . . . 58 5.8.3. Registrar audit log verification . . . . . . . . . . 58
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 60 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 60
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 60 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 60
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 60 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 60
5.9.3. EST Client Certificate Request . . . . . . . . . . . 61 5.9.3. EST Client Certificate Request . . . . . . . . . . . 61
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 61 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 61
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 62 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 62
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 62 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 63
6. Clarification of transfer-encoding . . . . . . . . . . . . . 63 6. Clarification of transfer-encoding . . . . . . . . . . . . . 63
7. Reduced security operational modes . . . . . . . . . . . . . 63 7. Reduced security operational modes . . . . . . . . . . . . . 63
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 63 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 64
7.2. Pledge security reductions . . . . . . . . . . . . . . . 64 7.2. Pledge security reductions . . . . . . . . . . . . . . . 64
7.3. Registrar security reductions . . . . . . . . . . . . . . 65 7.3. Registrar security reductions . . . . . . . . . . . . . . 65
7.4. MASA security reductions . . . . . . . . . . . . . . . . 66 7.4. MASA security reductions . . . . . . . . . . . . . . . . 66
7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 66 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 67
7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 67 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 67
7.4.3. Updating or extending voucher trust anchors . . . . . 67 7.4.3. Updating or extending voucher trust anchors . . . . . 68
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69
8.2. Well-known EST registration . . . . . . . . . . . . . . . 69 8.2. Well-known EST registration . . . . . . . . . . . . . . . 69
8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 69 8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 69
8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 69 8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 70
8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70 8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70
8.6. MUD File Extension for the MASA . . . . . . . . . . . . . 70 8.6. MUD File Extension for the MASA . . . . . . . . . . . . . 70
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 70 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 70
9.1. Operational Requirements . . . . . . . . . . . . . . . . 71 9.1. Operational Requirements . . . . . . . . . . . . . . . . 72
9.1.1. MASA Operational Requirements . . . . . . . . . . . . 72 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 72
9.1.2. Domain Owner Operational Requirements . . . . . . . . 72 9.1.2. Domain Owner Operational Requirements . . . . . . . . 73
9.1.3. Device Operational Requirements . . . . . . . . . . . 73 9.1.3. Device Operational Requirements . . . . . . . . . . . 73
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 73 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 74
10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 73 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 74
10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 74 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 74
10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 75 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 75
10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 77 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 77
10.5. Manufacturers and Grey market equipment . . . . . . . . 78 10.5. Manufacturers and Grey market equipment . . . . . . . . 78
10.6. Some mitigations for meddling by manufacturers . . . . . 79 10.6. Some mitigations for meddling by manufacturers . . . . . 79
10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 80 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 80
11. Security Considerations . . . . . . . . . . . . . . . . . . . 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 81
11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 81 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 81
11.2. Availability of good random numbers . . . . . . . . . . 82 11.2. DomainID must be resistant to second-preimage attacks . 82
11.3. Freshness in Voucher-Requests . . . . . . . . . . . . . 82 11.3. Availability of good random numbers . . . . . . . . . . 82
11.4. Trusting manufacturers . . . . . . . . . . . . . . . . . 83 11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 83
11.5. Manufacturer Maintenance of trust anchors . . . . . . . 84 11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 84
11.5.1. Compromise of Manufacturer IDevID signing keys . . . 86 11.6. Manufacturer Maintenance of trust anchors . . . . . . . 85
11.5.2. Compromise of MASA signing keys . . . . . . . . . . 86 11.6.1. Compromise of Manufacturer IDevID signing keys . . . 86
11.5.3. Compromise of MASA web service . . . . . . . . . . . 88 11.6.2. Compromise of MASA signing keys . . . . . . . . . . 87
11.6.3. Compromise of MASA web service . . . . . . . . . . . 89
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 89 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 89
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90
13.1. Normative References . . . . . . . . . . . . . . . . . . 89 13.1. Normative References . . . . . . . . . . . . . . . . . . 90
13.2. Informative References . . . . . . . . . . . . . . . . . 93 13.2. Informative References . . . . . . . . . . . . . . . . . 93
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 96 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 97
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 96 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 97
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 96 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 97
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 97 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 97
Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 97 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 98
Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 100 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 100
D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 100 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 100
D.1.1. MASA key pair for voucher signatures . . . . . . . . 100 D.1.1. MASA key pair for voucher signatures . . . . . . . . 100
D.1.2. Manufacturer key pair for IDevID signatures . . . . . 100 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 100
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 101 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 101
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 103 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 103
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 104 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 104
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 105 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 105
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 108 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 108
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 113 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117
1. Introduction 1. Introduction
The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
provides a solution for secure zero-touch (automated) bootstrap of provides a solution for secure zero-touch (automated) bootstrap of
skipping to change at page 8, line 8 skipping to change at page 8, line 10
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are defined for clarity: The following terms are defined for clarity:
ANI: The Autonomic Network Infrastructure as defined by ANI: The Autonomic Network Infrastructure as defined by
[I-D.ietf-anima-reference-model]. This document details specific [I-D.ietf-anima-reference-model]. Section 9 details specific
requirements for pledges, proxies and registrars when they are requirements for pledges, proxies and registrars when they are
part of an ANI. part of an ANI.
Circuit Proxy: A stateful implementation of the join proxy. This is Circuit Proxy: A stateful implementation of the join proxy. This is
the assumed type of proxy. the assumed type of proxy.
drop-ship: The physical distribution of equipment containing the drop-ship: The physical distribution of equipment containing the
"factory default" configuration to a final destination. In zero- "factory default" configuration to a final destination. In zero-
touch scenarios there is no staging or pre-configuration during touch scenarios there is no staging or pre-configuration during
drop-ship. drop-ship.
skipping to change at page 9, line 44 skipping to change at page 9, line 46
"original equipment manufacturer" or OEM, but in more complex "original equipment manufacturer" or OEM, but in more complex
situations it could be a "value added retailer" (VAR), or possibly situations it could be a "value added retailer" (VAR), or possibly
even a systems integrator. In general, it a goal of BRSKI to even a systems integrator. In general, it a goal of BRSKI to
eliminate small distinctions between different sales channels. eliminate small distinctions between different sales channels.
The reason for this is that it permits a single device, with a The reason for this is that it permits a single device, with a
uniform firmware load, to be shipped directly to all customers. uniform firmware load, to be shipped directly to all customers.
This eliminates costs for the manufacturer. This also reduces the This eliminates costs for the manufacturer. This also reduces the
number of products supported in the field increasing the chance number of products supported in the field increasing the chance
that firmware will be more up to date. that firmware will be more up to date.
MASA Audit-Log: A list of previous owners maintained by the MASA on MASA Audit-Log: An anonymized list of previous owners maintained by
a per device (per pledge) basis. Described in Section 5.8.1. the MASA on a per device (per pledge) basis. Described in
Section 5.8.1.
MASA Service: A third-party Manufacturer Authorized Signing MASA Service: A third-party Manufacturer Authorized Signing
Authority (MASA) service on the global Internet. The MASA signs Authority (MASA) service on the global Internet. The MASA signs
vouchers. It also provides a repository for audit-log information vouchers. It also provides a repository for audit-log information
of privacy protected bootstrapping events. It does not track of privacy protected bootstrapping events. It does not track
ownership. ownership.
nonced: a voucher (or request) that contains a nonce (the normal nonced: a voucher (or request) that contains a nonce (the normal
case). case).
skipping to change at page 10, line 22 skipping to change at page 10, line 25
offline: When an architectural component cannot perform realtime offline: When an architectural component cannot perform realtime
communications with a peer, either due to network connectivity or communications with a peer, either due to network connectivity or
because the peer is turned off, the operation is said to be because the peer is turned off, the operation is said to be
occurring offline. occurring offline.
Ownership Tracker: An Ownership Tracker service on the global Ownership Tracker: An Ownership Tracker service on the global
Internet. The Ownership Tracker uses business processes to Internet. The Ownership Tracker uses business processes to
accurately track ownership of all devices shipped against domains accurately track ownership of all devices shipped against domains
that have purchased them. Although optional, this component that have purchased them. Although optional, this component
allows vendors to provide additional value in cases where their allows vendors to provide additional value in cases where their
sales and distribution channels allow for accurately tracking of sales and distribution channels allow for accurate tracking of
such ownership. Ownership tracking information is indicated in such ownership. Ownership tracking information is indicated in
vouchers as described in [RFC8366] vouchers as described in [RFC8366]
Pledge: The prospective (unconfigured) device, which has an identity Pledge: The prospective (unconfigured) device, which has an identity
installed at the factory. installed at the factory.
(Public) Key Infrastructure: The collection of systems and processes (Public) Key Infrastructure: The collection of systems and processes
that sustain the activities of a public key system. The registrar that sustain the activities of a public key system. The registrar
acts as an [RFC5280] and [RFC5272] (see section 7) "Registration acts as an [RFC5280] and [RFC5272] (see section 7) "Registration
Authority". Authority".
skipping to change at page 18, line 12 skipping to change at page 18, line 12
This is consistent with [RFC5280] section 4.2.1.3, which does not This is consistent with [RFC5280] section 4.2.1.3, which does not
require key usage restrictions for end entity certificates. 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]. That specification The serialNumber field is defined in [RFC5280]. That specification
allows for the field to be omitted if there is a good technical allows for the field to be omitted if there is a good technical
reason. IDevID certificates for use with this protocol are REQUIRED reason. IDevID certificates for use with this protocol are REQUIRED
to include the "serialNumber" attribute with the device's unique to include the "serialNumber" attribute with the device's unique
serial number (from [IDevID] section 7.2.8, and [RFC5280] section serial number (from [IDevID] section 7.2.8, and [RFC5280] section
4.1.2.2's list of standard attributes). 4.1.2.2's list of standard attributes).
The serialNumber field is used as follows by the pledge to build the The serialNumber field is used as follows by the pledge to build the
"serial-number" that is placed in the voucher-request. In order to "serial-number" that is placed in the voucher-request. In order to
build it, the fields need to be converted into a serial-number of build it, the fields need to be converted into a serial-number of
"type string". "type string".
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. The pledge can The pledge is the device that is attempting to join. The pledge is
talk to the Join Proxy using link-local network connectivity. In assumed to talk to the Join Proxy using link-local network
most cases, the pledge has no other connectivity until the pledge connectivity. In most cases, the pledge has no other connectivity
completes the enrollment process and receives some kind of network until the pledge completes the enrollment process and receives some
credential. 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 24, line 41 skipping to change at page 24, line 41
A pledge MAY ignore all time stamps in the voucher and in the A pledge MAY ignore all time stamps in the voucher and in the
certificate validity periods if it does not know the current time. certificate validity periods if it does not know the current time.
The pledge is exposed to dates in the following five places: The pledge is exposed to dates in the following five places:
registrar certificate notBefore, registrar certificate notAfter, registrar certificate notBefore, registrar certificate notAfter,
voucher created-on, and voucher expires-on. Additionally, CMS voucher created-on, and voucher expires-on. Additionally, CMS
signatures contain a signingTime. signatures contain a signingTime.
A pledge with a real time clock in which it has confidence in, MUST A pledge with a real time clock in which it has confidence in, MUST
check the above time fields in all certificates and signatures that check the above time fields in all certificates and signatures that
ir processes. it processes.
If the voucher contains a nonce then the pledge MUST confirm the If the voucher contains a nonce then the pledge MUST confirm the
nonce matches the original pledge voucher-request. This ensures the nonce matches the original pledge voucher-request. This ensures the
voucher is fresh. See Section 5.2. voucher is fresh. See Section 5.2.
2.6.2. Infinite Lifetime of IDevID 2.6.2. Infinite Lifetime of IDevID
[RFC5280] explains that long lived pledge certificates "SHOULD be [RFC5280] explains that long lived pledge certificates "SHOULD be
assigned the GeneralizedTime value of 99991231235959Z" for the assigned the GeneralizedTime value of 99991231235959Z" for the
notAfter field. notAfter field.
Some deployed IDevID management systems are not compliant with the Some deployed IDevID management systems are not compliant with the
802.1AR requirement for infinite lifetimes, and put in typical <= 3 802.1AR requirement for infinite lifetimes, and put in typical <= 3
year certificate lifetimes. Registrars SHOULD be configurable on a year certificate lifetimes. Registrars SHOULD be configurable on a
per-manufacturer basis to ignore pledge lifetimes when they did not per-manufacturer basis to ignore pledge lifetimes when the pledge did
follow the RFC5280 recommendations. not follow the RFC5280 recommendations.
2.7. Cloud Registrar 2.7. Cloud Registrar
There exist operationally open networks wherein devices gain There exist operationally open networks wherein devices gain
unauthenticated access to the Internet at large. In these use cases unauthenticated access to the Internet at large. In these use cases
the management domain for the device needs to be discovered within the management domain for the device needs to be discovered within
the larger Internet. The case where a device can boot and get access the larger Internet. The case where a device can boot and get access
to larger Internet are less likely within the ANIMA ACP scope but may to larger Internet are less likely within the ANIMA ACP scope but may
be more important in the future. In the ANIMA ACP scope, new devices be more important in the future. In the ANIMA ACP scope, new devices
will be quarantined behind a Join Proxy. will be quarantined behind a Join Proxy.
skipping to change at page 34, line 21 skipping to change at page 34, line 21
announcements of the objective: "AN_Proxy". See section announcements of the objective: "AN_Proxy". See section
Section 4.1.1 for the details of the objective. The pledge MAY Section 4.1.1 for the details of the objective. The pledge MAY
listen concurrently for other sources of information, see listen concurrently for other sources of information, see
Appendix B. Appendix B.
Once a proxy is discovered the pledge communicates with a registrar Once a proxy is discovered the pledge communicates with a registrar
through the proxy using the bootstrapping protocol defined in through the proxy using the bootstrapping protocol defined in
Section 5. Section 5.
While the GRASP M_FLOOD mechanism is passive for the pledge, the non- While the GRASP M_FLOOD mechanism is passive for the pledge, the non-
normative other methods (mDNS, and IPv4 methods) described Appendix B normative other methods (mDNS, and IPv4 methods) described in
are active. The pledge SHOULD run those methods in parallel with Appendix B are active. The pledge SHOULD run those methods in
listening to for the M_FLOOD. The active methods SHOULD back-off by parallel with listening to for the M_FLOOD. The active methods
doubling to a maximum of one hour to avoid overloading the network SHOULD back-off by doubling to a maximum of one hour to avoid
with discovery attempts. Detection of change of physical link status overloading the network with discovery attempts. Detection of change
(Ethernet carrier for instance) SHOULD reset the back off timers. of physical link status (Ethernet carrier for instance) SHOULD reset
the back off timers.
The pledge could discover more than one proxy on a given physical The pledge could discover more than one proxy on a given physical
interface. The pledge can have a multitude of physical interfaces as interface. The pledge can have a multitude of physical interfaces as
well: a layer-2/3 Ethernet switch may have hundreds of physical well: a layer-2/3 Ethernet switch may have hundreds of physical
ports. ports.
Each possible proxy offer SHOULD be attempted up to the point where a Each possible proxy offer SHOULD be attempted up to the point where a
valid voucher is received: while there are many ways in which the valid voucher is received: while there are many ways in which the
attempt may fail, it does not succeed until the voucher has been attempt may fail, it does not succeed until the voucher has been
validated. validated.
skipping to change at page 43, line 10 skipping to change at page 43, line 10
If authorization is successful the registrar obtains a voucher from If authorization is successful the registrar obtains a voucher from
the MASA service (see Section 5.5) and returns that MASA signed the MASA service (see Section 5.5) and returns that MASA signed
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 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 in
authentication of the MASA using a DNS-ID that matches that which is authentication of the MASA using a DNS-ID that matches that which is
found in the IDevID. Registrars MAY include a mechanism to override found in the IDevID. Registrars MAY include a mechanism to override
the MASA URL on a manufacturer-by-manufacturer basis, and within that the MASA URL on a manufacturer-by-manufacturer basis, and within that
override it is appropriate to provide alternate anchors. This will override it is appropriate to provide alternate anchors. This will
typically used by some vendors to establish explicit (or private) typically used by some vendors to establish explicit (or private)
trust anchors for validating their MASA that is part of a sales trust anchors for validating their MASA that is part of a sales
channel integration. channel integration.
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED. TLS 1.3 (or newer) SHOULD be available. REQUIRED. TLS 1.3 (or newer) SHOULD be available.
skipping to change at page 53, line 27 skipping to change at page 53, line 27
known/est/voucher_status". known/est/voucher_status".
The format and semantics described below are for version 1. A The format and semantics described below are for version 1. A
version field is included to permit significant changes to this version field is included to permit significant changes to this
feedback in the future. A Registrar that receives a status message feedback in the future. A Registrar that receives a status message
with a version larger than it knows about SHOULD log the contents and with a version larger than it knows about SHOULD log the contents and
alert a human. alert a human.
The Status field indicates if the voucher was acceptable. Boolean The Status field indicates if the voucher was acceptable. Boolean
values are acceptable, where "true" indicates the voucher was values are acceptable, where "true" indicates the voucher was
accesptable. acceptable.
If the voucher was not acceptable the Reason string indicates why. If the voucher was not acceptable the Reason string indicates why.
In the failure case this message may be sent to an unauthenticated, In the failure case this message may be sent to an unauthenticated,
potentially malicious registrar and therefore the Reason string potentially malicious registrar and therefore the Reason string
SHOULD NOT provide information beneficial to an attacker. The SHOULD NOT provide information beneficial to an attacker. The
operational benefit of this telemetry information is balanced against operational benefit of this telemetry information is balanced against
the operational costs of not recording that an voucher was ignored by the operational costs of not recording that an voucher was ignored by
a client the registrar expected to continue joining the domain. a client the registrar expected to continue joining the domain.
The reason-context attribute is an arbitrary JSON object (literal The reason-context attribute is an arbitrary JSON object (literal
skipping to change at page 56, line 25 skipping to change at page 56, line 25
event = { event = {
"date": text, "date": text,
"domainID": text, "domainID": text,
"nonce": text / null, "nonce": text / null,
"assertion": "verified" / "logged" / "proximity", "assertion": "verified" / "logged" / "proximity",
? "truncated": uint, ? "truncated": uint,
} }
Figure 16: CDDL for audit-log response Figure 16: CDDL for audit-log response
As an abstract example: An example:
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"2019-05-15T17:25:55.644-04:00", "date":"2019-05-15T17:25:55.644-04:00",
"domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=",
"nonce":"VOUFT-WwrEv0NuAQEHoV7Q", "nonce":"VOUFT-WwrEv0NuAQEHoV7Q",
"assertion":"proximity", "assertion":"proximity",
"truncated":"0" "truncated":"0"
skipping to change at page 59, line 30 skipping to change at page 59, line 30
external audit log shows additional re-deployments our internal external audit log shows additional re-deployments our internal
logs are unaware of"). logs are unaware of").
nonce: Nonceless entries mean the logged domainID could nonce: Nonceless entries mean the logged domainID could
theoretically trigger a reset of the pledge and then take over theoretically trigger a reset of the pledge and then take over
management by using the existing nonceless voucher. management by using the existing nonceless voucher.
assertion: The assertion leaf in the voucher and audit log indicates assertion: The assertion leaf in the voucher and audit log indicates
why the MASA issued the voucher. A "verified" entry means that why the MASA issued the voucher. A "verified" entry means that
the MASA issued the associated voucher as a result of positive the MASA issued the associated voucher as a result of positive
verification of ownership but this can still be problematic for verification of ownership. However, this entry does not indicate
registrar's that expected only new (not pre-owned) pledges. A whether the pledge was actually deployed in the prior domain, or
"logged" assertion informs the registrar that the prior vouchers not. A "logged" assertion informs the registrar that the prior
were issued with minimal verification. A "proximity" assertion vouchers were issued with minimal verification. A "proximity"
assures the registrar that the pledge was truly communicating with assertion assures the registrar that the pledge was truly
the prior domain and thus provides assurance that the prior domain communicating with the prior domain and thus provides assurance
really has deployed the pledge. that the prior domain really has deployed the pledge.
A relatively simple policy is to white list known (internal or A relatively simple policy is to white list known (internal or
external) domainIDs, and require all vouchers to have a nonce. An external) domainIDs, and require all vouchers to have a nonce. An
alternative is to require that all nonceless vouchers be from a alternative is to require that all nonceless vouchers be from a
subset (e.g. only internal) of domainIDs. If the policy is violated subset (e.g. only internal) of domainIDs. If the policy is violated
a simple action is to revoke any locally issued credentials for the a simple action is to revoke any locally issued credentials for the
pledge in question or to refuse to forward the voucher. The pledge in question or to refuse to forward the voucher. The
Registrar MUST then refuse any EST actions, and SHOULD inform a human Registrar MUST then refuse any EST actions, and SHOULD inform a human
via a log. A registrar MAY be configured to ignore (i.e. override via a log. A registrar MAY be configured to ignore (i.e. override
the above policy) the history of the device but it is RECOMMENDED the above policy) the history of the device but it is RECOMMENDED
skipping to change at page 61, line 45 skipping to change at page 61, line 45
For automated bootstrapping of devices, the administrative elements For automated bootstrapping of devices, the administrative elements
providing bootstrapping also provide indications to the system providing bootstrapping also provide indications to the system
administrators concerning device lifecycle status. This might administrators concerning device lifecycle status. This might
include information concerning attempted bootstrapping messages seen include information concerning attempted bootstrapping messages seen
by the client. The MASA provides logs and status of credential by the client. The MASA provides logs and status of credential
enrollment. [RFC7030] assumes an end user and therefore does not enrollment. [RFC7030] assumes an end user and therefore does not
include a final success indication back to the server. This is include a final success indication back to the server. This is
insufficient for automated use cases. insufficient for automated use cases.
In order to communicate this indicator, the client HTTP POSTs the In order to communicate this indicator, the client HTTP POSTs a JSON
following to the server at the new EST endpoint at "/.well-known/est/ dictionary with a number of attributes described below to the new EST
enrollstatus". endpoint at "/.well-known/est/enrollstatus".
To indicate successful enrollment the client SHOULD first re- When indicating a successful enrollment the client SHOULD first re-
establish the EST TLS session using the newly obtained credentials. establish the EST TLS session using the newly obtained credentials.
TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The
client SHOULD therefore close the existing TLS connection, and start client SHOULD therefore always close the existing TLS connection, and
a new one. start a new one.
In the case of a FAIL, the Reason string indicates why the most In the case of a FAIL, the same TLS connection MUST be used. The
recent enrollment failed. Reason string indicates why the most recent enrollment failed.
The reason-context attribute is an arbitrary JSON object (literal The reason-context attribute is an arbitrary JSON object (literal
value or hash of values) which provides additional information value or hash of values) which provides additional information
specific to the failure to unroll from this pledge. The contents of specific to the failure to unroll from this pledge. The contents of
this field are not subject to standardization. this field are not subject to standardization. This is represented
by the group-socket "$$arbitrary-map" in the CDDL.
In the case of a SUCCESS the Reason string is omitted. In the case of a SUCCESS the Reason string is omitted.
enrollstatus-post = {
"version": uint,
"status": bool,
"reason": text,
? "reason-context" : { $$arbitrary-map }
}
}
Figure 18: CDDL for enrollment status POST
An example status report can be seen below. It is sent with with the An example status report can be seen below. It is sent with with the
media type: application/json media type: application/json
{ {
"version":"1", "version":"1",
"Status":true, "status":true,
"Reason":"Informative human readable message", "reason":"Informative human readable message",
"reason-context": { "additional" : "JSON" } "reason-context": { "additional" : "JSON" }
} }
Figure 18: Example of enrollment status POST Figure 19: Example of enrollment status POST
The server SHOULD respond with an HTTP 200 but MAY simply fail with The server SHOULD respond with an HTTP 200 but MAY simply fail with
an HTTP 404 error. an HTTP 404 error.
Within the server logs the server MUST capture if this message was Within the server logs the server MUST capture if this message was
received over an TLS session with a matching client certificate. received over an TLS session with a matching client certificate.
5.9.5. Multiple certificates 5.9.5. Multiple certificates
Pledges that require multiple certificates could establish direct EST Pledges that require multiple certificates could establish direct EST
skipping to change at page 75, line 18 skipping to change at page 75, line 37
Research into a mechanism to do multi-step, multi-party authenticated Research into a mechanism to do multi-step, multi-party authenticated
key agreement, incorporating some kind of zero-knowledge proof would key agreement, incorporating some kind of zero-knowledge proof would
be valuable. Such a mechanism would ideally avoid disclosing be valuable. Such a mechanism would ideally avoid disclosing
identities until pledge, registrar and MASA agree to the transaction. identities until pledge, registrar and MASA agree to the transaction.
Such a mechanism would need to discover the location of the MASA Such a mechanism would need to discover the location of the MASA
without knowing the identity of the pledge, or the identity of the without knowing the identity of the pledge, or the identity of the
MASA. This part of the problem may be unsolveable. 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- With consumer-oriented devices, the "call-home" mechanism in IoT
MASA connection standardizes what has been deemed by some as a devices raises significant privacy concerns. See [livingwithIoT] and
sinister mechanism for corporate oversight of individuals. [IoTstrangeThings] for exemplars. The Autonomic Control Plane (ACP)
([livingwithIoT] and [IoTstrangeThings] for a small sample). usage of BRSKI is not targeted at individual usage of IoT devices,
but rather at the Enterprise and ISP creation of networks in a zero-
touch fashion where the "call-home" represents a different class of
privacy and lifecycle management concerns.
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
skipping to change at page 82, line 11 skipping to change at page 82, line 36
unbounded number of devices. Ensuring a registrar is representative unbounded number of devices. Ensuring a registrar is representative
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. Supply chain integration ("know your customer") is an request. 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.
11.2. Availability of good random numbers 11.2. DomainID must be resistant to second-preimage attacks
Although the nonce used by the Pledge in the voucher-request does not The domainID is used as the reference in the audit log to the domain.
require a strong cryptographic randomness, the use of TLS in all of The domainID is expected to be calculated by a hash that is resistant
the protocols in this document does. to a second-preimage attack. The consequences of such an attack
would allow a second registrar to create audit log entries that are
fake.
11.3. Availability of good random numbers
The nonce used by the Pledge in the voucher-request SHOULD be
generated by a Strong Cryptographic Sequence ([RFC4086] section 6.2).
TLS has a similar requirement.
In particular implementations should pay attention to the advance in In particular implementations should pay attention to the advance in
[RFC4086] section 3, particularly section 3.4. Devices which are [RFC4086] section 3, particularly section 3.4. Devices which are
reset to factory default in order to perform a second bootstrap with reset to factory default in order to perform a second bootstrap with
a new owner MUST NOT seed their random number generators in the same a new owner MUST NOT use idential seeds.
way across bootstraps.
11.3. Freshness in Voucher-Requests 11.4. 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 83, line 39 skipping to change at page 84, line 23
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 Retrieval and examination of MASA log information upon the o Retrieval and examination of MASA log information upon the
occurrence of any such unexpected events. Rm will be listed in occurrence of any such unexpected events. Rm will be listed in
the logs along with nonce information for analysis. the logs along with nonce information for analysis.
11.4. Trusting manufacturers 11.5. 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 84, line 42 skipping to change at page 85, line 25
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.
11.5. Manufacturer Maintenance of trust anchors 11.6. Manufacturer Maintenance of trust anchors
BRSKI depends upon the manufacturer building in trust anchors to the BRSKI depends upon the manufacturer building in trust anchors to the
pledge device. The voucher artifact which is signed by the MASA will pledge device. The voucher artifact which is signed by the MASA will
be validated by the pledge using that anchor. This implies that the be validated by the pledge using that anchor. This implies that the
manufacturer needs to maintain access to a signing key that the manufacturer needs to maintain access to a signing key that the
pledge can validate. pledge can validate.
The manufacturer will need to maintain the ability to make signatures The manufacturer will need to maintain the ability to make signatures
that can be validated for the lifetime that the device could be that can be validated for the lifetime that the device could be
onboarded. Whether this onboarding lifetime is less than the device onboarded. Whether this onboarding lifetime is less than the device
skipping to change at page 86, line 7 skipping to change at page 86, line 38
or how strong the economic incentives are to maintain an appropriate or how strong the economic incentives are to maintain an appropriate
level of security. level of security.
This next section examines the risk due to a compromised manufacturer This next section examines the risk due to a compromised manufacturer
IDevID signing key. This is followed by examination of the risk due IDevID signing key. This is followed by examination of the risk due
to a compromised MASA key. The third section sections below examines to a compromised MASA key. The third section sections below examines
the situation where MASA web server itself is under attacker control, the situation where MASA web server itself is under attacker control,
but that the MASA signing key itself is safe in a not-directly but that the MASA signing key itself is safe in a not-directly
connected hardware module. connected hardware module.
11.5.1. Compromise of Manufacturer IDevID signing keys 11.6.1. Compromise of Manufacturer IDevID signing keys
An attacker that has access to the key that the manufacturer uses to An attacker that has access to the key that the manufacturer uses to
sign IDevID certificates can create counterfeit devices. Such sign IDevID certificates can create counterfeit devices. Such
devices can claim to be from a particular manufacturer, but be devices can claim to be from a particular manufacturer, but be
entirely different devices: Trojan horses in effect. entirely different devices: Trojan horses in effect.
As the attacker controls the MASA URL in the certificate, the As the attacker controls the MASA URL in the certificate, the
registrar can be convinced to talk to the attackers' MASA. The registrar can be convinced to talk to the attackers' MASA. The
Registrar does not need to be in any kind of promiscuous mode to be Registrar does not need to be in any kind of promiscuous mode to be
vulnerable. vulnerable.
skipping to change at page 86, line 29 skipping to change at page 87, line 15
In addition to creating fake devices, the attacker may also be able In addition to creating fake devices, the attacker may also be able
to issue revocations for existing certificates if the IDevID to issue revocations for existing certificates if the IDevID
certificate process relies upon CRL lists that are distributed. certificate process relies upon CRL lists that are distributed.
There does not otherwise seem to be any risk from this compromise to There does not otherwise seem to be any risk from this compromise to
devices which are already deployed, or which are sitting locally in devices which are already deployed, or which are sitting locally in
boxes waiting for deployment (local spares). The issue is that boxes waiting for deployment (local spares). The issue is that
operators will be unable to trust devices which have been in an operators will be unable to trust devices which have been in an
uncontrolled warehouse as they do not know if those are real devices. uncontrolled warehouse as they do not know if those are real devices.
11.5.2. Compromise of MASA signing keys 11.6.2. Compromise of MASA signing keys
There are two periods of time in which to consider: when the MASA key There are two periods of time in which to consider: when the MASA key
has fallen into the hands of an attacker, and after the MASA has fallen into the hands of an attacker, and after the MASA
recognizes that the key has been compromised. recognizes that the key has been compromised.
11.5.2.1. Attacker opportunties with compromised MASA key 11.6.2.1. Attacker opportunties with compromised MASA key
An attacker that has access to the MASA signing key could create An attacker that has access to the MASA signing key could create
vouchers. These vouchers could be for existing deployed devices, or vouchers. These vouchers could be for existing deployed devices, or
for devices which are still in a warehouse. In order to exploit for devices which are still in a warehouse. In order to exploit
these vouchers two things need to occur: the device has to go through these vouchers two things need to occur: the device has to go through
a factory default boot cycle, and the registrar has to be convinced a factory default boot cycle, and the registrar has to be convinced
to contact the attacker's MASA. to contact the attacker's MASA.
If the attacker controls a Registrar which is visible to the device, If the attacker controls a Registrar which is visible to the device,
then there is no difficulty in delivery of the false voucher. A then there is no difficulty in delivery of the false voucher. A
skipping to change at page 87, line 32 skipping to change at page 88, line 17
devices with low overall implementation quality, the end users might devices with low overall implementation quality, the end users might
be familiar with needing to reset the device regularly. be familiar with needing to reset the device regularly.
The authors are unable to come up with an attack scenario where a The authors are unable to come up with an attack scenario where a
compromised voucher signature enables an attacker to introduce a compromised voucher signature enables an attacker to introduce a
compromised pledge into an existing operator's network. This is the compromised pledge into an existing operator's network. This is the
case because the operator controls the communication between case because the operator controls the communication between
Registrar and MASA, and there is no opportunity to introduce the fake Registrar and MASA, and there is no opportunity to introduce the fake
voucher through that conduit. voucher through that conduit.
11.5.2.2. Risks after key compromise is known 11.6.2.2. Risks after key compromise is known
Once the operator of the MASA realizes that the voucher signing key Once the operator of the MASA realizes that the voucher signing key
has been compromised it has to do a few things. has been compromised it has to do a few things.
First, it MUST issue a firmware update to all devices that had that First, it MUST issue a firmware update to all devices that had that
key as a trust anchor, such that they will no longer trust vouchers key as a trust anchor, such that they will no longer trust vouchers
from that key. This will affect devices in the field which are from that key. This will affect devices in the field which are
operating, but those devices, being in operation, are not performing operating, but those devices, being in operation, are not performing
onboarding operations, so this is not a critical patch. onboarding operations, so this is not a critical patch.
skipping to change at page 88, line 26 skipping to change at page 89, line 10
such a thing. such a thing.
A key operational recommendation is for manufacturers to sign A key operational recommendation is for manufacturers to sign
nonceless, long-lived vouchers with a different key that they sign nonceless, long-lived vouchers with a different key that they sign
short-lived vouchers. That key needs significantly better short-lived vouchers. That key needs significantly better
protection. If both keys come from a common trust-anchor (the protection. If both keys come from a common trust-anchor (the
manufacturer's CA), then a compromise of the manufacturer's CA would manufacturer's CA), then a compromise of the manufacturer's CA would
compromise both keys. Such a compromise of the manufacturer's CA compromise both keys. Such a compromise of the manufacturer's CA
likely compromises all keys outlined in this section. likely compromises all keys outlined in this section.
11.5.3. Compromise of MASA web service 11.6.3. Compromise of MASA web service
An attacker that takes over the MASA web service has a number of An attacker that takes over the MASA web service has a number of
attacks. The most obvious one is simply to take the database listing attacks. The most obvious one is simply to take the database listing
customers and devices and to sell this data to other attackers who customers and devices and to sell this data to other attackers who
will now know where to find potentially vulnerable devices. will now know where to find potentially vulnerable devices.
The second most obvious thing that the attacker can do is to kill the The second most obvious thing that the attacker can do is to kill the
service, or make it operate unreliably, making customers frustrated. service, or make it operate unreliably, making customers frustrated.
This could have a serious affect on ability to deploy new services by This could have a serious affect on ability to deploy new services by
customers, and would be a significant issue during disaster recovery. customers, and would be a significant issue during disaster recovery.
skipping to change at page 93, line 40 skipping to change at page 94, line 24
operator-v2.0.pdf>. operator-v2.0.pdf>.
[docsisroot] [docsisroot]
"CableLabs Digital Certificate Issuance Service", February "CableLabs Digital Certificate Issuance Service", February
2018, <https://www.cablelabs.com/resources/digital- 2018, <https://www.cablelabs.com/resources/digital-
certificate-issuance-service/>. 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-15 (work in progress), October 2019. est-16 (work in progress), October 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 94, line 13 skipping to change at page 94, line 46
progress), November 2018. progress), November 2018.
[I-D.ietf-anima-stable-connectivity] [I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf- Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-10 (work in progress), February anima-stable-connectivity-10 (work in progress), February
2018. 2018.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "A YANG Data Model for a Keystore", draft- Watsen, K., "A YANG Data Model for a Keystore", draft-
ietf-netconf-keystore-12 (work in progress), July 2019. ietf-netconf-keystore-14 (work in progress), November
2019.
[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 article: Imprinting", July 2015, "Wikipedia article: Imprinting", July 2015,
<https://en.wikipedia.org/wiki/Imprinting_(psychology)>. <https://en.wikipedia.org/wiki/Imprinting_(psychology)>.
skipping to change at page 102, line 12 skipping to change at page 102, 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 Fountain CA Issuer: DC = ca, DC = sandelman, CN = Unstrung Fount
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:
 End of changes. 56 change blocks. 
92 lines changed or deleted 120 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/