draft-ietf-anima-bootstrapping-keyinfra-11.txt   draft-ietf-anima-bootstrapping-keyinfra-12.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: August 24, 2018 SSW Expires: September 6, 2018 SSW
M. Behringer M. Behringer
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
K. Watsen K. Watsen
Juniper Networks Juniper Networks
2 20, 2018 March 5, 2018
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-11 draft-ietf-anima-bootstrapping-keyinfra-12
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 August 24, 2018. This Internet-Draft will expire on September 6, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Other Bootstrapping Approaches . . . . . . . . . . . . . 5 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 8 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 9
1.3.1. Support enironment . . . . . . . . . . . . . . . . . 9
1.3.2. Constrained enironments . . . . . . . . . . . . . . . 9
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 . . . 10
1.5. Requirements for Autonomic Network Infrastructure (ANI) 1.5. Requirements for Autonomic Network Infrastructure (ANI)
devices . . . . . . . . . . . . . . . . . . . . . . . . . 10 devices . . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 11 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 11
2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 12 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 13
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 14 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 14
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 15 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 15
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 16 2.3.1. Identification of the Pledge . . . . . . . . . . . . 15
2.4.1. Architectural component: Pledge . . . . . . . . . . . 18 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 16
2.4.2. Architectural component: Circuit Proxy . . . . . . . 18 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 17
2.4.3. Architectural component: Domain Registrar . . . . . . 18 2.4.1. Architectural component: Pledge . . . . . . . . . . . 19
2.4.4. Architectural component: Manufacturer Service . . . . 18 2.4.2. Architectural component: Circuit Proxy . . . . . . . 19
2.5. Lack of realtime clock . . . . . . . . . . . . . . . . . 18 2.4.3. Architectural component: Domain Registrar . . . . . . 19
2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 19 2.4.4. Architectural component: Manufacturer Service . . . . 19
2.7. Determining the MASA to contact . . . . . . . . . . . . . 20 2.4.5. Architectural component: Public Key Infrastructure
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 20 (PKI) . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 20 2.5. Certificate Time Validation . . . . . . . . . . . . . . . 20
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1. Lack of realtime clock . . . . . . . . . . . . . . . 20
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 20
4. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 21
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 27 2.7. Determining the MASA to contact . . . . . . . . . . . . . 21
4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 28 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 22
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 28 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 22
4.3. HTTPS Proxy connection to Registrar . . . . . . . . . . . 28 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 29 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 30 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 28
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 32 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 29
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 32 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 30
5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 34 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 31
5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 34 4.3. Proxy discovery of Registrar . . . . . . . . . . . . . . 31
5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 37 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 33
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 35
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 35
5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 36
5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 37
5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 39
5.5.1. Completing authentication of Provisional TLS 5.5.1. Completing authentication of Provisional TLS
connection . . . . . . . . . . . . . . . . . . . . . 38 connection . . . . . . . . . . . . . . . . . . . . . 41
5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 39 5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 41
5.7. MASA authorization log Request . . . . . . . . . . . . . 40 5.7. MASA authorization log Request . . . . . . . . . . . . . 42
5.7.1. MASA authorization log Response . . . . . . . . . . . 41 5.7.1. MASA authorization log Response . . . . . . . . . . . 43
5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 42 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 45
5.8.1. EST Distribution of CA Certificates . . . . . . . . . 43 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 45
5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 43 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 46
5.8.3. EST Client Certificate Request . . . . . . . . . . . 44 5.8.3. EST Client Certificate Request . . . . . . . . . . . 47
5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 44 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 47
5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 45 5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 48
6. Reduced security operational modes . . . . . . . . . . . . . 45 6. Reduced security operational modes . . . . . . . . . . . . . 48
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 46 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 48
6.2. Pledge security reductions . . . . . . . . . . . . . . . 46 6.2. Pledge security reductions . . . . . . . . . . . . . . . 49
6.3. Registrar security reductions . . . . . . . . . . . . . . 47 6.3. Registrar security reductions . . . . . . . . . . . . . . 50
6.4. MASA security reductions . . . . . . . . . . . . . . . . 48 6.4. MASA security reductions . . . . . . . . . . . . . . . . 50
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
7.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 49 7.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 51
7.2. Voucher Status Telemetry . . . . . . . . . . . . . . . . 49 7.2. Voucher Status Telemetry . . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 51 8.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 54
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 8.2. Trusting manufacturers . . . . . . . . . . . . . . . . . 55
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
10.1. Normative References . . . . . . . . . . . . . . . . . . 52 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
10.2. Informative References . . . . . . . . . . . . . . . . . 55 10.1. Normative References . . . . . . . . . . . . . . . . . . 56
Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . 59
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 57 Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 61
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 57 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 61
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 57 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 61
Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 58 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 61
C.1. Multiple Join networks on the Join Proxy side . . . . . . 58 Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 62
C.2. Automatic configuration of tunnels on Registrar . . . . . 59 C.1. Multiple Join networks on the Join Proxy side . . . . . . 62
C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 59 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 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on
Registrar . . . . . . . . . . . . . . . . . . . . . . . . 60 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 64
C.5. Use of socket extension rather than virtual interface . . 60
Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 60 C.5. Use of socket extension rather than virtual interface . . 64
Appendix E. Example Vouchers . . . . . . . . . . . . . . . . . . 62 Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 64
E.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 62 Appendix E. Example Vouchers . . . . . . . . . . . . . . . . . . 66
E.1.1. MASA key pair for voucher signatures . . . . . . . . 62 E.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 66
E.1.2. Manufacturer key pair for IDevID signatures . . . . . 62 E.1.1. MASA key pair for voucher signatures . . . . . . . . 66
E.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 63 E.1.2. Manufacturer key pair for IDevID signatures . . . . . 66
E.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 65 E.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 67
E.2. Example process . . . . . . . . . . . . . . . . . . . . . 66 E.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 69
E.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 66 E.2. Example process . . . . . . . . . . . . . . . . . . . . . 70
E.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 72 E.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 70
E.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 78 E.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 E.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction 1. Introduction
BRSKI provides a foundation to securely answer the following BRSKI provides a solution for secure zero-touch (automated) bootstrap
questions between an element of the network domain called the of virgin (untouched) devices that are called Pledges in this
"Registrar" and an unconfigured and untouched device called a document. These Pledges need to discover (or be discovered by) an
"Pledge": element of the network domain to which the Pledge belongs to perform
the bootstrap. This element (device) is called the (Domain Join)
Registrar. Before any other operation, Pledge and Registrar need to
establish mutual trust:
o Registrar authenticating the Pledge: "Who is this device? What is 1. Registrar authenticating the Pledge: "Who is this device? What
its identity?" is its identity?"
o Registrar authoring the Pledge: "Is it mine? Do I want it? What 2. Registrar authoring the Pledge: "Is it mine? Do I want it? What
are the chances it has been compromised?" are the chances it has been compromised?"
o Pledge authenticating the Registrar/Domain: "What is this domain's 3. Pledge authenticating the Registrar/Domain: "What is this
identity?" domain's identity?"
o Pledge authorizing the Registrar: "Should I join it?" 4. Pledge authorizing the Registrar: "Should I join it?"
This document details protocols and messages to the endpoints to This document details protocols and messages to answer the above
answer the above questions. The Registrar actions derive from Pledge questions. It uses a TLS connection and an PKIX (X.509v3)
identity, third party cloud service communications, and local access certificate (an IEEE 802.1AR [IDevID] LDevID) of the Pledge to answer
control lists. The Pledge actions derive from a cryptographically points 1 and 2. It uses a new artifact called a "voucher" that the
protected "voucher" message delivered through the Registrar but registrar receives from a "Manufacturer Authorized Signing Authority"
originating at a Manufacturer Authorized Signing Authority. and passes to the Pledge to answer points 3 and 2.
A proxy provides very limited connectivity between the pledge and the
Registrar.
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]. This document details automated protocol [I-D.ietf-anima-voucher]. This document details automated protocol
mechanisms to obtain vouchers, including the definition of a mechanisms to obtain vouchers, including the definition of a
'voucher-request' message that is a minor extension to the voucher 'voucher-request' message that is a minor extension to the voucher
format (see Section 3) defined by [I-D.ietf-anima-voucher]. format (see Section 3) defined by [I-D.ietf-anima-voucher].
BRSKI results in the Pledge storing an X.509 root certificate BRSKI results in the Pledge storing an X.509 root certificate
sufficient for verifying the Registrar identity. In the process a sufficient for verifying the Registrar identity. In the process a
TLS connection is established that can be directly used for TLS connection is established that can be directly used for
skipping to change at page 5, line 9 skipping to change at page 5, line 22
Certificates" described in [RFC7030] Section 4.1.1 wherein the Pledge Certificates" described in [RFC7030] Section 4.1.1 wherein the Pledge
"MUST [...] engage a human user to authorize the CA certificate using "MUST [...] engage a human user to authorize the CA certificate using
out-of-band" information". With BRSKI the Pledge now can automate out-of-band" information". With BRSKI the Pledge now can automate
this process using the voucher. Integration with a complete EST this process using the voucher. Integration with a complete EST
enrollment is optional but trivial. enrollment is optional but trivial.
BRSKI is agile enough to support bootstrapping alternative key BRSKI is agile enough to support bootstrapping alternative key
infrastructures, such as a symmetric key solutions, but no such infrastructures, such as a symmetric key solutions, but no such
system is described in this document. system is described in this document.
1.1. Other Bootstrapping Approaches 1.1. Prior Bootstrapping Approaches
To literally "pull yourself up by the bootstraps" is an impossible To literally "pull yourself up by the bootstraps" is an impossible
action. Similarly the secure establishment of a key infrastructure action. Similarly the secure establishment of a key infrastructure
without external help is also an impossibility. Today it is commonly without external help is also an impossibility. Today it is commonly
accepted that the initial connections between nodes are insecure, accepted that the initial connections between nodes are insecure,
until key distribution is complete, or that domain-specific keying until key distribution is complete, or that domain-specific keying
material (often pre-shared keys, including mechanisms like SIM cards) material (often pre-shared keys, including mechanisms like SIM cards)
is pre-provisioned on each new device in a costly and non-scalable is pre-provisioned on each new device in a costly and non-scalable
manner. Existing mechanisms are known as non-secured 'Trust on First manner. Existing automated mechanisms are known as non-secured
Use' (TOFU) [RFC7435], 'resurrecting duckling' 'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling'
[Stajano99theresurrecting] or 'pre-staging'. [Stajano99theresurrecting] or 'pre-staging'.
Another approach is to try and minimize user actions during Another prior approach has been to try and minimize user actions
bootstrapping. The enrollment protocol EST [RFC7030] details a set during bootstrapping, but not eliminate all user-actions. The
of non-autonomic bootstrapping methods in this vein: original EST protocol [RFC7030] does reduce user actions during
bootstrap but does not provide solutions for how the following
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 (not an autonomic
solution because the URL must be securely distributed), 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
skipping to change at page 8, line 45 skipping to change at page 9, line 12
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
This solution (BRSKI) can support large router platforms with multi-
gigabit inter-connections, mounted in controlled access data centers.
But this solution is not exclusive to large equipment: it is intended
to scale to thousands of devices located in hostile environments,
such as ISP provided CPE devices which are drop-shipped to the end
user. The situation where an order is fulfilled from distributed
warehouse from a common stock and shipped directly to the target
location at the request of a domain owner is explicitly supported.
That stock ("SKU") could be provided to a number of potential domain
owners, and the eventual domain owner will not know a-priori which
device will go to which location.
The bootstrapping process can take minutes to complete depending on
the network infrastructure and device processing speed. The network
communication itself is not optimized for speed; for privacy reasons,
the discovery process allows for the Pledge to avoid announcing its
presence through broadcasting.
Nomadic or mobile devices often need to aquire credentials to access
the network at the new location. An example of this is mobile phone
roaming among network operators, or even between cell towers. This
is usually called handoff. BRSKI does not provide a low-latency
handoff which is usually a requirement in such situations. For these
solutions BRSKI can be used to create a relationship (an LDevID) with
the "home" domain owner. The resulting credentials are then used to
provide credentials more appropriate for a low-latency handoff.
1.3.2. Constrained enironments
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
(such as 802.15.4 LLNs). (such as 802.15.4 LLNs).
In many target applications, the systems involved are large router
platforms with multi-gigabit inter-connections, mounted in controlled
access data centers. But this solution is not exclusive to the
large, it is intended to scale to thousands of devices located in
hostile environments, such as ISP provided CPE devices which are
drop-shipped to the end user. The situation where an order is
fulfilled from distributed warehouse from a common stock and shipped
directly to the target location at the request of the domain owner is
explicitly supported. That stock ("SKU") could be provided to a
number of potential domain owners, and the eventual domain owner will
not know a-priori which device will go to which location.
The bootstrapping process can take minutes to complete depending on
the network infrastructure and device processing speed. The network
communication itself is not optimized for speed; for privacy reasons,
the discovery process allows for the Pledge to avoid announcing its
presence through broadcasting.
This protocol is not intended for low latency handoffs. In networks
requiring such things, the Pledge SHOULD already have been enrolled.
Specifically, there are protocol aspects described here that might Specifically, there are protocol aspects described here that might
result in congestion collapse or energy-exhaustion of intermediate result in congestion collapse or energy-exhaustion of intermediate
battery powered routers in an LLN. Those types of networks SHOULD battery powered routers in an LLN. Those types of networks SHOULD
NOT use this solution. These limitations are predominately related NOT use this solution. These limitations are predominately related
to the large credential and key sizes required for device to the large credential and key sizes required for device
authentication. Defining symmetric key techniques that meet the authentication. Defining symmetric key techniques that meet the
operational requirements is out-of-scope but the underlying protocol operational requirements is out-of-scope but the underlying protocol
operations (TLS handshake and signing structures) have sufficient operations (TLS handshake and signing structures) have sufficient
algorithm agility to support such techniques when defined. algorithm agility to support such techniques when defined.
The imprint protocol described here could, however, be used by non- The imprint protocol described here could, however, be used by non-
energy constrained devices joining a non-constrained network (for energy constrained devices joining a non-constrained network (for
instance, smart light bulbs are usually mains powered, and speak instance, smart light bulbs are usually mains powered, and speak
802.11). It could also be used by non-constrained devices across a 802.11). It could also be used by non-constrained devices across a
non-energy constrained, but challenged network (such as 802.15.4). non-energy constrained, but challenged network (such as 802.15.4).
The certificate contents, and the process by which the four questions The certificate contents, and the process by which the four questions
above are resolved do apply to constrained devices. It is simply the above are resolved do apply to constrained devices. It is simply the
actual on-the-wire imprint protocol that could be inappropriate. actual on-the-wire imprint protocol that could be inappropriate.
1.3.3. Network Access Controls
This document presumes that network access control has either already This document presumes that network access control has either already
occurred, is not required, or is integrated by the Proxy and occurred, is not required, or is integrated by the Proxy and
Registrar in such a way that the device itself does not need to be Registrar in such a way that the device itself does not need to be
aware of the details. Although the use of an X.509 Initial Device aware of the details. Although the use of an X.509 Initial Device
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.
skipping to change at page 11, line 4 skipping to change at page 11, line 31
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 Registrar (JRC) MUST support all the BRSKI and above listed
EST operations. 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 may be
enabled only if the JRC indicates support for them in it's enabled only if the JRC indicates support for them in it's
announcement. (See Section 4.4) 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. Each component is logical and may be combined with other components.
components as necessary.
+------------------------+ +------------------------+
+--------------Drop Ship--------------->| Vendor Service | +--------------Drop Ship--------------->| Vendor Service |
| +------------------------+ | +------------------------+
| | M anufacturer| | | | M anufacturer| |
| | A uthorized |Ownership| | | A uthorized |Ownership|
| | S igning |Tracker | | | S igning |Tracker |
| | A uthority | | | | A uthority | |
| +--------------+---------+ | +--------------+---------+
| ^ | ^
skipping to change at page 14, line 24 skipping to change at page 14, line 29
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
TA (trust anchor) (pinned-domain-cert in the Voucher response). A
secure transport exists between pledge and registrar, and it may be
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
detail in [I-D.ietf-anima-voucher]. detail in [I-D.ietf-anima-voucher].
Vouchers provide a flexible mechanism to secure imprinting: the Vouchers provide a flexible mechanism to secure imprinting: the
Pledge device only imprints when a voucher can be validated. At the Pledge device only imprints when a voucher can be validated. At the
lowest security levels the MASA server can indiscriminately issue lowest security levels the MASA server can indiscriminately issue
vouchers. At the highest security levels issuance of vouchers can be vouchers and log claims of ownership by domains. At the highest
integrated with complex sales channel integrations that are beyond security levels issuance of vouchers can be integrated with complex
the scope of this document. This provides the flexibility for a sales channel integrations that are beyond the scope of this
number of use cases via a single common protocol mechanism on the document. The sales channel integration would verify actual (legal)
Pledge and Registrar devices that are to be widely deployed in the ownership of the pledge by the domain. This provides the flexibility
field. The MASA services have the flexibility to leverage either the for a number of use cases via a single common protocol mechanism on
currently defined claim mechanisms or to experiment with higher or the Pledge and Registrar devices that are to be widely deployed in
lower security levels. the field. The MASA services have the flexibility to leverage either
the currently defined claim mechanisms or to experiment with higher
or lower security levels.
Vouchers provide a signed but non-encrypted communication channel Vouchers provide a signed but non-encrypted communication channel
among the Pledge, the MASA, and the Registrar. The Registrar among the Pledge, the MASA, and the Registrar. The Registrar
maintains control over the transport and policy decisions allowing maintains control over the transport and policy decisions allowing
the local security policy of the domain network to be enforced. the local security policy of the domain network to be enforced.
2.3. Initial Device Identifier 2.3. Initial Device Identifier
Pledge authentication and Pledge voucher-request signing is via an Pledge authentication and Pledge voucher-request signing is via a
X.509 certificate installed during the manufacturing process. This PKIX certificate installed during the manufacturing process. This is
Initial Device Identifier provides a basis for authenticating the the 802.1AR Initial Device Identifier (IDevID), and it provides a
Pledge during subsequent protocol exchanges and informing the basis for authenticating the Pledge during the protocol exchanges
Registrar of the MASA URI. There is no requirement for a common root described here. There is no requirement for a common root PKI
PKI hierarchy. Each device manufacturer can generate its own root hierarchy. Each device manufacturer can generate its own root
certificate. certificate. Specifically, the IDevID:
The following previously defined fields are in the X.509 IDevID 1. Uniquely identifying the pledge by the Distinguished Name (DN)
certificate: and subjectAltName (SAN) parameters in the IDevID. The unique
identification of a pledge in the voucher objects are derived
from those parameters as described below.
2. Securely authentating the pledges identity via TLS connection to
registrar. This provides protection against cloned/fake pledged.
3. Secure auto-discovery of the pledges MASA by the registrar via
the MASA URI in IDevID as explained below.
4. (Optionally) communicating the MUD URL (see Appendix D.
5. (Optional) Signing of voucher-request by the pledges IDevID to
enable MASA to generate voucher only to a registrar that has a
connection to the pledge.
6. Authorizing pledge (via registrar) to receive certificate from
domain CA, by signing the Certificate Signing Request (CSR).
2.3.1. Identification of the Pledge
In the context of BRSKI, pledges are uniquely identified by a
"serial-number". This serial-number is used both in the "serial-
number" field of Voucher or Voucher requests (see Section 3) and in
local policies on Registrar or MASA (see Section 5).
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.
o The subject-alt field's encoding SHOULD include a non-critical o The subject-alt field's encoding SHOULD include a non-critical
version of the RFC4108 defined HardwareModuleName. version of the RFC4108 defined HardwareModuleName.
In order to build the voucher "serial-number" field these IDevID and they are used as follows to build pledge "serial-number". In
fields need to be converted into a serial-number of "type string". order to build it, the fields need to be converted into a serial-
The following methods are used depending on the first available number of "type string". The following methods are used depending on
IDevID certificate field (attempted in this order): the first available IDevID certificate field (attempted in this
order):
o An RFC4514 String Representation of the Distinguished Name o An RFC4514 String Representation of the Distinguished Name
"serialNumber" attribute. "serialNumber" attribute.
o The HardwareModuleName hwSerialNum OCTET STRING base64 encoded. o The HardwareModuleName hwSerialNum OCTET STRING base64 encoded.
o The RFC4514 String Representation of the Distinguished Name o The RFC4514 String Representation of the Distinguished Name
"common name" attribute. "common name" attribute.
The following newly defined field SHOULD be in the X.509 IDevID 2.3.2. MASA URI extension
certificate: An X.509 non-critical certificate extension that
contains a single Uniform Resource Identifier (URI) that points to an The following newly defined field SHOULD be in the PKIX IDevID
on-line Manufacturer Authorized Signing Authority. The URI is certificate: A PKIX non-critical certificate extension that contains
represented as described in Section 7.4 of [RFC5280]. a single Uniform Resource Identifier (URI) that points to an on-line
Manufacturer Authorized Signing Authority. The URI is represented as
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
URIs as specified in Section 3.1 of [RFC3987] before they are placed URIs as specified in Section 3.1 of [RFC3987] before they are placed
in the certificate extension. The URI provides the authority in the certificate extension. The URI provides the authority
information. The BRSKI "/.well-known" tree ([RFC5785]) is described information. The BRSKI "/.well-known" tree ([RFC5785]) is described
in Section 5. in Section 5.
The new extension is identified as follows: The new extension is identified as follows:
<CODE BEGINS> <CODE BEGINS>
skipping to change at page 18, line 8 skipping to change at page 19, line 8
|<--------------------------------------->| | |<--------------------------------------->| |
| 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.4.1. Architectural component: 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 network connectivity Pledge completes the enrollment process, it has link-local network
only to the Proxy. connectivity only to the Proxy.
2.4.2. Architectural component: Circuit Proxy 2.4.2. Architectural component: Circuit Proxy
The (Circuit) Proxy provides HTTPS connectivity between the Pledge The (Circuit) Proxy provides HTTPS connectivity between the Pledge
and the Registrar. The Proxy mechanism is described in Section 4, and the Registrar. The circuit proxy mechanism is described in
with an optional stateless mechanism described in Appendix C. Section 4, with an optional stateless proxy mechanism described in
Appendix C.
2.4.3. Architectural component: Domain Registrar 2.4.3. Architectural component: Domain Registrar
The Domain Registrar (having the formal name Join Registrar/ The Domain Registrar (having the formal name Join Registrar/
Coordinator (JRC), operates as a CMC Registrar, terminating the EST Coordinator (JRC)), operates as a CMC Registrar, (Certificate
and BRSKI connections. The Registrar is manually configured or Management over CMS, see [RFC5272] section 7) terminating the EST and
BRSKI connections. The Registrar is manually configured or
distributed with a list of trust anchors necessary to authenticate distributed with a list of trust anchors necessary to authenticate
any Pledge device expected on the network. The Registrar any Pledge device expected on the network. The Registrar
communicates with the MASA to establish ownership. communicates with the MASA to establish ownership.
2.4.4. Architectural component: Manufacturer Service 2.4.4. Architectural component: Manufacturer Service
The Manufacturer Service provides two logically seperate functions: The Manufacturer Service provides two logically seperate functions:
the Manufacturer Authorized Signing Authority (MASA), and an the Manufacturer Authorized Signing Authority (MASA) described in
ownership tracking/auditing function. Section 5.4 and Section 5.5, and an ownership tracking/auditing
function described in Section 5.6 and Section 5.7.
2.5. Lack of realtime clock 2.4.5. Architectural component: Public Key Infrastructure (PKI)
The Key Infrastructure (PKI) administers certificates for the domain
of concerns, providing the trust anchor(s) for it and allowing
enrollment of Pledges with domain certificates.
The Domain Registrar uses a Trust Anchor (TE) from the PKI in the
BRSKI Voucher pinned-domain-cert to authenticate itself to the Pledge
with the help of MASA. (XXX fix me)
The Domain Registrar acts as an [RFC5272] Registration Authority,
requesting certificates for Pledges from the Key Infrastructure.
The above requirements and expectations against the Key
Infrastructure are unchanged from RFC7030. This document does not
place any additional architectural requirements on the Public Key
Infrastructure.
2.5. Certificate Time Validation
2.5.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"
of presumed time validity that is continually refined throughout the of presumed time validity that is continually refined throughout the
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 During Pledge authentiation by the Registrar a realtime clock can o Bootstrapping Pledges that have a Realtime Clock (RTC), SHOULD use
be used by the Registrar. This bullet expands on a closely it to verify certificate validity. However, they MUST be prepared
related issue regarding Pledge lifetimes. RFC5280 indicates that for the recognize that the RTC might be completely wrong when a
long lived Pledge certifiates "SHOULD be assigned the RTC battery fails and resets to an origin time (e.g., Jan. 1,
GeneralizedTime value of 99991231235959Z" [RFC7030], so the 1970)
Registrar MUST support such lifetimes and SHOULD support ignoring
Pledge lifetimes if they did not follow the RFC5280
recommendations.
o The Pledge authenticates the voucher presented to it. During this o The Pledge authenticates the voucher presented to it. During this
authentication the Pledge ignores certificate lifetimes (by authentication the Pledge ignores certificate lifetimes (by
necessity because it does not have a realtime clock). necessity because it does not have a realtime clock).
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).
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. Any
subsequent certificate validity periods checked during RFC5280 subsequent certificate validity periods checked during RFC5280
path validation MUST occur within this window. path validation MUST occur within this window.
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
[RFC5280] explains that long lived Pledge certificates "SHOULD be
assigned the GeneralizedTime value of 99991231235959Z". Registrars
MUST support such lifetimes and SHOULD support ignoring Pledge
lifetimes if they did not follow the RFC5280 recommendations.
For example, IDevID may have incorrect lifetime of N <= 3 years,
rendering replacement Pledges from storage useless after N years
unless registrars support ignoring such a lifetime.
2.6. Cloud Registrar 2.6. Cloud Registrar
There are transitional situations where devices may be deployed into There are transitional situations where devices may be deployed into
legacy networks that use proprietary bootstrapping mechanisms based legacy networks that use proprietary bootstrapping mechanisms based
upon the base EST ([RFC7030]). The same device may also be deployed upon the base EST ([RFC7030]). The same device may also be deployed
into an ANIMA environment. This may be due to incremental into an ANIMA environment. This may be due to incremental
replacement of a legacy situation with ANIMA. replacement of a legacy situation with ANIMA.
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
skipping to change at page 20, line 31 skipping to change at page 22, line 13
aligning current Pledge manufacturing with software releases and aligning current Pledge manufacturing with software releases and
development. As a final fallback the Registrar MAY be manually development. As a final fallback the Registrar MAY be manually
configured or distributed with a MASA URL for each manufacturer. configured or distributed with a MASA URL for each manufacturer.
Note that the Registrar can only select the configured MASA URL based Note that the Registrar can only select the configured MASA URL based
on the trust anchor -- so manufacturers can only leverage this on the trust anchor -- so manufacturers can only leverage this
approach if they ensure a single MASA URL works for all Pledge's approach if they ensure a single MASA URL works for all Pledge's
associated with each trust anchor. associated with each trust anchor.
3. Voucher-Request artifact 3. Voucher-Request artifact
The Pledge voucher-request is how a Pledge requests a voucher. The Voucher-requests are how vouchers are requested. The semantics of
Pledge forms a voucher-request and submits it to the Registrar. The the vouchers are described below, in the YANG model.
Registrar in turn submits a voucher-request to the MASA server. To
help differentiate this document refers to "Pledge voucher-request" A Pledge forms the "Pledge voucher-request" and submits it to the
and "Registrar voucher-request" when indicating the source is Registrar.
beneficial. The "proximity-registrar-cert" leaf defined in this
section is used in Pledge voucher-requests. The "prior-signed- The Registrar in turn forms the "Registrar voucher-request", and
voucher-request" is used in Registrar voucher-requests that include a submits it to the MASA server.
Pledge voucher-request.
The "proximity-registrar-cert" leaf is used in the Pledge voucher-
requests.
The "prior-signed-voucher-request" leaf is be used in Registrar
voucher-requests to the Pledge voucher-request. It contains the
encoded (signed form) of the Pledge voucher-request.
A Registar MAY also retrieve (nonceless) vouchers by sending voucher-
requests to the MASA. No "prior-signed-voucher-request" leaf would
be included. This can be used to retrieve vouchers for later offline
use. The Registrar will need to know the serial number of the
pledge. This document does not provide a mechanism for the Registrar
to learn that in an automated fashion. Typically this will be done
via scanning of bar-code or QR-code on packaging, or via some sales
channel integration.
Unless otherwise signaled (outside the voucher-request artifact), the Unless otherwise signaled (outside the voucher-request artifact), the
signing structure is as defined for vouchers, see 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 21, line 23 skipping to change at page 23, line 23
+---- idevid-issuer? binary +---- idevid-issuer? binary
+---- pinned-domain-cert? binary +---- pinned-domain-cert? binary
+---- domain-cert-revocation-checks? boolean +---- domain-cert-revocation-checks? boolean
+---- nonce? binary +---- nonce? binary
+---- last-renewal-date? yang:date-and-time +---- last-renewal-date? yang:date-and-time
+---- prior-signed-voucher-request? binary +---- prior-signed-voucher-request? binary
+---- proximity-registrar-cert? binary +---- proximity-registrar-cert? binary
3.2. Examples 3.2. Examples
This section provides voucher examples for illustration purposes. This section provides voucher-request examples for illustration
These examples conform to the encoding rules defined in [RFC7951]. purposes. These examples conform to the encoding rules defined in
[RFC7951].
Example (1) The following example illustrates a Pledge voucher- Example (1) The following example illustrates a Pledge voucher-
request. The assertion leaf is indicated as 'proximity' request. The assertion leaf is indicated as 'proximity'
and the Registrar's TLS server certificate is included and the Registrar's TLS server certificate is included
in the 'proximity-registrar-cert' leaf. See in the 'proximity-registrar-cert' leaf. See
Section 5.2. Section 5.2.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
skipping to change at page 23, line 27 skipping to change at page 25, line 27
import ietf-restconf { import ietf-restconf {
prefix rc; prefix rc;
description "This import statement is only present to access description "This import statement is only present to access
the yang-data extension defined in RFC 8040."; the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol"; reference "RFC 8040: RESTCONF Protocol";
} }
import ietf-voucher { import ietf-voucher {
prefix v; prefix v;
description "This module defines the format for a voucher, which is produced by description "This module defines the format for a voucher,
a pledge's manufacturer or delegate (MASA) to securely assign a which is produced by a pledge's manufacturer or
pledge to an 'owner', so that the pledge may establish a secure delegate (MASA) to securely assign a pledge to
an 'owner', so that the pledge may establish a secure
conn ection to the owner's network infrastructure"; conn ection to the owner's network infrastructure";
reference "RFC YYYY: Voucher Profile for Bootstrapping Protocols"; reference "RFC YYYY: Voucher Profile for Bootstrapping Protocols";
} }
organization organization
"IETF ANIMA Working Group"; "IETF ANIMA Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/anima/> "WG Web: <http://tools.ietf.org/wg/anima/>
skipping to change at page 23, line 52 skipping to change at page 26, line 4
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Author: Max Pritikin Author: Max Pritikin
<mailto:pritikin@cisco.com> <mailto:pritikin@cisco.com>
Author: Michael Richardson Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca> <mailto:mcr+ietf@sandelman.ca>
Author: Toerless Eckert Author: Toerless Eckert
<mailto:tte+ietf@cs.fau.de>"; <mailto:tte+ietf@cs.fau.de>";
description description
"This module module defines the format for a voucher request. "This module module defines the format for a voucher request.
It is a superset of the voucher itself.
It is a superset of the voucher itself.
This artifact may be optionally signed. This artifact may be optionally signed.
It provides content to the MASA for consideration It provides content to the MASA for consideration
during a voucher request. during a voucher request.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in
the module text are to be interpreted as described in RFC 2119. the module text are to be interpreted as described in RFC 2119.
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2017 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
skipping to change at page 26, line 4 skipping to change at page 28, line 4
Pledge's voucher request if the proximity assertion is Pledge's voucher request if the proximity assertion is
populated."; populated.";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4. Proxy details 4. Proxying details (Pledge - Proxy - Registrar)
The role of the Proxy is to facilitate communications. The Proxy The role of the Proxy is to facilitate communications. The Proxy
forwards packets between the Pledge and a Registrar that has been forwards packets between the Pledge and a Registrar that has been
configured on the Proxy. provisioned to the Proxy via GRASP discovery.
This section defines a stateful proxy mechanism which is refered to
as a "circuit" proxy.
The Proxy does not terminate the TLS handshake: it passes streams of The Proxy does not terminate the TLS handshake: it passes streams of
bytes onward without examination. bytes onward without examination.
A Proxy MAY assume TLS framing for auditing purposes, but MUST NOT A Proxy MAY assume TLS framing for auditing purposes, but MUST NOT
assume any TLS version. assume any TLS version.
A Proxy is always assumed even if it is directly integrated into a Registrars are assumed to have logically a locally integrated Proxy
Registrar. (In a completely autonomic network, the Registrar MUST to support directly (subnet) connected Pledges - because Registrars
provide Proxy functionality so that it can be discovered, and the themself does not define any functions for Pledges to discover them.
network can grow concentrically around the Registrar.) Such a logical local proxy does not need to provide actual TCP
proxying (just discovery) as long as the Registrar can operate with
subnet (link) local addresses on the interfaces where Pledges may
connect to.
As a result of the Proxy Discovery process in Section 4.1.1, the port As a result of the Proxy Discovery process in Section 4.1.1, the port
number exposed by the Proxy does not need to be well known, or number exposed by the Proxy does not need to be well known, or
require an IANA allocation. require an IANA allocation.
If the Proxy joins an Autonomic Control Plane In the ANI, the Autonomic Control Plane (ACP) secured instance of
([I-D.ietf-anima-autonomic-control-plane]) it SHOULD use Autonomic GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI
Control Plane secured GRASP ([I-D.ietf-anima-grasp]) to discover the Registrar ACP addresses and ports by ANI Proxies. The TCP leg of the
Registrar address and port. As part of the discovery process, the proxy connection between ANI Proxy and ANI Registrar therefore also
Proxy mechanism (Circuit Proxy vs IPIP encapsulation) is agreed to runs across the ACP.
between the Registrar and Join Proxy.
If GRASP is used by proxies for discovery of Registrars (ACP or not),
the proxy can also learn the proxy mechanism (Circuit Proxy vs. IPIP
encapsulation or other)
For the IPIP encapsulation methods (described in Appendix C), the For the IPIP encapsulation methods (described in Appendix C), the
port announced by the Proxy SHOULD be the same as on the Registrar in port announced by the Proxy SHOULD be the same as on the Registrar in
order for the Proxy to remain stateless. order for the Proxy to remain stateless.
In order to permit the Proxy functionality to be implemented on the In order to permit the Proxy functionality to be implemented on the
maximum variety of devices the chosen mechanism SHOULD use the maximum variety of devices the chosen mechanism SHOULD use the
minimum amount of state on the Proxy device. While many devices in minimum amount of state on the Proxy device. While many devices in
the ANIMA target space will be rather large routers, the Proxy the ANIMA target space will be rather large routers, the Proxy
function is likely to be implemented in the control plane CPU of such function is likely to be implemented in the control plane CPU of such
skipping to change at page 27, line 32 skipping to change at page 29, line 36
2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp])
announcements of the objective: "AN_Proxy". See section announcements of the objective: "AN_Proxy". See section
Section 4.1.1 for the details of the objective. The Pledge MAY Section 4.1.1 for the details of the objective. The Pledge MAY
listen concurrently for other sources of information, see listen concurrently for other sources of information, see
Appendix B. Appendix B.
Once a Proxy is discovered the Pledge communicates with a Registrar Once a Proxy is discovered the Pledge communicates with a Registrar
through the Proxy using the bootstrapping protocol defined in through the Proxy using the bootstrapping protocol defined in
Section 5. Section 5.
Each discovery method attempted SHOULD exponentially back-off While the GRASP M_FLOOD mechanism is passive for the Pledge, the
attempts (to a maximum of one hour) to avoid overloading the network optional other methods (mDNS, and IPv4 methods) are active. The
infrastructure with discovery. The back-off timer for each method Pledge SHOULD run those methods in parallel with listening to for the
MUST be independent of other methods. M_FLOOD. The active methods SHOULD exponentially back-off to a
maximum of one hour to avoid overloading the network with discovery
attempts. Detection of change of physical link status (ethernet
carrier for instance) SHOULD reset the exponential back off.
Methods SHOULD be run in parallel to avoid head of queue problems The Pledge may discover more than one proxy on a given physical
wherein an attacker running a fake Proxy or Registrar can operate interface. The Pledge may have a multitude of physical interfaces as
protocol actions intentionally slowly. well: a layer-2/3 ethernet switch may have hundreds of physical
ports.
Each possible proxy offer SHOULD be attempted up to the point where a
voucher is received: while there are many ways in which the attempt
may fail, it does not succeed until the voucher has been validated.
The connection attempts via a single proxy SHOULD exponentially back-
off to a maximum of one hour to avoid overloading the network
infrastructure. The back-off timer for each MUST be independent of
other connection attempts.
Connection attempts SHOULD be run in parallel to avoid head of queue
problems wherein an attacker running a fake Proxy or Registrar could
perform protocol actions intentionally slowly. The Pledge SHOULD
continue to listen to for additional GRASP M_FLOOD messages during
the connection attempts.
Once a connection to a Registrar is established (e.g. establishment Once a connection to a Registrar is established (e.g. establishment
of a TLS session key) there are expectations of more timely of a TLS session key) there are expectations of more timely
responses, see Section 5.2. responses, see Section 5.2.
Once all discovered services are attempted the device SHOULD return Once all discovered services are attempted (assuming that none
to listening for GRASP M_FLOOD. It SHOULD periodically retry the succeeded) the device MUST return to listening for GRASP M_FLOOD. It
manufacturer specific mechanisms. The Pledge MAY prioritize SHOULD periodically retry the manufacturer specific mechanisms. The
selection order as appropriate for the anticipated environment. Pledge MAY prioritize selection order as appropriate for the
anticipated environment.
4.1.1. Proxy GRASP announcements 4.1.1. Proxy GRASP announcements
A Proxy uses the GRASP M_FLOOD mechanism to announce itself. The A Proxy uses the DULL GRASP M_FLOOD mechanism to announce itself.
Pledge SHOULD listen for messages of this form. This announcement This announcement can be within the same message as the ACP
can be within the same message as the ACP announcement detailed in announcement detailed in [I-D.ietf-anima-autonomic-control-plane].
[I-D.ietf-anima-autonomic-control-plane]. The M_FLOOD is formatted The M_FLOOD is formatted as follows:
as follows:
[M_FLOOD, 12340815, h'fe80::1', 180000, [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
["AN_Proxy", 4, 1, ""], ["AN_Proxy", 4, 1, ""],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe80::1', 'TCP', 4443]] h'fe800000000000000000000000000001', 'TCP', 4443]]
Figure 6b: Proxy Discovery Figure 6b: Proxy Discovery
The formal CDDL definition is: The formal CDDL definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_Proxy", objective-flags, loop-count, objective = ["AN_Proxy", objective-flags, loop-count,
objective-value] objective-value]
skipping to change at page 28, line 48 skipping to change at page 31, line 31
transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6
port-number = selected by Proxy port-number = selected by Proxy
Figure 6c: AN_Proxy CDDL Figure 6c: AN_Proxy CDDL
4.2. CoAP connection to Registrar 4.2. CoAP connection to Registrar
The use of CoAP to connect from Pledge to Registrar is out of scope The use of CoAP to connect from Pledge to Registrar is out of scope
for this document, and may be described in future work. for this document, and may be described in future work.
4.3. HTTPS Proxy connection to Registrar 4.3. Proxy discovery of Registrar
The Proxy SHOULD also provide one of: an IPIP encapsulation of HTTP
traffic to the Registrar, or a TCP circuit Proxy that connects the
Pledge to a Registrar.
When the Proxy provides a circuit Proxy to a Registrar the Registrar
MUST accept HTTPS connections.
4.4. Proxy discovery of Registrar
The Registrar SHOULD announce itself so that proxies can find it and The Registrar SHOULD announce itself so that proxies can find it and
determine what kind of connections can be terminated. determine what kind of connections can be terminated.
The Registrar announces itself using GRASP M_FLOOD messages. The The Registrar announces itself using ACP instance of GRASP using
M_FLOOD is formatted as follows: M_FLOOD messages. They MUST support ANI TLS circuit Proxy and
therefore BRSKI across HTTPS/TLS native across the ACP. ANI
Registrars MAY support the IPIP proxy method by implementing IPIP
tunneling for their HTTPS/TLS traffic across the ACP. ANI Proxies
MUST support GRASP discovery of Registrars.
[M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000, The M_FLOOD is formatted as follows:
[M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000,
["AN_join_registrar", 4, 255, "EST-TLS"], ["AN_join_registrar", 4, 255, "EST-TLS"],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fda379a6f6ee0000200000064000001', TCP, 80 h'fda379a6f6ee00000200000064000001', TCP, 80]]
Figure 7a: Registrar Discovery Figure 7a: Registrar Discovery
The formal CDDL definition is: The formal CDDL definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_join_registrar", objective-flags, loop-count, objective = ["AN_join_registrar", objective-flags, loop-count,
objective-value] objective-value]
skipping to change at page 33, line 34 skipping to change at page 36, line 11
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 functionality. The nonce MUST NOT be reused for Section 2.5.1 functionality. The nonce MUST NOT be reused for
bootstrapping attempts. 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 35, line 38 skipping to change at page 38, line 15
etc wrapped by the Pledge's original signature). etc wrapped by the Pledge's original signature).
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
certificate used to sign the Registrar voucher-request. Any of these certificate used to sign the Registrar voucher-request. Any of these
methods reduce the risk of DDoS attacks and provide an authenticated methods reduce the risk of DDoS attacks and provide an authenticated
identity as an input to sales channel integration and authorizations identity as an input to sales channel integration and authorizations
(the actual sale-channel integration is also out-of-scope of this (the actual sale-channel integration is also out-of-scope of this
document). document).
All other fields MAY be omitted in the Registrar voucher-request. All other fields MAY be omitted in the Registrar voucher-request.
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.
skipping to change at page 37, line 47 skipping to change at page 40, line 25
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/pkcs7-mime; smime-type=voucher The response is a "YANG-
defined JSON document that has been signed using a PKCS#7 defined JSON document that has been signed using a PKCS#7
structure" as described in [I-D.ietf-anima-voucher] using the structure" as described in [I-D.ietf-anima-voucher] using the JSON
JSON encoded described in [RFC7951]. The MASA MUST sign the encoded described in [RFC7951]. The MASA MUST sign the request.
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"
skipping to change at page 38, line 51 skipping to change at page 41, line 25
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. Once the validity period information is as described in Section 2.5.1. Once
PKIX path validation is successful the TLS connection is no longer the PKIX path validation is successful the TLS connection is no
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 EST
section 4.1.3 CA Certificate Response, which is an additional section 4.1.3 CA Certificate Response, which is an additional
skipping to change at page 47, line 18 skipping to change at page 49, line 45
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 to ensure new entities can always be deployed even when autonomic
methods fail. This allows for unsecured imprint. 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.
These methods are acceptable when low security models are needed, as These methods are acceptable when low security models are needed, as
the security decisions are being made by the local administrator, but the security decisions are being made by the local administrator, but
they MUST NOT be the default behavior: they MUST NOT be the default behavior:
skipping to change at page 52, line 35 skipping to change at page 55, line 20
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
The BRSKI extensions to EST permit a new pledge to be completely
configured with domain specific trust anchors. The link from built-
in manufacturer-provided trust anchors to domain-specific trust
anchors is mediated by the signed voucher artifact.
If the manufacturer's IDevID signing key is not properly validated,
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
manufacturer's MASA is provided in the IDevID using the extension
from Section 2.3, the malicious pledge will have no problem
collaborating with it's MASA to produce a completely valid voucher.
BRSKI does not, however, fundamentally change the trust model from
domain owner to manufacturer. Assuming that the pledge used its
IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs
to trust the manufacturer.
Establishing this trust between domain and manufacturer is outside
the scope of BRSKI. There are a number of mechanisms that can
adopted including:
o Manually configuring each manufacturer's trust anchor.
o A Trust-On-First-Use (TOFU) mechanism. A human would be queried
upon seeing a manufacturer's trust anchor for the first time, and
then the trust anchor would be installed to the trusted store.
There are risks with this; even if the key to name is validated
using something like the WebPKI, there remains the possibility
that the name is a look alike: e.g, c1sco.com, ..
o scanning the trust anchor from a QR code that came with the
packaging (this is really a manual TOFU mechanism)
o some sales integration process where trust anchors are provided as
part of the sales process, probably included in a digital packing
"slip", or a sales invoice.
o consortium membership, where all manufacturers of a particular
device category (e.g, a light bulb, or a cable-modem) are signed
by an certificate authority specifically for this. This is done
by CableLabs today. It is used for authentication and
authorization as part of TR-79: [docsisroot] and [TR069].
The existing WebPKI provides a reasonable anchor between manufacturer
name and public key. It authenticates the key. It does not provide
a reasonable authorization for the manufacturer, so it is not
directly useable on it's own.
9. Acknowledgements 9. 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, Markus Stenberg, and Peter van Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg,
der Stok and Peter van der Stok
10. References 10. References
10.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.
skipping to change at page 54, line 5 skipping to change at page 57, line 40
[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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
Security: An Unauthenticated Mode of IPsec", RFC 5386, Security: An Unauthenticated Mode of IPsec", RFC 5386,
DOI 10.17487/RFC5386, November 2008, DOI 10.17487/RFC5386, November 2008,
<https://www.rfc-editor.org/info/rfc5386>. <https://www.rfc-editor.org/info/rfc5386>.
skipping to change at page 55, line 15 skipping to change at page 59, line 11
[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 10.2. Informative References
[docsisroot]
CableLabs, "CableLabs Digital Certificate Issuance
Service", February 2018,
<https://www.cablelabs.com/resources/
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 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
Reference Model for Autonomic Networking", draft-ietf- Reference Model for Autonomic Networking", draft-ietf-
anima-reference-model-05 (work in progress), October 2017. anima-reference-model-05 (work in progress), October 2017.
[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 NETCONF or RESTCONF based Management", Provisioning for Networking Devices", draft-ietf-netconf-
draft-ietf-netconf-zerotouch-19 (work in progress), zerotouch-20 (work in progress), February 2018.
October 2017.
[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-15 (work Description Specification", draft-ietf-opsawg-mud-18 (work
in progress), January 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.
[I-D.vanderstok-ace-coap-est] [I-D.vanderstok-ace-coap-est]
Stok, P., Kampanakis, P., Kumar, S., Richardson, M., Stok, P., Kampanakis, P., Kumar, S., Richardson, M.,
Furuhed, M., and S. Raza, "EST over secure CoAP (EST- Furuhed, M., and S. Raza, "EST over secure CoAP (EST-
coaps)", draft-vanderstok-ace-coap-est-04 (work in coaps)", draft-vanderstok-ace-coap-est-04 (work in
skipping to change at page 56, line 48 skipping to change at page 60, line 48
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[Stajano99theresurrecting] [Stajano99theresurrecting]
Stajano, F. and R. Anderson, "The resurrecting duckling: Stajano, F. and R. Anderson, "The resurrecting duckling:
security issues for ad-hoc wireless networks", 1999, security issues for ad-hoc wireless networks", 1999,
<https://www.cl.cam.ac.uk/~fms27/ <https://www.cl.cam.ac.uk/~fms27/
papers/1999-StajanoAnd-duckling.pdf>. papers/1999-StajanoAnd-duckling.pdf>.
[TR069] Broadband Forum, "TR-69: CPE WAN Management Protocol",
February 2018, <https://www.broadband-forum.org/
standards-and-software/technical-specifications/
tr-069-files-tools>.
Appendix A. IPv4 operations Appendix A. IPv4 operations
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 59, line 11 skipping to change at page 63, line 14
Each of these interfaces on the Join Proxy may be separate L3 routing Each of these interfaces on the Join Proxy may be separate L3 routing
domains, and therefore will have a unique set of link-local domains, and therefore will have a unique set of link-local
addresses. An IPIP packet being returned by the Registrar needs to addresses. An IPIP packet being returned by the Registrar needs to
be forwarded to the correct interface, so the Join Proxy needs an be forwarded to the correct interface, so the Join Proxy needs an
additional key to distinguish which network the packet should be additional key to distinguish which network the packet should be
returned to. returned to.
The simplest way to get this additional key is to allocate an The simplest way to get this additional key is to allocate an
additional ACP address; one address for each network on which join additional ACP address; one address for each network on which join
traffic is occuring. The Join Proxy SHOULD do a GRASP M_NEG_SYN for traffic is occuring.
each interface for which they wish to relay traffic, as this allows
the Registrar to do any static tunnel configuration that may be
required.
C.2. Automatic configuration of tunnels on Registrar C.2. Automatic configuration of tunnels on Registrar
The Join Proxy is expected to do a GRASP negotiation with the Proxy The Join Proxy is expected to do a GRASP negotiation with the Proxy
for each Join Interface that it needs to relay traffic from. This is for each Join Interface that it needs to relay traffic from. This is
to permit Registrars to configure the appropriate virtual interfaces to permit Registrars to configure the appropriate virtual interfaces
before join traffic arrives. before join traffic arrives.
A Registrar serving a large number of interfaces may not wish to A Registrar serving a large number of interfaces may not wish to
allocate resources to every interface at all times, but can instead allocate resources to every interface at all times, but can instead
skipping to change at page 64, line 12 skipping to change at page 68, 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 65, line 45 skipping to change at page 69, 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. 74 change blocks. 
249 lines changed or deleted 449 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/