draft-ietf-anima-bootstrapping-keyinfra-12.txt   draft-ietf-anima-bootstrapping-keyinfra-13.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: September 6, 2018 SSW Expires: September 27, 2018 Sandelman
M. Behringer M. Behringer
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
K. Watsen K. Watsen
Juniper Networks Juniper Networks
March 5, 2018 March 26, 2018
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-12 draft-ietf-anima-bootstrapping-keyinfra-13
Abstract Abstract
This document specifies automated bootstrapping of a remote secure This document specifies automated bootstrapping of a remote secure
key infrastructure (BRSKI) using manufacturer installed X.509 key infrastructure (BRSKI) using manufacturer installed X.509
certificate, in combination with a manufacturer's authorizing certificate, in combination with a manufacturer's authorizing
service, both online and offline. Bootstrapping a new device can service, both online and offline. Bootstrapping a new device can
occur using a routable address and a cloud service, or using only occur using a routable address and a cloud service, or using only
link-local connectivity, or on limited/disconnected networks. link-local connectivity, or on limited/disconnected networks.
Support for lower security models, including devices with minimal Support for lower security models, including devices with minimal
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on September 27, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 9 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 9
1.3.1. Support enironment . . . . . . . . . . . . . . . . . 9 1.3.1. Support environment . . . . . . . . . . . . . . . . . 9
1.3.2. Constrained enironments . . . . . . . . . . . . . . . 9 1.3.2. Constrained environments . . . . . . . . . . . . . . 10
1.3.3. Network Access Controls . . . . . . . . . . . . . . . 10 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 10
1.4. Leveraging the new key infrastructure / next steps . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 11 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 12
2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 13 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 13
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 14 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 15
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 15 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 16
2.3.1. Identification of the Pledge . . . . . . . . . . . . 15 2.3.1. Identification of the Pledge . . . . . . . . . . . . 16
2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 16 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 17
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 17 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1. Architectural component: Pledge . . . . . . . . . . . 19 2.5. Architectural Components . . . . . . . . . . . . . . . . 20
2.4.2. Architectural component: Circuit Proxy . . . . . . . 19 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3. Architectural component: Domain Registrar . . . . . . 19 2.5.2. Circuit Proxy . . . . . . . . . . . . . . . . . . . . 20
2.4.4. Architectural component: Manufacturer Service . . . . 19 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 20
2.4.5. Architectural component: Public Key Infrastructure 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 20
(PKI) . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 20
2.5. Certificate Time Validation . . . . . . . . . . . . . . . 20 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 21
2.5.1. Lack of realtime clock . . . . . . . . . . . . . . . 20 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 21
2.5.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 20 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 23
2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 21 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 23
2.7. Determining the MASA to contact . . . . . . . . . . . . . 21 2.8. Determining the MASA to contact . . . . . . . . . . . . . 23
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 22 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 24
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 22 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27
4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 28 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 30
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 29 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 31
4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 30 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 32
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 31 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 33
4.3. Proxy discovery of Registrar . . . . . . . . . . . . . . 31 4.3. Proxy discovery of Registrar . . . . . . . . . . . . . . 33
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 33 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 35
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 35 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 37
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 35 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 37
5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 36 5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 39
5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 37 5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 39
5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 39 5.4.1. Renew for expired voucher . . . . . . . . . . . . . . 41
5.4.2. Voucher signature consistency . . . . . . . . . . . . 41
5.4.3. Registrar revocation consistency . . . . . . . . . . 41
5.4.4. Pledge proximity assertion . . . . . . . . . . . . . 42
5.4.5. Registar (certificate) authentication . . . . . . . . 42
5.4.6. Registrar Anchor . . . . . . . . . . . . . . . . . . 42
5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 42
5.5.1. Completing authentication of Provisional TLS 5.5.1. Completing authentication of Provisional TLS
connection . . . . . . . . . . . . . . . . . . . . . 41 connection . . . . . . . . . . . . . . . . . . . . . 44
5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 41 5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 45
5.7. MASA authorization log Request . . . . . . . . . . . . . 42 5.7. MASA authorization log Request . . . . . . . . . . . . . 45
5.7.1. MASA authorization log Response . . . . . . . . . . . 43 5.7.1. MASA authorization log Response . . . . . . . . . . . 46
5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 45 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 48
5.8.1. EST Distribution of CA Certificates . . . . . . . . . 45 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 48
5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 46 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 49
5.8.3. EST Client Certificate Request . . . . . . . . . . . 47 5.8.3. EST Client Certificate Request . . . . . . . . . . . 50
5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 47 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 50
5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 48 5.8.5. Multiple certificates . . . . . . . . . . . . . . . . 51
6. Reduced security operational modes . . . . . . . . . . . . . 48 5.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 51
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 48 6. Reduced security operational modes . . . . . . . . . . . . . 51
6.2. Pledge security reductions . . . . . . . . . . . . . . . 49 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 51
6.3. Registrar security reductions . . . . . . . . . . . . . . 50 6.2. Pledge security reductions . . . . . . . . . . . . . . . 52
6.4. MASA security reductions . . . . . . . . . . . . . . . . 50 6.3. Registrar security reductions . . . . . . . . . . . . . . 53
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 6.4. MASA security reductions . . . . . . . . . . . . . . . . 54
7.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 51 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
7.2. Voucher Status Telemetry . . . . . . . . . . . . . . . . 52 7.1. Well-known EST registration . . . . . . . . . . . . . . . 54
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52 7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 55
8.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 54 7.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 55
8.2. Trusting manufacturers . . . . . . . . . . . . . . . . . 55 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 55
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 8.1. MASA authorization log . . . . . . . . . . . . . . . . . 55
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 9. Security Considerations . . . . . . . . . . . . . . . . . . . 56
10.1. Normative References . . . . . . . . . . . . . . . . . . 56 9.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 57
10.2. Informative References . . . . . . . . . . . . . . . . . 59 9.2. Trusting manufacturers . . . . . . . . . . . . . . . . . 58
Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 61 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 61 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 61 11.1. Normative References . . . . . . . . . . . . . . . . . . 60
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 61 11.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 62
C.1. Multiple Join networks on the Join Proxy side . . . . . . 62
C.2. Automatic configuration of tunnels on Registrar . . . . . 63
C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 63
C.4. Use of connected sockets; or IP_PKTINFO for CoAP on
Registrar . . . . . . . . . . . . . . . . . . . . . . . . 64
C.5. Use of socket extension rather than virtual interface . . 64 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 64
Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 64 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 64
Appendix E. Example Vouchers . . . . . . . . . . . . . . . . . . 66 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 64
E.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 66 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 65
E.1.1. MASA key pair for voucher signatures . . . . . . . . 66 Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 65
E.1.2. Manufacturer key pair for IDevID signatures . . . . . 66 C.1. Multiple Join networks on the Join Proxy side . . . . . . 66
E.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 67 C.2. Automatic configuration of tunnels on Registrar . . . . . 67
E.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 69 C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 67
E.2. Example process . . . . . . . . . . . . . . . . . . . . . 70 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on
E.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 70 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 67
E.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 76 C.5. Use of socket extension rather than virtual interface . . 68
E.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 82 Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87 Appendix E. Example Vouchers . . . . . . . . . . . . . . . . . . 70
E.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 70
E.1.1. MASA key pair for voucher signatures . . . . . . . . 70
E.1.2. Manufacturer key pair for IDevID signatures . . . . . 70
E.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 71
E.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 73
E.2. Example process . . . . . . . . . . . . . . . . . . . . . 74
E.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 74
E.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 80
E.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91
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. These Pledges need to 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 (Domain Join) the bootstrap. This element (device) is called the Registrar.
Registrar. Before any other operation, Pledge and Registrar need to Before any other operation, Pledge and Registrar need to establish
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 authoring the Pledge: "Is it mine? Do I want it? What 2. Registrar authorizing the Pledge: "Is it mine? Do I want it?
are the chances it has been compromised?" What are the chances it has been compromised?"
3. Pledge authenticating the Registrar/Domain: "What is this 3. Pledge authenticating the Registrar/Domain: "What is this
domain's identity?" domain's identity?"
4. Pledge authorizing the Registrar: "Should I join it?" 4. Pledge authorizing the Registrar: "Should I join it?"
This document details protocols and messages to answer the above This document details protocols and messages to answer the above
questions. It uses a TLS connection and an PKIX (X.509v3) questions. It uses a TLS connection and an PKIX (X.509v3)
certificate (an IEEE 802.1AR [IDevID] LDevID) of the Pledge to answer certificate (an IEEE 802.1AR [IDevID] LDevID) of the Pledge to answer
points 1 and 2. It uses a new artifact called a "voucher" that the points 1 and 2. It uses a new artifact called a "voucher" that the
skipping to change at page 5, line 41 skipping to change at page 6, line 5
manner. Existing automated mechanisms are known as non-secured manner. Existing automated mechanisms are known as non-secured
'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling'
[Stajano99theresurrecting] or 'pre-staging'. [Stajano99theresurrecting] or 'pre-staging'.
Another prior approach has been to try and minimize user actions Another prior approach has been to try and minimize user actions
during bootstrapping, but not eliminate all user-actions. The during bootstrapping, but not eliminate all user-actions. The
original EST protocol [RFC7030] does reduce user actions during original EST protocol [RFC7030] does reduce user actions during
bootstrap but does not provide solutions for how the following bootstrap but does not provide solutions for how the following
protocol steps can be made autonomic (not involving user actions): protocol steps can be made autonomic (not involving user actions):
o using the Implicit Trust Anchor database (not an autonomic o using the Implicit Trust Anchor database to authenticate an owner
solution because the URL must be securely distributed), specific service (not an autonomic solution because the URL must
be securely distributed),
o engaging a human user to authorize the CA certificate using out- o engaging a human user to authorize the CA certificate using out-
of-band data (not an autonomic solution because the human user is of-band data (not an autonomic solution because the human user is
involved), involved),
o using a configured Explicit TA database (not an autonomic solution o using a configured Explicit TA database (not an autonomic solution
because the distribution of an explicit TA database is not because the distribution of an explicit TA database is not
autonomic), autonomic),
o and using a Certificate-Less TLS mutual authentication method (not o and using a Certificate-Less TLS mutual authentication method (not
skipping to change at page 7, line 26 skipping to change at page 7, line 38
Pledge: The prospective device, which has an identity installed at Pledge: The prospective device, which has an identity installed at
the factory. the factory.
Voucher: A signed artifact from the MASA that indicates to a Pledge Voucher: A signed artifact from the MASA that indicates to a Pledge
the cryptographic identity of the Registrar it should trust. the cryptographic identity of the Registrar it should trust.
There are different types of vouchers depending on how that trust There are different types of vouchers depending on how that trust
is asserted. Multiple voucher types are defined in is asserted. Multiple voucher types are defined in
[I-D.ietf-anima-voucher] [I-D.ietf-anima-voucher]
Domain: The set of entities that trust a common key infrastructure Domain: The set of entities that share a common local trust anchor.
trust anchor. This includes the Proxy, Registrar, Domain This includes the Proxy, Registrar, Domain Certificate Authority,
Certificate Authority, Management components and any existing Management components and any existing entity that is already a
entity that is already a member of the domain. member of the domain.
Domain CA: The domain Certification Authority (CA) provides Domain CA: The domain Certification Authority (CA) provides
certification functionalities to the domain. At a minimum it certification functionalities to the domain. At a minimum it
provides certification functionalities to a Registrar and stores provides certification functionalities to a Registrar and manages
the trust anchor that defines the domain. Optionally, it the private key that defines the domain. Optionally, it certifies
certifies all elements. all elements.
Join Registrar (and Coordinator): A representative of the domain Join Registrar (and Coordinator): A representative of the domain
that is configured, perhaps autonomically, to decide whether a new that is configured, perhaps autonomically, to decide whether a new
device is allowed to join the domain. The administrator of the device is allowed to join the domain. The administrator of the
domain interfaces with a Join Registrar (and Coordinator) to domain interfaces with a Join Registrar (and Coordinator) to
control this process. Typically a Join Registrar is "inside" its control this process. Typically a Join Registrar is "inside" its
domain. For simplicity this document often refers to this as just domain. For simplicity this document often refers to this as just
"Registrar". The term JRC is used in common with other bootstrap "Registrar". Within [I-D.ietf-anima-reference-model] this is
mechanisms. refered to as the Join Registrar Autonomic Service Agent.
(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. In an ANIMA that sustain the activities of a public key system. The Join
Autonomic system, this includes a Domain Certification Authority Registrar (and Coordinator) acts as an [RFC5280] and [RFC5272]
(CA), (Join) Registrar which acts as an [RFC5280] Registrar, as (see section 7) "Registration Authority".
well as appropriate certificate revocation list (CRL) distribution
points and/or OCSP ([RFC6960]) servers.
Join Proxy: A domain entity that helps the Pledge join the domain. Join Proxy: A domain entity that helps the Pledge join the domain.
A Proxy facilitates communication for devices that find themselves A Proxy facilitates communication for devices that find themselves
in an environment where they are not provided connectivity until in an environment where they are not provided connectivity until
after they are validated as members of the domain. The Pledge is after they are validated as members of the domain. The Pledge is
unaware that they are communicating with a Proxy rather than unaware that they are communicating with a Proxy rather than
directly with a Registrar. directly with a Registrar.
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
skipping to change at page 9, line 12 skipping to change at page 9, line 24
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.
ANI: The Autonomic Network Infrastructure as defined by ANI: The Autonomic Network Infrastructure as defined by
[I-D.ietf-anima-autonomic-control-plane]. This document details [I-D.ietf-anima-autonomic-control-plane]. This document details
specific requirements for pledges, proxies and registrars when specific requirements for pledges, proxies and registrars when
they are part of an ANI. they are part of an ANI.
1.3. Scope of solution 1.3. Scope of solution
1.3.1. Support enironment 1.3.1. Support environment
This solution (BRSKI) can support large router platforms with multi- This solution (BRSKI) can support large router platforms with multi-
gigabit inter-connections, mounted in controlled access data centers. gigabit inter-connections, mounted in controlled access data centers.
But this solution is not exclusive to large equipment: it is intended But this solution is not exclusive to large equipment: it is intended
to scale to thousands of devices located in hostile environments, to scale to thousands of devices located in hostile environments,
such as ISP provided CPE devices which are drop-shipped to the end such as ISP provided CPE devices which are drop-shipped to the end
user. The situation where an order is fulfilled from distributed user. The situation where an order is fulfilled from distributed
warehouse from a common stock and shipped directly to the target warehouse from a common stock and shipped directly to the target
location at the request of a domain owner is explicitly supported. location at the request of a domain owner is explicitly supported.
That stock ("SKU") could be provided to a number of potential domain That stock ("SKU") could be provided to a number of potential domain
skipping to change at page 9, line 41 skipping to change at page 10, line 5
Nomadic or mobile devices often need to aquire credentials to access Nomadic or mobile devices often need to aquire credentials to access
the network at the new location. An example of this is mobile phone the network at the new location. An example of this is mobile phone
roaming among network operators, or even between cell towers. This roaming among network operators, or even between cell towers. This
is usually called handoff. BRSKI does not provide a low-latency is usually called handoff. BRSKI does not provide a low-latency
handoff which is usually a requirement in such situations. For these handoff which is usually a requirement in such situations. For these
solutions BRSKI can be used to create a relationship (an LDevID) with solutions BRSKI can be used to create a relationship (an LDevID) with
the "home" domain owner. The resulting credentials are then used to the "home" domain owner. The resulting credentials are then used to
provide credentials more appropriate for a low-latency handoff. provide credentials more appropriate for a low-latency handoff.
1.3.2. Constrained enironments 1.3.2. Constrained environments
Questions have been posed as to whether this solution is suitable in Questions have been posed as to whether this solution is suitable in
general for Internet of Things (IoT) networks. This depends on the general for Internet of Things (IoT) networks. This depends on the
capabilities of the devices in question. The terminology of capabilities of the devices in question. The terminology of
[RFC7228] is best used to describe the boundaries. [RFC7228] is best used to describe the boundaries.
The solution described in this document is aimed in general at non- The solution described in this document is aimed in general at non-
constrained (i.e., class 2+) devices operating on a non-Challenged constrained (i.e., class 2+) devices operating on a non-Challenged
network. The entire solution as described here is not intended to be network. The entire solution as described here is not intended to be
useable as-is by constrained devices operating on challenged networks useable as-is by constrained devices operating on challenged networks
skipping to change at page 10, line 40 skipping to change at page 11, line 8
Identity is consistant with IEEE 802.1AR [IDevID], and allows for Identity is consistant with IEEE 802.1AR [IDevID], and allows for
alignment with 802.1X network access control methods, its use here is alignment with 802.1X network access control methods, its use here is
for Pledge authentication rather than network access control. for Pledge authentication rather than network access control.
Integrating this protocol with network access control, perhaps as an Integrating this protocol with network access control, perhaps as an
Extensible Authentication Protocol (EAP) method (see [RFC3748]), is Extensible Authentication Protocol (EAP) method (see [RFC3748]), is
out-of-scope. out-of-scope.
1.4. Leveraging the new key infrastructure / next steps 1.4. Leveraging the new key infrastructure / next steps
As a result of the protocol described herein, the bootstrapped As a result of the protocol described herein, the bootstrapped
devices have a common trust anchor and a certificate has optionally devices have the Domain CA trust anchor in common. An end entity
been issued from a local PKI. This makes it possible to certificate has optionally been issued from the Domain CA. This
automatically deploy services across the domain in a secure manner. makes it possible to automatically deploy services across the domain
in a secure manner.
Services that benefit from this: Services that benefit from this:
o Device management. o Device management.
o Routing authentication. o Routing authentication.
o Service discovery. o Service discovery.
The major beneficiary is that it possible to use the credentials The major beneficiary is that it possible to use the credentials
skipping to change at page 11, line 32 skipping to change at page 11, line 48
o BRSKI: Request Voucher o BRSKI: Request Voucher
o EST: CA Certificates Request o EST: CA Certificates Request
o EST: CSR Attributes o EST: CSR Attributes
o EST: Client Certificate Request o EST: Client Certificate Request
o BRSKI: Enrollment status Telemetry o BRSKI: Enrollment status Telemetry
The ANI Registrar (JRC) MUST support all the BRSKI and above listed The ANI Join Registrar ASA MUST support all the BRSKI and above
EST operations. listed EST operations.
All ANI devices SHOULD support the BRSKI proxy function, using All ANI devices SHOULD support the BRSKI proxy function, using
circuit proxies. Other proxy methods are optional, and may be circuit proxies. Other proxy methods are optional, and MUST NOT
enabled only if the JRC indicates support for them in it's enabled unless the Join Registrar ASA indicates support for them in
announcement. (See Section 4.3) it's announcement. (See Section 4.3)
2. Architectural Overview 2. Architectural Overview
The logical elements of the bootstrapping framework are described in The logical elements of the bootstrapping framework are described in
this section. Figure 1 provides a simplified overview of the this section. Figure 1 provides a simplified overview of the
components. components.
+------------------------+ +------------------------+
+--------------Drop Ship--------------->| Vendor Service | +--------------Drop Ship--------------->| Vendor Service |
| +------------------------+ | +------------------------+
skipping to change at page 14, line 30 skipping to change at page 15, line 25
5. Enroll. By accepting the domain specific information from a 5. Enroll. By accepting the domain specific information from a
Registrar, and by obtaining a domain certificate from a Registrar Registrar, and by obtaining a domain certificate from a Registrar
using a standard enrollment protocol, e.g. Enrollment over using a standard enrollment protocol, e.g. Enrollment over
Secure Transport (EST) [RFC7030]. Secure Transport (EST) [RFC7030].
6. The Pledge is now a member of, and can be managed by, the domain 6. The Pledge is now a member of, and can be managed by, the domain
and will only repeat the discovery aspects of bootstrapping if it and will only repeat the discovery aspects of bootstrapping if it
is returned to factory default settings. is returned to factory default settings.
After step 4, the pledge has received and authenticated an explicit After step 4, the pledge has received and authenticated an explicit
TA (trust anchor) (pinned-domain-cert in the Voucher response). A trust anchor (the pinned-domain-cert in the Voucher response). A
secure transport exists between pledge and registrar, and it may be secure transport exists between pledge and registrar, and it may be
used for things other than enrollment into a PKI. used for things other than enrollment into a PKI.
2.2. Secure Imprinting using Vouchers 2.2. Secure Imprinting using Vouchers
A voucher is a cryptographically protected artifact (a digital A voucher is a cryptographically protected artifact (a digital
signature) to the Pledge device authorizing a zero-touch imprint on signature) to the Pledge device authorizing a zero-touch imprint on
the Registrar domain. the Registrar domain.
The format and cryptographic mechanism of vouchers is described in The format and cryptographic mechanism of vouchers is described in
skipping to change at page 16, line 6 skipping to change at page 16, line 50
2.3.1. Identification of the Pledge 2.3.1. Identification of the Pledge
In the context of BRSKI, pledges are uniquely identified by a In the context of BRSKI, pledges are uniquely identified by 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 following fields are defined in [IDevID] and [RFC5280]: The following fields are defined in [IDevID] and [RFC5280]:
o The subject field's DN encoding MUST include the "serialNumber" o The subject field's DN encoding MUST include the "serialNumber"
attribute with the device's unique serial number. attribute with the device's unique serial number. (from [IDevID]
section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard
attributes)
o The subject-alt field's encoding SHOULD include a non-critical o The subject-alt field's encoding MAY include a non-critical
version of the RFC4108 defined HardwareModuleName. version of the RFC4108 defined HardwareModuleName. (from [IDevID]
section 7.2.9) If the IDevID is stored in a Trusted Platform
Module (TPM), then this field MAY contain the TPM identification
rather than the device's serial number. If both fields are
present, then the subject field takes precedence.
and they are used as follows to build pledge "serial-number". In and they are used as follows to build pledge "serial-number". In
order to build it, the fields need to be converted into a serial- order to build it, the fields need to be converted into a serial-
number of "type string". The following methods are used depending on number of "type string". The following methods are used depending on
the first available IDevID certificate field (attempted in this the first available IDevID certificate field (attempted in this
order): order):
o An RFC4514 String Representation of the Distinguished Name 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the
"serialNumber" attribute. Distinguished Name "serialNumber" attribute, formatted according
to RFC4514 rules.
o The HardwareModuleName hwSerialNum OCTET STRING base64 encoded.
o The RFC4514 String Representation of the Distinguished Name 2. The HardwareModuleName hwSerialNum OCTET STRING, base64 encoded.
"common name" attribute.
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 19, line 5 skipping to change at page 20, line 5
|---------------------------------------->| | |---------------------------------------->| |
| [voucher status telemetry] |<-device audit log--| | [voucher status telemetry] |<-device audit log--|
| | [verify audit log and voucher] | | | [verify audit log and voucher] |
|<--------------------------------------->| | |<--------------------------------------->| |
| Continue with RFC7030 enrollment | | | Continue with RFC7030 enrollment | |
| using now bidirectionally authenticated | | | using now bidirectionally authenticated | |
| TLS session. | | | | TLS session. | | |
Figure 3 Figure 3
2.4.1. Architectural component: Pledge 2.5. Architectural Components
2.5.1. Pledge
The Pledge is the device that is attempting to join. Until the The Pledge is the device that is attempting to join. Until the
Pledge completes the enrollment process, it has link-local network Pledge completes the enrollment process, it has link-local network
connectivity only to the Proxy. connectivity only to the Proxy.
2.4.2. Architectural component: Circuit Proxy 2.5.2. Circuit Proxy
The (Circuit) Proxy provides HTTPS connectivity between the Pledge The (Circuit) Proxy provides HTTPS connectivity between the Pledge
and the Registrar. The circuit proxy mechanism is described in and the Registrar. The circuit proxy mechanism is described in
Section 4, with an optional stateless proxy mechanism described in Section 4, with an optional stateless proxy mechanism described in
Appendix C. Appendix C.
2.4.3. Architectural component: Domain Registrar 2.5.3. Domain Registrar
The Domain Registrar (having the formal name Join Registrar/ The domain's Registrar operates as the BRSKI-MASA client when
Coordinator (JRC)), operates as a CMC Registrar, (Certificate requesting vouchers from the MASA (see Section 5.3). The Registrar
Management over CMS, see [RFC5272] section 7) terminating the EST and operates as the BRSKI-EST server when Pledges request vouchers (see
BRSKI connections. The Registrar is manually configured or Section 5.1). The Registrar operates as the BRSKI-EST server
distributed with a list of trust anchors necessary to authenticate "Registration Authority" if the Pledge requests an end entity
any Pledge device expected on the network. The Registrar certificate over the BRSKI-EST connection (see Section 5.8).
communicates with the MASA to establish ownership.
2.4.4. Architectural component: Manufacturer Service The Registar uses an Implicit Trust Anchor database for
authenticating the BRSKI-MASA TLS connection MASA server certificate.
The Registrar uses a different Implicit Trust Anchor database for
authenticating the BRSKI-EST TLS connection Pledge client
certificate. Configuration or distribution of these trust anchor
databases is out-of-scope of this specification.
2.5.4. Manufacturer Service
The Manufacturer Service provides two logically seperate functions: The Manufacturer Service provides two logically seperate functions:
the Manufacturer Authorized Signing Authority (MASA) described in the Manufacturer Authorized Signing Authority (MASA) described in
Section 5.4 and Section 5.5, and an ownership tracking/auditing Section 5.4 and Section 5.5, and an ownership tracking/auditing
function described in Section 5.6 and Section 5.7. function described in Section 5.6 and Section 5.7.
2.4.5. Architectural component: Public Key Infrastructure (PKI) 2.5.5. Public Key Infrastructure (PKI)
The Key Infrastructure (PKI) administers certificates for the domain The Key Infrastructure (PKI) administers certificates for the domain
of concerns, providing the trust anchor(s) for it and allowing of concerns, providing the trust anchor(s) for it and allowing
enrollment of Pledges with domain certificates. enrollment of Pledges with domain certificates.
The Domain Registrar uses a Trust Anchor (TE) from the PKI in the The domain's Registrar uses the "pinned-domain-cert" voucher field to
BRSKI Voucher pinned-domain-cert to authenticate itself to the Pledge distribute a trust anchor for authenticating itself to the Pledge.
with the help of MASA. (XXX fix me)
The Domain Registrar acts as an [RFC5272] Registration Authority, The domain's Registrar acts as an [RFC5272] Registration Authority,
requesting certificates for Pledges from the Key Infrastructure. requesting certificates for Pledges from the Key Infrastructure.
The above requirements and expectations against the Key The above requirements and expectations against the Key
Infrastructure are unchanged from RFC7030. This document does not Infrastructure are unchanged from RFC7030. This document does not
place any additional architectural requirements on the Public Key place any additional architectural requirements on the Public Key
Infrastructure. Infrastructure.
2.5. Certificate Time Validation 2.6. Certificate Time Validation
2.5.1. Lack of realtime clock 2.6.1. Lack of realtime clock
Many devices when bootstrapping do not have knowledge of the current Many devices when bootstrapping do not have knowledge of the current
time. Mechanisms such as Network Time Protocols cannot be secured time. Mechanisms such as Network Time Protocols cannot be secured
until bootstrapping is complete. Therefore bootstrapping is defined until bootstrapping is complete. Therefore bootstrapping is defined
in a method that does not require knowledge of the current time. in a method that does not require knowledge of the current time.
Unfortunately there are moments during bootstrapping when Unfortunately there are moments during bootstrapping when
certificates are verified, such as during the TLS handshake, where certificates are verified, such as during the TLS handshake, where
validity periods are confirmed. This paradoxical "catch-22" is validity periods are confirmed. This paradoxical "catch-22" is
resolved by the Pledge maintaining a concept of the current "window" resolved by the Pledge maintaining a concept of the current "window"
skipping to change at page 20, line 29 skipping to change at page 21, line 37
bootstrapping process as follows: bootstrapping process as follows:
o Initially the Pledge does not know the current time. o Initially the Pledge does not know the current time.
o Bootstrapping Pledges that have a Realtime Clock (RTC), SHOULD use o Bootstrapping Pledges that have a Realtime Clock (RTC), SHOULD use
it to verify certificate validity. However, they MUST be prepared it to verify certificate validity. However, they MUST be prepared
for the recognize that the RTC might be completely wrong when a for the recognize that the RTC might be completely wrong when a
RTC battery fails and resets to an origin time (e.g., Jan. 1, RTC battery fails and resets to an origin time (e.g., Jan. 1,
1970) 1970)
o The Pledge authenticates the voucher presented to it. During this o If the Pledge has any stable storage (such as from where firmware
authentication the Pledge ignores certificate lifetimes (by is loaded) then it SHOULD assume that the clock CAN NOT be before
necessity because it does not have a realtime clock). the date at which the firmware or the the storage was last time
stamped. The Pledge SHOULD NOT update the timestamps in any file
systems until it has a secure time source. This provides an
earliest date which is reasonable. Call this the current
reasonable date (CRD). This value SHOULD NOT be stored in any
way, and applies to the current Registration attempt only.
Subsequent attempts MUST follow this proceedure again from
scratch. The current reasonable date may only increase.
o The Pledge is exposed to dates in the following five places
(Registrar certificate, notBefore and notAfter. Voucher created-
on, and expires-on. Additionally, CMS signatures contain a
signingTime)
o During the initial connection with the Registrar, the Pledge sees
the Registrar Certificate. It has an inception date (notBefore)
and an expiry date (notAfter). It is reasonable that the
notBefore date be after the Pledge's current working reasonable
date. It is however, suspicious for the notAfter date to be
before the Pledge's current reasonable date. No action is
recommended, other than an internal audit entry for this.
o If the notBefore date of the Registrar's certificate is newer than
the Pledge's reasonable date, then it MAY update it's current
reasonable date to the notBefore value.
o After the voucher request process, the pledge will have a voucher.
It can validate the signature on the voucher, as it has been (by
literal construction) provided with the MASA's key as a trust
anchor. The time values (created-on, expires-on) in the voucher
can not in general be validated as the Pledge has no certain real
time clock. There are some reasonable assumptions that can be
made: the voucher's expires-on time can not be prior to the the
Pledge's current reasonable date. For nonceless vouchers, the
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
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). 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
current reasonable date. In addition, when there is a valid
nonce, the current reasonable date MAY be incremented to that of
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. Any domain-cert in the voucher now serves as a valid time window. As
subsequent certificate validity periods checked during RFC5280 explained in Section 5.4.3, the MASA has checked the Registrar's
path validation MUST occur within this window. certificate against real clocks , the endorsement of the MASA
allows the Pledge to treat the notBefore and notAfter dates as
being constrained on any subsequent certificate validity periods
that may need to be checked: for instance, validating peer
certificates during ANIMA ACP setup.
o When accepting an enrollment certificate the validity period o When accepting an enrollment certificate the validity period
within the new certificate is assumed to be valid by the Pledge. within the new certificate is assumed to be valid by the Pledge.
The Pledge is now willing to use this credential for client The Pledge is now willing to use this credential for client
authentication. authentication.
2.5.2. Infinite Lifetime of IDevID o
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". Registrars assigned the GeneralizedTime value of 99991231235959Z". Registrars
MUST support such lifetimes and SHOULD support ignoring Pledge MUST support such lifetimes and SHOULD support ignoring Pledge
lifetimes if they did not follow the RFC5280 recommendations. lifetimes if they did not follow the RFC5280 recommendations.
For example, IDevID may have incorrect lifetime of N <= 3 years, For example, IDevID may have incorrect lifetime of N <= 3 years,
rendering replacement Pledges from storage useless after N years rendering replacement Pledges from storage useless after N years
unless registrars support ignoring such a lifetime. unless registrars support ignoring such a lifetime.
2.6. Cloud Registrar 2.7. Cloud Registrar
There are transitional situations where devices may be deployed into There exist operationally open network wherein device gains
legacy networks that use proprietary bootstrapping mechanisms based unauthenticated access to the internet at large. In these use cases
upon the base EST ([RFC7030]). The same device may also be deployed the management domain for the device needs to be discovered within
into an ANIMA environment. This may be due to incremental the larger internet. These are less likely within the anima scope
replacement of a legacy situation with ANIMA. but may be more important in the future.
There are additionally some greenfield situations involving an There are additionally some greenfield situations involving an
entirely new installation where a device may have some kind of entirely new installation where a device may have some kind of
management uplink that it can use (such as via 3G network for management uplink that it can use (such as via 3G network for
instance). In such a future situation, the device might use this instance). In such a future situation, the device might use this
management interface to learn that it should configure itself by to- management interface to learn that it should configure itself by to-
be-determined mechanism (such as an Intent) to become the local be-determined mechanism (such as an Intent) to become the local
Registrar. Registrar.
In order to support these scenarios, the Pledge MAY contact a well In order to support these scenarios, the Pledge MAY contact a well
known URI of a cloud Registrar if a local Registrar cannot be known URI of a cloud Registrar if a local Registrar cannot be
discovered or if the Pledge's target use cases do not include a local discovered or if the Pledge's target use cases do not include a local
Registrar. Registrar.
If the Pledge uses a well known URI for contacting a cloud Registrar If the Pledge uses a well known URI for contacting a cloud Registrar
an Implicit Trust Anchor database (see [RFC7030]) MUST be used to an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
authenticate service as described in [RFC6125]. This is consistent authenticate service as described in [RFC6125]. This is consistent
with the human user configuration of an EST server URI in [RFC7030] with the human user configuration of an EST server URI in [RFC7030]
which also depends on RFC6125. which also depends on RFC6125.
2.7. Determining the MASA to contact 2.8. Determining the MASA to contact
The Registrar needs to be able to contact a MASA that is trusted by The Registrar needs to be able to contact a MASA that is trusted by
the Pledge in order to obtain vouchers. There are three mechanisms the Pledge in order to obtain vouchers. There are three mechanisms
described: described:
The device's Initial Device Identifier will normally contain the MASA The device's Initial Device Identifier will normally contain the MASA
URL as detailed in Section 2.3. This is the RECOMMENDED mechanism. URL as detailed in Section 2.3. This is the RECOMMENDED mechanism.
If the Registrar is integrated with [I-D.ietf-opsawg-mud] and the If the Registrar is integrated with [I-D.ietf-opsawg-mud] and the
Pledge IDevID contains the id-pe-mud-url then the Registrar MAY Pledge IDevID contains the id-pe-mud-url then the Registrar MAY
skipping to change at page 22, line 23 skipping to change at page 24, line 32
Voucher-requests are how vouchers are requested. The semantics of Voucher-requests are how vouchers are requested. The semantics of
the vouchers are described below, in the YANG model. the vouchers are described below, in the YANG model.
A Pledge forms the "Pledge voucher-request" and submits it to the A Pledge forms the "Pledge voucher-request" and submits it to the
Registrar. Registrar.
The Registrar in turn forms the "Registrar voucher-request", and The Registrar in turn forms the "Registrar voucher-request", and
submits it to the MASA server. submits it to the MASA server.
The "proximity-registrar-cert" leaf is used in the Pledge voucher- The "proximity-registrar-cert" leaf is used in the Pledge voucher-
requests. requests. This provides a method for the Pledge to assert the
Registrar's proximity.
The "prior-signed-voucher-request" leaf is be used in Registrar The "prior-signed-voucher-request" leaf is used in Registrar voucher-
voucher-requests to the Pledge voucher-request. It contains the requests. If present, it is the encoded (signed form) of the Pledge
encoded (signed form) of the Pledge voucher-request. voucher-request. This provides a method for the Registrar to forward
the Pledge's signed request to the MASA. This completes transmission
of the signed "proximity-registrar-cert" leaf.
A Registar MAY also retrieve (nonceless) vouchers by sending voucher- A Registar MAY also retrieve nonceless vouchers by sending nonceless
requests to the MASA. No "prior-signed-voucher-request" leaf would voucher-requests to the MASA in order to obtain vouchers for later
be included. This can be used to retrieve vouchers for later offline offline use. No "prior-signed-voucher-request" leaf would be
use. The Registrar will need to know the serial number of the included. The Registrar will also need to know the serial number of
pledge. This document does not provide a mechanism for the Registrar the pledge. This document does not provide a mechanism for the
to learn that in an automated fashion. Typically this will be done Registrar to learn that in an automated fashion. Typically this will
via scanning of bar-code or QR-code on packaging, or via some sales be done via scanning of bar-code or QR-code on packaging, or via some
channel integration. 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 signing structure is as defined for vouchers, see
[I-D.ietf-anima-voucher]. [I-D.ietf-anima-voucher].
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 notation used in this diagram is
described in [I-D.ietf-anima-voucher]. Each node in the diagram is described in [I-D.ietf-anima-voucher]. Each node in the diagram is
skipping to change at page 33, line 5 skipping to change at page 35, line 5
address given in the locator. address given in the locator.
Registrars MUST accept TCP / UDP traffic on the ports given at the Registrars MUST accept TCP / UDP traffic on the ports given at the
ACP address of the Registrar. If the Registrar supports IPIP ACP address of the Registrar. If the Registrar supports IPIP
tunnelling, it MUST also accept traffic encapsulated with IPIP. tunnelling, it MUST also accept traffic encapsulated with IPIP.
Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated.
Registrars MAY accept DTLS/CoAP/EST traffic on the UDP ports, in Registrars MAY accept DTLS/CoAP/EST traffic on the UDP ports, in
addition to TCP traffic. addition to TCP traffic.
5. Protocol Details 5. Protocol Details (Pledge - Registrar - MASA)
The Pledge MUST initiate BRSKI after boot if it is unconfigured. The The Pledge MUST initiate BRSKI after boot if it is unconfigured. The
Pledge MUST NOT automatically initiate BRSKI if it has been Pledge MUST NOT automatically initiate BRSKI if it has been
configured or is in the process of being configured. configured or is in the process of being configured.
BRSKI is described as extensions to EST [RFC7030]. The goal of these BRSKI is described as extensions to EST [RFC7030]. The goal of these
extensions is to reduce the number of TLS connections and crypto extensions is to reduce the number of TLS connections and crypto
operations required on the Pledge. The Registrar implements the operations required on the Pledge. The Registrar implements the
BRSKI REST interface within the same "/.well-known" URI tree as the BRSKI REST interface within the same "/.well-known" URI tree as the
existing EST URIs as described in EST [RFC7030] section 3.2.2. The existing EST URIs as described in EST [RFC7030] section 3.2.2. The
skipping to change at page 33, line 32 skipping to change at page 35, line 32
Figure 1). Figure 1).
MASA URI is "https://" authority "/.well-known/est". MASA URI is "https://" authority "/.well-known/est".
BRSKI uses existing CMS message formats for existing EST operations. BRSKI uses existing CMS message formats for existing EST operations.
BRSKI uses JSON [RFC7159] for all new operations defined here, and BRSKI uses JSON [RFC7159] for all new operations defined here, and
voucher formats. voucher formats.
While EST section 3.2 does not insist upon use of HTTP 1.1 persistent While EST section 3.2 does not insist upon use of HTTP 1.1 persistent
connections, BRSKI-EST connections SHOULD use persistent connections. connections, BRSKI-EST connections SHOULD use persistent connections.
The intention of this guidance is to ensure the provisional TLS The intention of this guidance is to ensure the provisional TLS state
authentication occurs only once and is properly managed. occurs only once, and that the subsequent resolution of the provision
state is not subject to a MITM attack during a critical phase.
Summarized automation extensions for the BRSKI-EST flow are: Summarized automation extensions for the BRSKI-EST flow are:
o The Pledge provisionally accepts the Registrar certificate during o The Pledge provisionally accepts the Registrar certificate during
the TLS handshake as detailed in Section 5.1. the TLS handshake as detailed in Section 5.1.
o If the Registrar responds with a redirection to other web origins o In order to avoid infinite redirect loops, which a malicious
the Pledge MUST follow only a single redirection. (EST supports Registrar might do in order to keep the Pledge from discovering
redirection but does not allow redirections to other web origins the correct Registrar, the Pledge MUST NOT follow more than one
without user input.) redirection to another other web origins.
o (EST supports redirection but does not allow redirections to other
web origins without user input.)
o The Registar MAY respond with an HTTP 202 ("the request has been o The Registar MAY respond with an HTTP 202 ("the request has been
accepted for processing, but the processing has not been accepted for processing, but the processing has not been
completed") as described in EST [RFC7030] section 4.2.3 wherein completed") as described in EST [RFC7030] section 4.2.3 wherein
the client "MUST wait at least the specified 'retry-after' time the client "MUST wait at least the specified 'retry-after' time
before repeating the same request". The Pledge is RECOMMENDED to before repeating the same request". The Pledge is RECOMMENDED to
provide local feed (blinked LED etc) during this wait cycle if provide local feedback (blinked LED etc) during this wait cycle if
mechanisms for this are available. To prevent an attacker mechanisms for this are available. To prevent an attacker
Registrar from significantly delaying bootstrapping the Pledge Registrar from significantly delaying bootstrapping the Pledge
MUST limit the 'retry-after' time to 60 seconds. To avoid MUST limit the 'retry-after' time to 60 seconds.
blocking on a single erroneous Registrar the Pledge MUST drop the
connection after 5 seconds in which there has been no progress on o To avoid blocking on a single erroneous Registrar the Pledge MUST
the TCP connection. It should proceed to other discovered drop the connection after 5 seconds in which there has been no
Registrars if there are any. If there were no other Registrars progress on the TCP connection. It should proceed to connect to
discovered, the Pledge MAY continue to wait, as long as it is any other Registrar's via any other discovered Proxies if there
concurrently listening for new Proxy announcements. are any. If there were no other Proxies discovered, the Pledge
MAY continue to wait, as long as it is concurrently listening for
new Proxy announcements.
o Ideally the Pledge could keep track of the appropriate retry-after o Ideally the Pledge could keep track of the appropriate retry-after
value for any number of outstanding Registrars but this would value for any number of outstanding Registrars but this would
involve a large state table on the Pledge. Instead the Pledge MAY involve a large state table on the Pledge. Instead the Pledge MAY
ignore the exact retry-after value in favor of a single hard coded ignore the exact retry-after value in favor of a single hard coded
value that takes effect between discovery attempts. A Registrar value that takes effect between discovery attempts. A Registrar
that is unable to complete the transaction the first time due to that is unable to complete the transaction the first time due to
timing reasons will have future chances. timing reasons will have future chances.
o The Pledge requests and validates a voucher using the new REST o The Pledge requests and validates a voucher using the new REST
calls described below. calls described below.
o If necessary the Pledge calls the EST defined /cacerts method to o If necessary the Pledge calls the EST defined /cacerts method to
obtain the domain owners' CA certificate. The pinned-domain- obtain the domain owners' CA certificate. The pinned-domain-
certificate element from the voucher should validate this certificate element from the voucher should validate this
certificate, or be identical to it. certificate, or be identical to it.
o The Pledge completes authentication of the server certificate as o The Pledge completes authentication of the server certificate as
detailed in Section 5.5.1. This moves the BRSKI-EST TLS detailed in Section 5.5.1. This moves the BRSKI-EST TLS
connection out of the provisional state. Optionally, the BRSKI- connection out of the provisional state.
EST TLS connection can now be used for EST enrollment.
o Mandatory boostrap steps conclude with Voucher Status Telemetry
(see Section 5.6).
The BRSKI-EST TLS connection can now be used for EST enrollment.
The extensions for a Registrar (equivalent to EST server) are: The extensions for a Registrar (equivalent to EST server) are:
o Client authentication is automated using Initial Device Identity o Client authentication is automated using Initial Device Identity
(IDevID) as per the EST certificate based client authentication. (IDevID) as per the EST certificate based client authentication.
The subject field's DN encoding MUST include the "serialNumber" The subject field's DN encoding MUST include the "serialNumber"
attribute with the device's unique serial number. In the language attribute with the device's unique serial number.
of [RFC6125] this provides for a SERIALNUM-ID category of
identifier that can be included in a certificate and therefore o In the language of [RFC6125] this provides for a SERIALNUM-ID
that can also be used for matching purposes. The SERIALNUM-ID category of identifier that can be included in a certificate and
whitelist is collated according to manufacturer trust anchor since therefore that can also be used for matching purposes. The
serial numbers are not globally unique. SERIALNUM-ID whitelist is collated according to manufacturer trust
anchor since serial numbers are not globally unique.
o The Registrar requests and validates the Voucher from the MASA. o The Registrar requests and validates the Voucher from the MASA.
o The Registrar forwards the Voucher to the Pledge when requested. o The Registrar forwards the Voucher to the Pledge when requested.
o The Registar performs log verifications in addition to local o The Registar performs log verifications in addition to local
authorization checks before accepting optional Pledge device authorization checks before accepting optional Pledge device
enrollment requests. enrollment requests.
5.1. BRSKI-EST TLS establishment details 5.1. BRSKI-EST TLS establishment details
skipping to change at page 36, line 11 skipping to change at page 38, line 21
those types are not yet known. those types are not yet known.
The Pledge populates the voucher-request fields as follows: The Pledge populates the voucher-request fields as follows:
created-on: Pledges that have a realtime clock are RECOMMENDED to created-on: Pledges that have a realtime clock are RECOMMENDED to
populate this field. This provides additional information to the populate this field. This provides additional information to the
MASA. MASA.
nonce: The Pledge voucher-request MUST contain a cryptographically nonce: The Pledge voucher-request MUST contain a cryptographically
strong random or pseudo-random number nonce. Doing so ensures strong random or pseudo-random number nonce. Doing so ensures
Section 2.5.1 functionality. The nonce MUST NOT be reused for Section 2.6.1 functionality. The nonce MUST NOT be reused for
bootstrapping attempts. multiple bootstrapping attempts.
assertion: The Pledge voucher-request MAY contain an assertion of assertion: The Pledge voucher-request MAY contain an assertion of
"proximity". "proximity".
proximity-registrar-cert: In a Pledge voucher-request this is the proximity-registrar-cert: In a Pledge voucher-request this is the
first certificate in the TLS server 'certificate_list' sequence first certificate in the TLS server 'certificate_list' sequence
(see [RFC5246]) presented by the Registrar to the Pledge. This (see [RFC5246]) presented by the Registrar to the Pledge. This
MUST be populated in a Pledge voucher-request if the "proximity" MUST be populated in a Pledge voucher-request if the "proximity"
assertion is populated. assertion is populated.
skipping to change at page 36, line 44 skipping to change at page 39, line 9
respond with an appropriate HTTP error code. respond with an appropriate HTTP error code.
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.4) and returns that MASA signed the MASA service (see Section 5.4) and returns that MASA signed
voucher to the Pledge as described in Section 5.5. voucher to the Pledge as described in Section 5.5.
5.3. BRSKI-MASA TLS establishment details 5.3. 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.7 connection and uses the MASA URL obtained as described in Section 2.8
for [RFC6125] authentication of the MASA server. for [RFC6125] authentication of the MASA server.
The primary method of Registrar "authentication" by the MASA is The primary method of Registrar "authentication" by the MASA is
detailed in Section 5.4. As detailed in Section 8 the MASA might detailed in Section 5.4. As detailed in Section 9 the MASA might
find it necessary to request additional Registrar authentication. find it necessary to request additional Registrar authentication.
Registrars MUST be prepared to support TLS client certificate Registrars MUST be prepared to support TLS client certificate
authentication and HTTP Basic or Digest authentication as described authentication and HTTP Basic or Digest authentication as described
in RFC7030 for EST clients. Implementors are advised that contacting in RFC7030 for EST clients. Implementors are advised that contacting
the MASA is to establish a secured REST connection with a web service the MASA is to establish a secured REST connection with a web service
and that there are a number of authentication models being explored and that there are a number of authentication models being explored
within the industry. Registrars are RECOMMENDED to fail gracefully within the industry. Registrars are RECOMMENDED to fail gracefully
and generate useful administrative notifications or logs in the and generate useful administrative notifications or logs in the
advent of unexpected HTTP 401 (Unauthorized) responses from the MASA. advent of unexpected HTTP 401 (Unauthorized) responses from the MASA.
skipping to change at page 37, line 42 skipping to change at page 40, line 9
The Registrar populates the voucher-request fields as follows: The Registrar populates the voucher-request fields as follows:
created-on: Registrars are RECOMMENDED to populate this field. This created-on: Registrars are RECOMMENDED to populate this field. This
provides additional information to the MASA. provides additional information to the MASA.
nonce: The optional nonce value from the Pledge request if desired nonce: The optional nonce value from the Pledge request if desired
(see below). (see below).
serial-number: The serial number of the Pledge the Registrar would serial-number: The serial number of the Pledge the Registrar would
like a voucher for. like a voucher for. The Registrar determines this value by
parsing the authenticated Pledge IDevID certificate. See
Section 2.3. The Registrar SHOULD verify that the serial number
field it parsed matches the serial number field the Pledge
provided in its voucher-request. This provides a sanity check
useful for detecting error conditions and logging. The Registrar
MUST NOT simply copy the serial number field from a Pledge voucher
request as that field is claimed but not certified.
idevid-issuer: The idevid-issuer value from the Pledge certificate idevid-issuer: The idevid-issuer value from the Pledge certificate
is included to ensure a statistically unique identity. The is included to ensure a statistically unique identity.
Pledge's serial number is extracted from the X.509 IDevID. See
Section 2.3.
prior-signed-voucher: If a signed Pledge voucher-request was prior-signed-voucher: If a signed Pledge voucher-request was
received then it SHOULD be included in the Registrar voucher- received then it SHOULD be included in the Registrar voucher-
request. (NOTE: what is included is the complete Pledge voucher- request. (NOTE: what is included is the complete Pledge voucher-
request, inclusive of the 'assertion', 'proximity-registrar-cert', request, inclusive of the 'assertion', 'proximity-registrar-cert',
etc wrapped by the Pledge's original signature). etc wrapped by the Pledge's original signature). If a signed
voucher-request was not recieved from the Pledge then this leaf is
omitted from the Registrar voucher request.
A nonceless Registrar voucher-request MAY be submitted to the MASA. A nonceless Registrar voucher-request MAY be submitted to the MASA.
Doing so allows the Registrar to request a Voucher when the Pledge is Doing so allows the Registrar to request a Voucher when the Pledge is
offline, or when the Registrar is expected to be offline when the offline, or when the Registrar is expected to be offline when the
Pledge is being deployed. These use cases require the Registrar to Pledge is being deployed. These use cases require the Registrar to
learn the appropriate IDevID SerialNumber field from the physical learn the appropriate IDevID SerialNumber field from the physical
device labeling or from the sales channel (out-of-scope for this device labeling or from the sales channel (out-of-scope for this
document). If a nonceless voucher-reqeust is submitted the MASA document). If a nonceless voucher-reqeust is submitted the MASA
server MUST authenticate the Registrar as described in either EST server MUST authenticate the Registrar as described in either EST
[RFC7030] section 3.2, section 3.3, or by validating the Registrar's [RFC7030] section 3.2, section 3.3, or by validating the Registrar's
skipping to change at page 38, line 33 skipping to change at page 41, line 7
Example JSON payloads of Registrar voucher-requests are in Example JSON payloads of Registrar voucher-requests are in
Section 3.2 Examples 2 through 4. Section 3.2 Examples 2 through 4.
The MASA verifies that the Registrar voucher-request is internally The MASA verifies that the Registrar voucher-request is internally
consistent but does not necessarily authenticate the Registrar consistent but does not necessarily authenticate the Registrar
certificate since the Registrar is not known to the MASA server in certificate since the Registrar is not known to the MASA server in
advance. The MASA performs the following actions and validation advance. The MASA performs the following actions and validation
checks before issuing a voucher: checks before issuing a voucher:
Renew for expired voucher: As described in [I-D.ietf-anima-voucher] 5.4.1. Renew for expired voucher
vouchers are normally short lived to avoid revocation issues. If
the request is for a previous (expired) voucher using the same
Registrar (as determined by the Registrar pinned-domain-cert) and
the MASA has not been informed that the claim is invalid then the
request for a renewed voucher SHOULD be automatically authorized.
Voucher signature consistency: The MASA MUST verify that the As described in [I-D.ietf-anima-voucher] vouchers are normally short
Registrar voucher-request is signed by a Registrar. This is lived to avoid revocation issues. If the request is for a previous
confirmed by verifying that the id-kp-cmcRA extended key usage (expired) voucher using the same Registrar (as determined by the
extension field (as detailed in EST RFC7030 section 3.6.1) exists Registrar pinned-domain-cert) and the MASA has not been informed that
in the certificate of the entity that signed the Registrar the claim is invalid then the request for a renewed voucher SHOULD be
voucher-request. This verification is only a consistency check automatically authorized.
that the unauthenticated domain CA intended this to be a
Registrar. Performing this check provides value to domain PKI by
assuring the domain administrator that the MASA service will only
respect claims from authorized Registration Authorities of the
domain. (The requirement for the Registrar to include the Domain
CA certificate in the signature structure was stated above.)
Registrar revocation consistency: The MASA SHOULD check for 5.4.2. Voucher signature consistency
revocation of the Registrar certificate. The maximum lifetime of
the voucher issued SHOULD NOT exceed the lifetime of the
Registrar's revocation validation (for example if the Registrar
revocation status is indicated in a CRL that is valid for two
weeks then that is an appropriate lifetime for the voucher.)
Because the Registar certificate authority is unknown to the MASA
in advance this is only an extended consistency check and is not
required. The maximum lifetime of the voucher issued SHOULD NOT
exceed the lifetime of the Registrar's revocation validation (for
example if the Registrar revocation status is indicated in a CRL
that is valid for two weeks then that is an appropriate lifetime
for the voucher.)
Pledge proximity assertion: The MASA server MAY verify that the The MASA MUST verify that the Registrar voucher-request is signed by
Registrar voucher-request includes the 'prior-signed-voucher' a Registrar. This is confirmed by verifying that the id-kp-cmcRA
field populated with a Pledge voucher-request that includes a extended key usage extension field (as detailed in EST RFC7030
'proximity-registrar-cert' that is consistent with the certificate section 3.6.1) exists in the certificate of the entity that signed
used to sign the Registrar voucher-request. The MASA server is the Registrar voucher-request. This verification is only a
aware of which Pledge's support signing of their voucher requests consistency check that the unauthenticated domain CA intended this to
and can use this information to confirm proximity of the Pledge be a Registrar. Performing this check provides value to domain PKI
with the Registrar. by assuring the domain administrator that the MASA service will only
respect claims from authorized Registration Authorities of the
domain. (The requirement for the Registrar to include the Domain CA
certificate in the signature structure was stated above.)
Registar (certificate) authentication: This only occurs if the 5.4.3. Registrar revocation consistency
Registrar voucher-request is nonceless. As noted above the
details concerning necessary sales-channel integration for the If the Registrar uses a CA known to the MASA, and it makes
MASA to authenticate a Registrar certificate is out-of-scope. certificate revocation information available to the MASA, then the
MASA SHOULD check for the maximum validity of the Registrar's
certificate.
There are three times to consider: a) a configured voucher lifetime
in the MASA, b) the expiry time for the Registrar's Certificate, c)
any certificate revocation information (CRL) lifetime.
The resulting voucher should have a lifetime (expires-on field) which
is the earliest of these three values. Typically (b) will be some
significant time in the future, but (c) will typically be short (on
the order of a week or less). The RECOMMENDED period for (a) is on
the order of 20 minutes, so it will typically determine the lifespan
of the resulting voucher.
By limiting the voucher lifetime in this way, the MASA is effectively
doing CRL and lifetime checks on behalf of the Pledge. While the
pledge may be without a real time clock to tell it absolute time, it
SHOULD be able to calculate relative time. See section
Section 2.6.1.
If CRL information is unavailable to the MASA, then the MASA SHOULD
rely on the validity information Because the Registar certificate
authority is unknown to the MASA in advance this is only an extended
consistency check and is not required. The maximum lifetime of the
voucher issued SHOULD NOT exceed the lifetime of the Registrar's
revocation validation (for example if the Registrar revocation status
is indicated in a CRL that is valid for two weeks then that is an
appropriate lifetime for the voucher.)
5.4.4. Pledge proximity assertion
The MASA server MAY verify that the Registrar voucher-request
includes the 'prior-signed-voucher' field populated with a Pledge
voucher-request that includes a 'proximity-registrar-cert' that is
consistent with the certificate used to sign the Registrar voucher-
request. The MASA server is aware of which Pledges support signing
of their voucher requests and can use this information to confirm
proximity of the Pledge with the Registrar.
5.4.5. Registar (certificate) authentication
The pledge proximity assertion only occurs if the Registrar voucher-
request is nonceless. As noted above the details concerning
necessary sales-channel integration for the MASA to authenticate a
Registrar certificate is out-of-scope.
5.4.6. Registrar Anchor
The Registrar's certificate chain is extracted from the signature The Registrar's certificate chain is extracted from the signature
method and the root certificate is used to populate the "pinned- method and the root certificate is used to populate the "pinned-
domain-cert" of the Voucher being issued. The domainID (e.g., hash domain-cert" of the Voucher being issued. The domainID (e.g., hash
of the root public key) is determined from the pinned-domain-cert and of the root public key) is determined from the pinned-domain-cert and
is used to update the audit log. is used to update the audit log.
5.5. Voucher Response 5.5. Voucher Response
The voucher response to requests from the Pledge and requests from a The voucher response to requests from the Pledge and requests from a
Registrar are in the same format. A Registrar either caches prior Registrar are in the same format. A Registrar either caches prior
MASA responses or dynamically requests a new Voucher based on local MASA responses or dynamically requests a new Voucher based on local
policy. policy.
If the join operation is successful, the server response MUST contain If the join operation is successful, the server (MASA responding to
Registrar, and Registrar responding to Pledge) response MUST contain
an HTTP 200 response code. The server MUST answer with a suitable an HTTP 200 response code. The server MUST answer with a suitable
4xx or 5xx HTTP [RFC2616] error code when a problem occurs. In this 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. In this
case, the response data from the MASA server MUST be a plaintext case, the response data from the MASA server MUST be a plaintext
human-readable (ASCII, English) error message containing explanatory human-readable (ASCII, English) error message containing explanatory
information describing why the request was rejected. information describing why the request was rejected.
A 403 (Forbidden) response is appropriate if the voucher-request is A 403 (Forbidden) response is appropriate if the voucher-request is
not signed correctly, stale, or if the Pledge has another outstanding not signed correctly, stale, or if the Pledge has another outstanding
voucher that cannot be overridden. voucher that cannot be overridden.
skipping to change at page 40, line 23 skipping to change at page 43, line 26
desired type, or using the desired algorithms (as indicated by the desired type, or using the desired algorithms (as indicated by the
Accept: headers, and algorithms used in the signature) cannot be Accept: headers, and algorithms used in the signature) cannot be
issued, such as because the MASA knows the Pledge cannot process that issued, such as because the MASA knows the Pledge cannot process that
type. type.
A 415 (Unsupported Media Type) response is approriate for a request A 415 (Unsupported Media Type) response is approriate for a request
that has a voucher encoding that is not understood. that has a voucher encoding that is not understood.
The response media type is: The response media type is:
application/pkcs7-mime; smime-type=voucher The response is a "YANG- application/voucher-cms+json The response is a "YANG-defined JSON
defined JSON document that has been signed using a PKCS#7 document that has been signed using a CMS structure" as described
structure" as described in [I-D.ietf-anima-voucher] using the JSON in [I-D.ietf-anima-voucher] using the JSON encoded described in
encoded described in [RFC7951]. The MASA MUST sign the request. [RFC7951]. The MASA MUST sign the request.
The syntactic details of vouchers are described in detail in The syntactic details of vouchers are described in detail in
[I-D.ietf-anima-voucher]. For example, the voucher consists of: [I-D.ietf-anima-voucher]. For example, the voucher consists of:
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"assertion": "logging" "assertion": "logging"
"pinned-domain-cert": "base64encodedvalue==" "pinned-domain-cert": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
The Pledge verifies the signed voucher using the manufacturer The Pledge verifies the signed voucher using the manufacturer
installed trust anchor associated with the manufacturer's selected installed trust anchor associated with the manufacturer's selected
Manufacturer Authorized Signing Authority. Manufacturer Authorized Signing Authority.
The Pledge verifies the serial-number field of the signed voucher
matches the Pledge's serial-number.
The 'pinned-domain-cert' element of the voucher contains the domain The 'pinned-domain-cert' element of the voucher contains the domain
CA's public key. The Pledge MUST use the 'pinned-domain-cert' trust CA's public key. The Pledge MUST use the 'pinned-domain-cert' trust
anchor to immediately complete authentication of the provisional TLS anchor to immediately complete authentication of the provisional TLS
connection. connection.
The Pledge MUST be prepared to parse and fail gracefully from a The Pledge MUST be prepared to parse and fail gracefully from a
Voucher response that does not contain a 'pinned-domain-cert' field. Voucher response that does not contain a 'pinned-domain-cert' field.
The Pledge MUST be prepared to ignore additional fields that it does The Pledge MUST be prepared to ignore additional fields that it does
not recognize. not recognize.
skipping to change at page 41, line 25 skipping to change at page 44, line 32
backoff described earlier. Attempts SHOULD be repeated as failure backoff described earlier. Attempts SHOULD be repeated as failure
may be the result of a temporary inconsistently (an inconsistently may be the result of a temporary inconsistently (an inconsistently
rolled Registrar key, or some other mis-configuration.) The rolled Registrar key, or some other mis-configuration.) The
inconsistently could also be the result an active MITM attack on the inconsistently could also be the result an active MITM attack on the
EST connection. EST connection.
The Registrar MUST use a certificate that chains to the pinned- The Registrar MUST use a certificate that chains to the pinned-
domain-cert as its TLS server certificate. domain-cert as its TLS server certificate.
The Pledge's PKIX path validation of a Registrar certificate's The Pledge's PKIX path validation of a Registrar certificate's
validity period information is as described in Section 2.5.1. Once validity period information is as described in Section 2.6.1. Once
the PKIX path validation is successful the TLS connection is no the PKIX path validation is successful the TLS connection is no
longer provisional. longer provisional.
The pinned-domain-cert is installed as an Explicit Trust Anchor for The pinned-domain-cert is installed as an Explicit Trust Anchor for
future operations. It can therefore can be used to authenticate any future operations. It can therefore can be used to authenticate any
dynamically discovered EST server that contain the id-kp-cmcRA dynamically discovered EST server that contain the id-kp-cmcRA
extended key usage extension as detailed in EST RFC7030 section extended key usage extension as detailed in EST RFC7030 section
3.6.1; but to reduce system complexity the Pledge SHOULD avoid 3.6.1; but to reduce system complexity the Pledge SHOULD avoid
additional discovery operations. Instead the Pledge SHOULD additional discovery operations. Instead the Pledge SHOULD
communicate directly with the Registrar as the EST server. The communicate directly with the Registrar as the EST server. The
'pinned-domain-cert' is not a complete distribution of the EST 'pinned-domain-cert' is not a complete distribution of the [RFC7030]
section 4.1.3 CA Certificate Response, which is an additional section 4.1.3 CA Certificate Response, which is an additional
justification for the recommendation to proceed with EST key justification for the recommendation to proceed with EST key
management operations. Once a full CA Certificate Response is management operations. Once a full CA Certificate Response is
obtained it is more authoritative for the domain than the limited obtained it is more authoritative for the domain than the limited
'pinned-domain-cert' response. 'pinned-domain-cert' response.
5.6. Voucher Status Telemetry 5.6. Voucher Status Telemetry
The domain is expected to provide indications to the system The domain is expected to provide indications to the system
administrators concerning device lifecycle status. To facilitate administrators concerning device lifecycle status. To facilitate
skipping to change at page 42, line 4 skipping to change at page 45, line 15
5.6. Voucher Status Telemetry 5.6. Voucher Status Telemetry
The domain is expected to provide indications to the system The domain is expected to provide indications to the system
administrators concerning device lifecycle status. To facilitate administrators concerning device lifecycle status. To facilitate
this it needs telemetry information concerning the device's status. this it needs telemetry information concerning the device's status.
To indicate Pledge status regarding the Voucher, the Pledge MUST post To indicate Pledge status regarding the Voucher, the Pledge MUST post
a status message. a status message.
The posted data media type: application/json The posted data media type: application/json
The client HTTP POSTs the following to the server at the EST well The client HTTP POSTs the following to the server at the EST well
known URI "/voucher_status". The Status field indicates if the known URI "/voucher_status". The Status field indicates if the
Voucher was acceptable. If it was not acceptable the Reason string Voucher was acceptable. If it was not acceptable the Reason string
indicates why. In the failure case this message is being sent to an indicates why. In the failure case this message may be sent to an
unauthenticated, potentially malicious Registrar and therefore the unauthenticated, potentially malicious Registrar and therefore the
Reason string SHOULD NOT provide information beneficial to an Reason string SHOULD NOT provide information beneficial to an
attacker. The operational benefit of this telemetry information is attacker. The operational benefit of this telemetry information is
balanced against the operational costs of not recording that an balanced against the operational costs of not recording that an
Voucher was ignored by a client the registar expected to continue Voucher was ignored by a client the registar expected to continue
joining the domain. joining the domain.
{ {
"version":"1", "version":"1",
"Status":FALSE /* TRUE=Success, FALSE=Fail" "Status":FALSE /* TRUE=Success, FALSE=Fail"
skipping to change at page 43, line 8 skipping to change at page 46, line 19
did when requesting a Voucher. It is posted to the /requestauditlog did when requesting a Voucher. It is posted to the /requestauditlog
URI instead. The "idevid-issuer" and "serial-number" informs the URI instead. The "idevid-issuer" and "serial-number" informs the
MASA server which log is requested so the appropriate log can be MASA server which log is requested so the appropriate log can be
prepared for the response. Using the same media type and message prepared for the response. Using the same media type and message
minimizes cryptographic and message operations although it results in minimizes cryptographic and message operations although it results in
additional network traffic. The relying MASA server implementation additional network traffic. The relying MASA server implementation
MAY leverage internal state to associate this request with the MAY leverage internal state to associate this request with the
original, and by now already validated, Registrar voucher-request so original, and by now already validated, Registrar voucher-request so
as to avoid an extra crypto validation. as to avoid an extra crypto validation.
A MASA that receives a request for a device which does not exist, or A MASA that receives a request for a device that does not exist, or
for which the requesting owner was never an owner returns an HTTP 404 for which the requesting owner was never an owner returns an HTTP 404
("Not found") code. ("Not found") code.
Rather than returning the audit log as a response to the POST (with a Rather than returning the audit log as a response to the POST (with a
return code 200), the MASA MAY instead return a 201 ("Created") return code 200), the MASA MAY instead return a 201 ("Created")
RESTful response ([RFC7231] section 7.1) containing a URL to the RESTful response ([RFC7231] section 7.1) containing a URL to the
prepared (and easily cachable) audit response. prepared (and easily cachable) audit response.
MASA servers that return URLs SHOULD take care to make the returned In order to avoid enumeration of device audit logs, MASA servers that
URL unguessable. URLs containing a database number such as return URLs SHOULD take care to make the returned URL unguessable.
https://example.com/auditlog/1234 or the EUI of the device such For instance, rather than returning URLs containing a database number
https://example.com/auditlog/10-00-00-11-22-33, would be easily such as https://example.com/auditlog/1234 or the EUI of the device
enumerable by an attacker. It is recommended to put some meaningless such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD
randomly generated slug that indexes a database instead. return a randomly generated value (a "slug" in web parlance). The
value is used to find the relevant database entry.
A MASA that returns a code 200 MAY also include a Location: header A MASA that returns a code 200 MAY also include a Location: header
for future reference by the Registrar. for future reference by the Registrar.
The request media type is: The request media type is:
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
skipping to change at page 45, line 16 skipping to change at page 48, line 16
("nonced duplicates" and/or "nonceless duplicates) could still be ("nonced duplicates" and/or "nonceless duplicates) could still be
acceptable for informed decisions. A log that has had "arbitrary" acceptable for informed decisions. A log that has had "arbitrary"
truncations is less acceptable but manufacturer transparency is truncations is less acceptable but manufacturer transparency is
better than hidden truncations. better than hidden truncations.
This document specifies a simple log format as provided by the MASA This document specifies a simple log format as provided by the MASA
service to the registar. This format could be improved by service to the registar. This format could be improved by
distributed consensus technologies that integrate vouchers with distributed consensus technologies that integrate vouchers with
technologies such as block-chain or hash trees or optimized logging technologies such as block-chain or hash trees or optimized logging
approaches. Doing so is out of the scope of this document but is an approaches. Doing so is out of the scope of this document but is an
anticipated improvements for future work. As such, the Registrar anticipated improvement for future work. As such, the Registrar
client SHOULD anticipate new kinds of responses, and SHOULD provide client SHOULD anticipate new kinds of responses, and SHOULD provide
operator controls to indicate how to process unknown responses. operator controls to indicate how to process unknown responses.
5.8. EST Integration for PKI bootstrapping 5.8. EST Integration for PKI bootstrapping
The Pledge SHOULD follow the BRSKI operations with EST enrollment The Pledge SHOULD follow the BRSKI operations with EST enrollment
operations including "CA Certificates Request", "CSR Attributes" and operations including "CA Certificates Request", "CSR Attributes" and
"Client Certificate Request" or "Server-Side Key Generation", etc. "Client Certificate Request" or "Server-Side Key Generation", etc.
This is a relatively seamless integration since BRSKI REST calls This is a relatively seamless integration since BRSKI REST calls
provide an automated alternative to the manual bootstrapping method provide an automated alternative to the manual bootstrapping method
described in [RFC7030]. As noted above, use of HTTP 1.1 persistent described in [RFC7030]. As noted above, use of HTTP 1.1 persistent
connections simplifies the Pledge state machine. connections simplifies the Pledge state machine.
The Pledge is also RECOMMENDED to implement the EST automation An ANIMA ANI Pledge MUST implement the EST automation extensions
extensions described below. They supplement the RFC7030 EST to described below. They supplement the [RFC7030] EST to better support
better support automated devices that do not have an end user. automated devices that do not have an end user.
Although EST allows clients to obtain multiple certificates by Although EST allows clients to obtain multiple certificates by
sending multiple CSR requests BRSKI mandates use of the CSR sending multiple CSR requests BRSKI mandates use of the CSR
Attributes request and mandates that the Registrar validate the CSR Attributes request and mandates that the Registrar validate the CSR
against the expected attributes. This implies that client requests against the expected attributes. This implies that client requests
will "look the same" and therefore result in a single logical will "look the same" and therefore result in a single logical
certificate being issued even if the client were to make multiple certificate being issued even if the client were to make multiple
requests. Registrars MAY contain more complex logic but doing so is requests. Registrars MAY contain more complex logic but doing so is
out-of-scope of this specification. BRSKI does not signal any out-of-scope of this specification. BRSKI does not signal any
enhancement or restriction to this capability. Pledges that require enhancement or restriction to this capability.
multiple certificates could establish direct EST connections to the
Registrar.
5.8.1. EST Distribution of CA Certificates 5.8.1. EST Distribution of CA Certificates
The Pledge MUST request the full EST Distribution of CA Certificates The Pledge MUST request the full EST Distribution of CA Certificates
message. See RFC7030, section 4.1. message. See RFC7030, section 4.1.
This ensures that the Pledge has the complete set of current CA This ensures that the Pledge has the complete set of current CA
certificates beyond the pinned-domain-cert (see Section 5.5.1 for a certificates beyond the pinned-domain-cert (see Section 5.5.1 for a
discussion of the limitations inherent in having a single certificate discussion of the limitations inherent in having a single certificate
instead of a full CA Certificates response.) Although these instead of a full CA Certificates response.) Although these
skipping to change at page 47, line 17 skipping to change at page 50, line 17
The Pledge MUST request a new client certificate. See RFC7030, The Pledge MUST request a new client certificate. See RFC7030,
section 4.2. section 4.2.
5.8.4. Enrollment Status Telemetry 5.8.4. Enrollment Status Telemetry
For automated bootstrapping of devices, the adminstrative elements For automated bootstrapping of devices, the adminstrative 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, MASA provides logs and status of credential by the client, MASA provides logs and status of credential
enrollment. The EST protocol assumes an end user and therefore does enrollment. [RFC7030] assumes an end user and therefore does not
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.
To indicate successful enrollment the client SHOULD re-negotiate the To indicate successful enrollment the client SHOULD re-negotiate the
EST TLS session using the newly obtained credentials. This occurs by EST TLS session using the newly obtained credentials. This occurs by
the client initiating a new TLS ClientHello message on the existing the client initiating a new TLS ClientHello message on the existing
TLS connection. The client MAY simply close the old TLS session and TLS connection. The client MAY simply close the old TLS session and
start a new one. The server MUST support either model. start a new one. The server MUST support either model.
In the case of a FAIL, the Reason string indicates why the most In the case of a FAIL, the Reason string indicates why the most
recent enrollment failed. The SubjectKeyIdentifier field MUST be recent enrollment failed. The SubjectKeyIdentifier field MUST be
skipping to change at page 48, line 12 skipping to change at page 51, line 12
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.
This allows for clients that wish to minimize their crypto operations This allows for clients that wish to minimize their crypto operations
to simply POST this response without renegotiating the TLS session - to simply POST this response without renegotiating the TLS session -
at the cost of the server not being able to accurately verify that at the cost of the server not being able to accurately verify that
enrollment was truly successful. enrollment was truly successful.
5.8.5. EST over CoAP 5.8.5. Multiple certificates
Pledges that require multiple certificates could establish direct EST
connections to the Registrar.
5.8.6. EST over CoAP
This document describes extensions to EST for the purposes of This document describes extensions to EST for the purposes of
bootstrapping of remote key infrastructures. Bootstrapping is bootstrapping of remote key infrastructures. Bootstrapping is
relevant for CoAP enrollment discussions as well. The defintion of relevant for CoAP enrollment discussions as well. The defintion of
EST and BRSKI over CoAP is not discussed within this document beyond EST and BRSKI over CoAP is not discussed within this document beyond
ensuring proxy support for CoAP operations. Instead it is ensuring proxy support for CoAP operations. Instead it is
anticipated that a definition of CoAP mappings will occur in anticipated that a definition of CoAP mappings will occur in
subsequent documents such as [I-D.vanderstok-ace-coap-est] and that subsequent documents such as [I-D.vanderstok-ace-coap-est] and that
CoAP mappings for BRSKI will be discussed either there or in future CoAP mappings for BRSKI will be discussed either there or in future
work. work.
6. Reduced security operational modes 6. Reduced security operational modes
A common requirement of bootstrapping is to support less secure A common requirement of bootstrapping is to support less secure
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
be detailed in specific profiles of BRSKI. This is the subject for
future work.
6.1. Trust Model 6.1. Trust Model
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| Pledge | | Circuit | | Domain | |Manufacturer| | Pledge | | Circuit | | Domain | |Manufacturer|
| | | Proxy | | Registrar | | Service | | | | Proxy | | Registrar | | Service |
| | | | | | | (Internet) | | | | | | | | (Internet) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
Figure 10 Figure 10
skipping to change at page 49, line 40 skipping to change at page 52, line 48
interfaces such as a local console port or physical user interfaces such as a local console port or physical user
interface but MUST NOT support "trust on first use" on network interface but MUST NOT support "trust on first use" on network
interfaces. This is because "trust on first use" permanently interfaces. This is because "trust on first use" permanently
degrades the security for all use cases. degrades the security for all use cases.
3. The Pledge MAY have an operational mode where it skips Voucher 3. The Pledge MAY have an operational mode where it skips Voucher
validation one time. For example if a physical button is validation one time. For example if a physical button is
depressed during the bootstrapping operation. This can be useful depressed during the bootstrapping operation. This can be useful
if the manufacturer service is unavailable. This behavior SHOULD if the manufacturer service is unavailable. This behavior SHOULD
be available via local configuration or physical presence methods be available via local configuration or physical presence methods
to ensure new entities can always be deployed even when autonomic (such as use of a serial/craft console) to ensure new entities
methods fail. This allows for unsecured imprint. can always be deployed even when autonomic methods fail. This
allows for unsecured imprint.
It is RECOMMENDED that "trust on first use" or skipping voucher It is RECOMMENDED that "trust on first use" or skipping voucher
validation only be available if hardware assisted Network Endpoint validation only be available if hardware assisted Network Endpoint
Assessment [RFC5209] is supported. This recommendation ensures that Assessment [RFC5209] is supported. This recommendation ensures that
domain network monitoring can detect innappropriate use of offline or domain network monitoring can detect innappropriate use of offline or
emergency deployment procedures. emergency deployment procedures.
6.3. Registrar security reductions 6.3. Registrar security reductions
A Registrar can choose to accept devices using less secure methods. A Registrar can choose to accept devices using less secure methods.
skipping to change at page 51, line 41 skipping to change at page 54, line 47
equipment the Registrar would throw an error if any audit log equipment the Registrar would throw an error if any audit log
information is reported.) The MASA should verify the 'prior- information is reported.) The MASA should verify the 'prior-
signed-voucher' information for Pledges that support that signed-voucher' information for Pledges that support that
functionality. This provides a proof-of-proximity check that functionality. This provides a proof-of-proximity check that
reduces the need for ownership verification. reduces the need for ownership verification.
7. IANA Considerations 7. IANA Considerations
This document requires the following IANA actions: This document requires the following IANA actions:
7.1. PKIX Registry 7.1. Well-known EST registration
This document extends the definitions of "est" (so far defined via
RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
well-known-uris.xhtml" registry as follows:
o add /.well-known/est/requestvoucher (see Section 5.4 )
o add /.well-known/est/requestauditlog (see Section 5.6)
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. [[EDNOTE: fix names]]
This document requests a number from the id-pe registry for id-pe- This document requests a number from the id-pe registry for id-pe-
masa-url. XXX masa-url. XXX
7.2. Voucher Status Telemetry 7.3. Voucher Status Telemetry
IANA is requested to create a registry entitled: _Voucher Status IANA is requested to create a registry entitled: _Voucher Status
Telemetry Attributes_. New items can be added using the Telemetry Attributes_. New items can be added using the
Specification Required. The following items are to be in the initial Specification Required. The following items are to be in the initial
registration, with this document as the reference: registration, with this document as the reference:
o version o version
o Status o Status
o Reason o Reason
o reason-context o reason-context
8. Security Considerations 8. Privacy Considerations
8.1. MASA authorization log
The MASA authorization log includes a hash of the domainID for each
Registrar a voucher has been issued to. This information is closely
related to the actual domain identity, especially when paired with
the anti-DDoS authentication information the MASA might collect.
This could provide sufficient information for the MASA service to
build a detailed understanding the devices that have been provisioned
within a domain.
There are a number of design choices that mitigate this risk. The
domain can maintain some privacy since it has not necessarily been
authenticated and is not authoritatively bound to the supply chain.
Additionally the domainID captures only the unauthenticated subject
key identifier of the domain. A privacy sensitive domain could
theoretically generate a new domainID for each device being deployed.
Similarly a privacy sensitive domain would likely purchase devices
that support proximity assertions from a manufacturer that does not
require sales channel integrations. This would result in a
significant level of privacy while maintaining the security
characteristics provided by Registrar based audit log inspection.
9. Security Considerations
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 planned and unplanned uncooperative to the Registrar. They include planned and unplanned
network partitions, changes to MASA policy, or other instances where network partitions, changes to MASA policy, or other instances where
MASA policy rejects a claim. These introduce an operational risk to MASA policy rejects a claim. These introduce an operational risk to
the Registrar owner that MASA behavior might limit the ability to re- the Registrar owner that MASA behavior might limit the ability to re-
boostrap a Pledge device. For example this might be an issue during boostrap a Pledge device. For example this might be an issue during
disaster recovery. This risk can be mitigated by Registrars that disaster recovery. This risk can be mitigated by Registrars that
request and maintain long term copies of "nonceless" Vouchers. In request and maintain long term copies of "nonceless" Vouchers. In
that way they are guaranteed to be able to repeat bootstrapping for that way they are guaranteed to be able to repeat bootstrapping for
skipping to change at page 53, line 17 skipping to change at page 57, line 8
To facilitate logging and administrative oversight in addition to To facilitate logging and administrative oversight in addition to
triggering Registration verification of MASA logs the Pledge reports triggering Registration verification of MASA logs the Pledge reports
on Voucher parsing status to the Registrar. In the case of a on Voucher parsing status to the Registrar. In the case of a
failure, this information is informative to a potentially malicious failure, this information is informative to a potentially malicious
Registar but this is mandated anyway because of the operational Registar but this is mandated anyway because of the operational
benefits of an informed administrator in cases where the failure is benefits of an informed administrator in cases where the failure is
indicative of a problem. The Registrar is RECOMMENDED to verify MASA indicative of a problem. The Registrar is RECOMMENDED to verify MASA
logs if voucher status telemetry is not received. logs if voucher status telemetry is not received.
The MASA authorization log includes a hash of the domainID for each
Registrar a voucher has been issued to. This information is closely
related to the actual domain identity, especially when paired with
the anti-DDoS authentication information the MASA might collect.
This could provide sufficient information for the MASA service to
build a detailed understanding the devices that have been provisioned
within a domain. There are a number of design choices that mitigate
this risk. The domain can maintain some privacy since it has not
necessarily been authenticated and is not authoritatively bound to
the supply chain. Additionally the domainID captures only the
unauthenticated subject key identifier of the domain. A privacy
sensitive domain could theoretically generate a new domainID for each
device being deployed. Similarly a privacy sensitive domain would
likely purchase devices that support proximity assertions from a
manufacturer that does not require sales channel integrations. This
would result in a significant level of privacy while maintaining the
security characteristics provided by Registrar based audit log
inspection.
To facilitate truely limited clients EST RFC7030 section 3.3.2 To facilitate truely limited clients EST RFC7030 section 3.3.2
requirements that the client MUST support a client authentication requirements that the client MUST support a client authentication
model have been reduced in Section 6 to a statement that the model have been reduced in Section 6 to a statement that the
Registrar "MAY" choose to accept devices that fail cryptographic Registrar "MAY" choose to accept devices that fail cryptographic
authentication. This reflects current (poor) practices in shipping authentication. This reflects current (poor) practices in shipping
devices without a cryptographic identity that are NOT RECOMMENDED. devices without a cryptographic identity that are NOT RECOMMENDED.
During the provisional period of the connection the Pledge MUST treat During the provisional period of the connection the Pledge MUST treat
all HTTP header and content data as untrusted data. HTTP libraries all HTTP header and content data as untrusted data. HTTP libraries
are regularly exposed to non-secured HTTP traffic: mature libraries are regularly exposed to non-secured HTTP traffic: mature libraries
skipping to change at page 54, line 9 skipping to change at page 57, line 29
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 Registrar's verifying voucher to accept based on internal logic. The Registrar's 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.
8.1. Freshness in Voucher-Requests 9.1. 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 55, line 20 skipping to change at page 58, line 38
is a consideration the target network is RECOMMENDED to take the is a consideration the target network is RECOMMENDED to take the
following steps: 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. logs.
8.2. Trusting manufacturers 9.2. 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 56, line 23 skipping to change at page 59, line 41
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.
9. Acknowledgements 10. 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
10. References 11. References
11.1. Normative References
10.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-13 (work in progress), December 2017. plane-13 (work in progress), December 2017.
[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 57, line 25 skipping to change at page 60, line 45
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005, DOI 10.17487/RFC3927, May 2005,
<https://www.rfc-editor.org/info/rfc3927>. <https://www.rfc-editor.org/info/rfc3927>.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519,
DOI 10.17487/RFC4519, June 2006,
<https://www.rfc-editor.org/info/rfc4519>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
skipping to change at page 59, line 9 skipping to change at page 62, line 31
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[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>.
10.2. Informative References 11.2. Informative References
[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-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.,
Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A and J. Nobre, "A Reference Model for Autonomic
Reference Model for Autonomic Networking", draft-ietf- Networking", draft-ietf-anima-reference-model-06 (work in
anima-reference-model-05 (work in progress), October 2017. progress), February 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, "Zero Touch
Provisioning for Networking Devices", draft-ietf-netconf- Provisioning for Networking Devices", draft-ietf-netconf-
zerotouch-20 (work in progress), February 2018. zerotouch-21 (work in progress), March 2018.
[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-18 (work Description Specification", draft-ietf-opsawg-mud-18 (work
in progress), March 2018. in progress), March 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.
skipping to change at page 61, line 5 skipping to change at page 64, line 31
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>.
Appendix A. IPv4 operations Appendix A. IPv4 and non-ANI operations
The secification of BRSKI in Section 4 intentionally only covers the
mechanisms for an IPv6 Pledge using Link-Local addresses. This
section describes non-normative extensions that can be used in other
environments.
A.1. IPv4 Link Local addresses A.1. IPv4 Link Local addresses
Instead of an IPv6 link-local address, an IPv4 address may be Instead of an IPv6 link-local address, an IPv4 address may be
generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local
Addresses. Addresses.
In the case that an IPv4 Link-Local address is formed, then the In the case that an IPv4 Link-Local address is formed, then the
bootstrap process would continue as in the IPv6 case by looking for a bootstrap process would continue as in the IPv6 case by looking for a
(circuit) proxy. (circuit) proxy.
skipping to change at page 61, line 29 skipping to change at page 65, line 11
The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP
provided parameters for the Domain Name System can be used to perform provided parameters for the Domain Name System can be used to perform
DNS operations if all local discovery attempts fail. DNS operations if all local discovery attempts fail.
Appendix B. mDNS / DNSSD proxy discovery options Appendix B. mDNS / DNSSD proxy discovery options
The Pledge MAY perform DNS-based Service Discovery [RFC6763] over The Pledge MAY perform DNS-based Service Discovery [RFC6763] over
Multicast DNS [RFC6762] searching for the service Multicast DNS [RFC6762] searching for the service
"_bootstrapks._tcp.local.". "_bootstrapks._tcp.local.".
To prevent unaccceptable levels of network traffic the congestion A non-ANI Proxy MAY perform DNS-based Service Discovery using unicast
avoidance mechanisms specified in [RFC6762] section 7 MUST be DNS to discover Registrars searching for searching for the service
followed. The Pledge SHOULD listen for an unsolicited broadcast "_brski-registrar._tcp.local.".
response as described in [RFC6762]. This allows devices to avoid
announcing their presence via mDNS broadcasts and instead silently To prevent unaccceptable levels of network traffic, when using mDNS,
join a network by watching for periodic unsolicited broadcast the congestion avoidance mechanisms specified in [RFC6762] section 7
responses. MUST be followed. The Pledge SHOULD listen for an unsolicited
broadcast response as described in [RFC6762]. This allows devices to
avoid announcing their presence via mDNS broadcasts and instead
silently join a network by watching for periodic unsolicited
broadcast responses.
The service searched for is "_bootstrapks._tcp.example.com". In this The service searched for is "_bootstrapks._tcp.example.com". In this
case the domain "example.com" is discovered as described in [RFC6763] case the domain "example.com" is discovered as described in [RFC6763]
section 11. This method is only available if the host has received a section 11. This method is only available if the host has received a
useable IPv4 address via DHCPv4 as suggested in Appendix A.2. useable IPv4 address via DHCPv4 as suggested in Appendix A.2.
If no local bootstrapks service is located using the GRASP If no local bootstrapks service is located using the GRASP
mechanisms, or the above mentioned DNS-based Service Discovery mechanisms, or the above mentioned DNS-based Service Discovery
methods, the Pledge MAY contact a well known manufacturer provided methods, the Pledge MAY contact a well known manufacturer provided
bootstrapping server by performing a DNS lookup using a well known bootstrapping server by performing a DNS lookup using a well known
URI such as "bootstrapks.manufacturer-example.com". The details of URI such as "bootstrapks.manufacturer-example.com". The details of
the URI are manufacturer specific. Manufacturers that leverage this the URI are manufacturer specific. Manufacturers that leverage this
method on the Pledge are responsible for providing the bootstrapks method on the Pledge are responsible for providing the bootstrapks
service. service. Also see Section 2.7.
The current DNS services returned during each query are maintained The current DNS services returned during each query are maintained
until bootstrapping is completed. If bootstrapping fails and the until bootstrapping is completed. If bootstrapping fails and the
Pledge returns to the Discovery state, it picks up where it left off Pledge returns to the Discovery state, it picks up where it left off
and continues attempting bootstrapping. For example, if the first and continues attempting bootstrapping. For example, if the first
Multicast DNS _bootstrapks._tcp.local response doesn't work then the Multicast DNS _bootstrapks._tcp.local response doesn't work then the
second and third responses are tried. If these fail the Pledge moves second and third responses are tried. If these fail the Pledge moves
on to normal DNS-based Service Discovery. on to normal DNS-based Service Discovery.
Appendix C. IPIP Join Proxy mechanism Appendix C. IPIP Join Proxy mechanism
skipping to change at page 68, line 12 skipping to change at page 72, 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 Fount
ain 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:
skipping to change at page 69, line 45 skipping to change at page 73, line 45
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 Highw
ay 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-0
0-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)
 End of changes. 98 change blocks. 
319 lines changed or deleted 478 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/