draft-ietf-6tisch-dtsecurity-zerotouch-join-01.txt   draft-ietf-6tisch-dtsecurity-zerotouch-join-02.txt 
6tisch Working Group M. Richardson 6tisch Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Informational B. Damm Intended status: Informational B. Damm
Expires: May 3, 2018 Silver Spring Networks Expires: November 1, 2018 Silver Spring Networks
October 30, 2017 April 30, 2018
6tisch Zero-Touch Secure Join protocol 6tisch Zero-Touch Secure Join protocol
draft-ietf-6tisch-dtsecurity-zerotouch-join-01 draft-ietf-6tisch-dtsecurity-zerotouch-join-02
Abstract Abstract
This document describes a zero-touch mechanism to enroll a new device This document describes a Zero-touch Secure Join (ZSJ) mechanism to
(the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network
signaling mechanisms. The resulting device will obtain a domain using the 6tisch signaling mechanisms. The resulting device will
specific credential that can be used with either 802.15.9 per-host obtain a domain specific credential that can be used with either
pair keying protocols, or to obtain the network-wide key from a 802.15.9 per-host pair keying protocols, or to obtain the network-
coordinator. The mechanism describe her is an augmentation to the wide key from a coordinator. The mechanism describe here is an
one-touch mechanism described in [I-D.ietf-6tisch-minimal-security]. augmentation to the one-touch mechanism described in
[I-D.ietf-6tisch-minimal-security], and a constrained version of
[I-D.ietf-anima-bootstrapping-keyinfra].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018. This Internet-Draft will expire on November 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6
1.2. Scope of solution . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Leveraging the new key infrastructure / next steps . . . 6 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 7
1.3.1. Key Distribution Process . . . . . . . . . . . . . . 7 1.3.1. Support environment . . . . . . . . . . . . . . . . . 8
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 7 1.3.2. Constrained environments . . . . . . . . . . . . . . 8
2.1. Behaviour of a Pledge . . . . . . . . . . . . . . . . . . 7 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 8
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 9 1.4. Leveraging the new key infrastructure / next steps . . . 8
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 9 1.4.1. Key Distribution Process . . . . . . . . . . . . . . 8
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 10 1.5. Requirements for Autonomic Network Infrastructure (ANI)
2.4.1. Architectural component: Pledge . . . . . . . . . . . 11 devices . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.2. Architectural component: Stateless IPIP Proxy . . . . 12 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
2.4.3. Architectural component: Domain Registrar . . . . . . 12 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 9
2.4.4. Architectural component: Vendor Service . . . . . . . 12 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 10
2.5. Lack of realtime clock . . . . . . . . . . . . . . . . . 12 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 10
2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 13 2.3.1. Identification of the Pledge . . . . . . . . . . . . 11
2.7. Determining the MASA to contact . . . . . . . . . . . . . 13 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 11
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 13 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Architectural Components . . . . . . . . . . . . . . . . 13
3.2. SID values . . . . . . . . . . . . . . . . . . . . . . . 13 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.2. Stateless IPIP Join Proxy . . . . . . . . . . . . . . 13
4. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 13
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 16 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 14
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 16 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 14
4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 16 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 14
4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 16 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 14
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 16 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 14
5.1. BRSKI-EST (D)TLS establishment details . . . . . . . . . 17 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. BRSKI-EST CoAP/DTLS estasblishment details . . . . . 17 2.8. Determining the MASA to contact . . . . . . . . . . . . . 14
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 15
4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 15
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 15
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 15
4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 15
4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 15
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 16
5.1. BRSKI-EST (D)TLS establishment details . . . . . . . . . 16
5.1.1. BRSKI-EST CoAP/DTLS estasblishment details . . . . . 16
5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details . . . . . 17 5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details . . . . . 17
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 18 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 18
5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 18 5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 18
5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 18 5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 19
5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 18 5.4.1. MASA renewal of expired vouchers . . . . . . . . . . 19
5.5.1. Completing authentication of Provisional TLS 5.4.2. MASA verification of voucher-request signature
connection . . . . . . . . . . . . . . . . . . . . . 18 consistency . . . . . . . . . . . . . . . . . . . . . 19
5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 18 5.4.3. MASA authentication of registrar (certificate) . . . 19
5.7. MASA authorization log Request . . . . . . . . . . . . . 19 5.4.4. MASA revocation checking of registrar (certificate) . 20
5.7.1. MASA authorization log Response . . . . . . . . . . . 19 5.4.5. MASA verification of pledge prior-signed-voucher-
5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 19 request . . . . . . . . . . . . . . . . . . . . . . . 20
5.8.1. EST Distribution of CA Certificates . . . . . . . . . 19 5.4.6. MASA pinning of registrar . . . . . . . . . . . . . . 20
5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 19 5.4.7. MASA nonce handling . . . . . . . . . . . . . . . . . 20
5.8.3. EST Client Certificate Request . . . . . . . . . . . 19 5.5. MASA Voucher Response . . . . . . . . . . . . . . . . . . 20
5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 19 5.5.1. Pledge voucher verification . . . . . . . . . . . . . 21
5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 19 5.5.2. Pledge authentication of provisional TLS connection . 21
6. Reduced security operational modes . . . . . . . . . . . . . 19 5.6. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 21
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 19 5.7. Registrar audit log request . . . . . . . . . . . . . . . 21
6.2. Pledge security reductions . . . . . . . . . . . . . . . 19 5.7.1. MASA audit log response . . . . . . . . . . . . . . . 21
6.3. Registrar security reductions . . . . . . . . . . . . . . 20 5.7.2. Registrar audit log verification . . . . . . . . . . 21
6.4. MASA security reductions . . . . . . . . . . . . . . . . 20 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 21
7.1. MIME-Type Registry . . . . . . . . . . . . . . . . . . . 20 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5.8.3. EST Client Certificate Request . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 22
9.1. Security of MASA voucher signing key(s) . . . . . . . . . 20 5.8.5. Multiple certificates . . . . . . . . . . . . . . . . 22
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 5.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 22
10.1. Privacy Considerations for Production network . . . . . 20 5.9. Use of Secure Transport for Minimal Join . . . . . . . . 22
10.2. Privacy Considerations for New Pledges . . . . . . . . . 20 6. Reduced security operational modes . . . . . . . . . . . . . 22
10.2.1. EUI-64 derived address for join time IID . . . . . . 21 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 23
10.3. Privacy Considerations for Join Proxy . . . . . . . . . 22 6.2. Pledge security reductions . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 6.3. Registrar security reductions . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.4. MASA security reductions . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 25 7.1. Well-known EST registration . . . . . . . . . . . . . . . 23
Appendix A. Extra text . . . . . . . . . . . . . . . . . . . . . 27 7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 23
A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 27 7.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 23
A.1.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 27 7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 23
A.1.2. Factory provided credentials (if any) . . . . . . . . 27 7.5. MUD File Extension for the MASA server . . . . . . . . . 23
A.1.3. Credentials to be introduced . . . . . . . . . . . . 27 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
A.2. Network Assumptions . . . . . . . . . . . . . . . . . . . 28 8.1. Privacy Considerations for Production network . . . . . . 24
A.2.1. Security above and below IP . . . . . . . . . . . . . 28 8.2. Privacy Considerations for New Pledges . . . . . . . . . 24
A.2.2. Join network assumptions . . . . . . . . . . . . . . 29 8.2.1. EUI-64 derived address for join time IID . . . . . . 25
A.2.3. Number and cost of round trips . . . . . . . . . . . 29 8.3. Privacy Considerations for Join Proxy . . . . . . . . . . 25
A.2.4. Size of packets, number of fragments . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
A.3. Target end-state for join process . . . . . . . . . . . . 29 9.1. Security of MASA voucher signing key(s) . . . . . . . . . 25
Appendix B. Join Protocol . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
B.1. Key Agreement process . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.2. Provisional Enrollment process . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
Appendix C. IANA Considerations . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix D. Protocol Definition . . . . . . . . . . . . . . . . 32
D.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Extra text . . . . . . . . . . . . . . . . . . . . . 31
D.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 33 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 31
D.1.2. Registrar Discovery Protocol Details . . . . . . . . 33 A.1.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 A.1.2. Factory provided credentials (if any) . . . . . . . . 31
A.1.3. Credentials to be introduced . . . . . . . . . . . . 31
A.2. Network Assumptions . . . . . . . . . . . . . . . . . . . 32
A.2.1. Security above and below IP . . . . . . . . . . . . . 32
A.2.2. Join network assumptions . . . . . . . . . . . . . . 33
A.2.3. Number and cost of round trips . . . . . . . . . . . 33
A.2.4. Size of packets, number of fragments . . . . . . . . 33
A.3. Target end-state for join process . . . . . . . . . . . . 33
Appendix B. Join Protocol . . . . . . . . . . . . . . . . . . . 34
B.1. Key Agreement process . . . . . . . . . . . . . . . . . . 34
B.2. Provisional Enrollment process . . . . . . . . . . . . . 35
Appendix C. IANA Considerations . . . . . . . . . . . . . . . . 36
Appendix D. Protocol Definition . . . . . . . . . . . . . . . . 36
D.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 36
D.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 37
D.1.2. Registrar Discovery Protocol Details . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
Enrollment of new nodes into LLNs present unique challenges. The Enrollment of new nodes into LLNs present unique challenges. The
constrained nodes has no user interfaces, and even if they did, constrained nodes has no user interfaces, and even if they did,
configuring thousands of such nodes manually is undesireable from a configuring thousands of such nodes manually is undesireable from a
human resources issue, as well as the difficulty in getting human resources issue, as well as the difficulty in getting
consistent results. consistent results.
This document is about a standard way to introduce new nodes into a This document is about a standard way to introduce new nodes into a
skipping to change at page 4, line 19 skipping to change at page 4, line 46
nodes themselves. This act has been called "zero-touch" nodes themselves. This act has been called "zero-touch"
provisioning, and it does not occur by chance, but requires provisioning, and it does not occur by chance, but requires
coordination between the manufacturer of the node, the service coordination between the manufacturer of the node, the service
operator running the LLN, and the installers actually taking the operator running the LLN, and the installers actually taking the
devices out of the shipping boxes. devices out of the shipping boxes.
This document is a constrained profile of This document is a constrained profile of
[I-D.ietf-anima-bootstrapping-keyinfra]. The above document/protocol [I-D.ietf-anima-bootstrapping-keyinfra]. The above document/protocol
is referred by by it's acronym: BRSKI. The pronounciation of which is referred by by it's acronym: BRSKI. The pronounciation of which
is "brew-ski", a common north american slang for beer with a pseudo- is "brew-ski", a common north american slang for beer with a pseudo-
polish ending. polish ending. This constrained protocol is called ZSJ.
This document follows the same structure as it's parent in order to This document follows the same structure as it's parent in order to
emphasize the similarities, but specializes a number of things to emphasize the similarities, but specializes a number of things to
constrained networks of constrained devices. Like ANIMA's BRSKI, the constrained networks of constrained devices. Like
networks which are in scope for this protocol are deployed by a [I-D.ietf-anima-bootstrapping-keyinfra], the networks which are in
professional operator. The deterministic mechanisms which have been scope for this protocol are deployed by a professional operator. The
designed into 6tisch have been created to satisfy the operational deterministic mechanisms which have been designed into 6tisch have
needs of industrial settings. been created to satisfy the operational needs of industrial settings
where such an operator exists.
This document builds upon the "one-touch" provisioning described in This document builds upon the "one-touch" provisioning described in
[I-D.ietf-6tisch-minimal-security], reusing the OSCOAP Join Request [I-D.ietf-6tisch-minimal-security], reusing the OSCOAP Join Request
mechanism when appropriate. In addition, it uses the CoAP adaption mechanism when appropriate, but preceeding it with either the EDHOC
of EST defined in [I-D.vanderstok-ace-coap-est] in an identical way. key agreement protocol, or a DTLS channel. The [RFC7030] EST
protocol extended in [I-D.ietf-6tisch-minimal-security], has been
mapped by [I-D.ietf-ace-coap-est] into CoAP.
Otherwise, this document follows BRSKI with the following high-level Otherwise, this document follows BRSKI with the following high-level
changes: changes:
o HTTP is replaced with CoAP. o HTTP is replaced with CoAP.
o TLS (HTTPS) is replaced with either DTLS+CoAP, or EDHOC/ o TLS (HTTPS) is replaced with either DTLS+CoAP, or EDHOC/
OSCOAP+CoAP OSCOAP+CoAP
o the domain-registrar anchor certificate is replaced with a Raw o the domain-registrar anchor certificate is replaced with a Raw
skipping to change at page 5, line 9 skipping to change at page 5, line 36
o the PKCS7 signed JSON voucher format is replaced with CWT o the PKCS7 signed JSON voucher format is replaced with CWT
o the GRASP discovery mechanism for the Proxy is replaced with an o the GRASP discovery mechanism for the Proxy is replaced with an
announcement in the Enhanced Beacon announcement in the Enhanced Beacon
[I-D.richardson-6tisch-join-enhanced-beacon] [I-D.richardson-6tisch-join-enhanced-beacon]
o the TCP circuit proxy mechanism is not used. The IPIP mechanism o the TCP circuit proxy mechanism is not used. The IPIP mechanism
if mandatory to implement when deployed with DTLS, while the CoAP if mandatory to implement when deployed with DTLS, while the CoAP
based stateless proxy mechanism is used for OSCOAP/EDHOC. based stateless proxy mechanism is used for OSCOAP/EDHOC.
o real time clocks are assumed to be impossible, so expiry dates in o real time clocks are assumed to be unavailable, so expiry dates in
ownership vouchers are never used ownership vouchers are never used
o nonce-full vouchers are encouraged, but off-line nonce-less o nonce-full vouchers are encouraged, but off-line nonce-less
operation is also supported operation is also supported, however, the resulting vouchers have
infinite life.
802.1AR Client certificates are retained, but optionally are 802.1AR Client certificates are retained, but optionally are
specified by reference rather than value. specified by reference rather than value.
It is expected that the back-end network operator infrastructure It is expected that the back-end network operator infrastructure
would be able to bootstrap ANIMA BRSKI-type devices over ethernet, would be able to bootstrap ANIMA BRSKI-type devices over ethernet,
while also being able bootstrap 6tisch devices over 802.15.4 with few while also being able bootstrap 6tisch devices over 802.15.4 with few
changes. changes.
1.1. Terminology NOTE TO RFC-EDITOR: during production of this document, it was
matched against [I-D.ietf-anima-bootstrapping-keyinfra] section by
section. This results in a few sections, such as IANA Considerations
where there is no requested activity. Those sections are marked "NO
ACTION, PLEASE REMOVE" and should be removed (along with this
paragraph) from the final document.
1.1. Prior Bootstrapping Approaches
Constrained devices as used in industrial control systems are usually
installed (or replaced) by technicians with expertise in the
equipment being serviced, not in secure enrollment of devices.
Devices therefore are typically pre-configured in advance, marked for
a particular factory, assembly line, or even down to the specific
machine. It is not uncommon for manufacturers to have a product code
(stock keeping unit -SKU) for each part, and for each customer as the
part will be loaded with customer specifc security configuration.
The resulting customer-specific parts are hard to inventory and
spare, and should parts be delivered to the wrong customer,
determining the reason for inability to configure is difficult and
time consuming.
End-user actions to configure the part at the time of installation,
aside from being error prone, also suffer from requiring a part that
has an interface.
1.2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant STuPiD [RFC2119] and indicate requirement levels for compliant STuPiD
implementations. implementations.
The reader is expected to be familiar with the terms and concepts The reader is expected to be familiar with the terms and concepts
defined in [I-D.ietf-6tisch-terminology], [RFC7252], defined in [I-D.ietf-6tisch-terminology], [RFC7252],
[I-D.ietf-core-object-security], and [I-D.ietf-core-object-security], and
skipping to change at page 6, line 19 skipping to change at page 7, line 28
to proceed. to proceed.
Ownership Voucher A signed voucher from the vendor vouching that a Ownership Voucher A signed voucher from the vendor vouching that a
specific domain "owns" the new entity as defined in specific domain "owns" the new entity as defined in
[I-D.ietf-anima-voucher]. [I-D.ietf-anima-voucher].
MIC manufacturer installed certificate. An [ieee802-1AR] identity. MIC manufacturer installed certificate. An [ieee802-1AR] identity.
Not to be confused with a (cryptographic) "Message Integrity Not to be confused with a (cryptographic) "Message Integrity
Check" Check"
1.2. Scope of solution 1.3. Scope of solution
The solution described in this document is appropriate to enrolling The solution described in this document is appropriate to enrolling
between hundreds to hundreds of thousands of diverse devices into a between hundreds to hundreds of thousands of diverse devices into a
network without any prior contact with the devices. The devices network without any prior contact with the devices. The devices
could be shipped by the manufacturer directly to the customer site could be shipped by the manufacturer directly to the customer site
without ever being seen by the operator of the network. As described without ever being seen by the operator of the network. As described
in BRSKI, in the audit-mode of operation the device will be claimed in BRSKI, in the audit-mode of operation the device will be claimed
by the first network that sees it. In the tracked owner mode of by the first network that sees it. In the tracked owner mode of
operation, sales channel integration provides a strong connection operation, sales channel integration provides a strong connection
that the operator of the network is the legitimate owner of the that the operator of the network is the legitimate owner of the
device. device.
BRSKI describes a more general, more flexible approach for BRSKI describes a more general, more flexible approach for
bootstrapping devices into an ISP or Enterprise network. bootstrapping devices into an ISP or Enterprise network.
[I-D.ietf-6tisch-minimal-security] provides an extremely streamlined [I-D.ietf-6tisch-minimal-security] provides an extremely streamlined
approach to enrolling from hundreds to thousands of devices into a approach to enrolling from hundreds to thousands of devices into a
network, provided that a unique secret key can be installed in each network, provided that a unique secret key can be installed in each
device. device.
1.3. Leveraging the new key infrastructure / next steps 1.3.1. Support environment
TBD
1.3.2. Constrained environments
TBD
1.3.3. Network Access Controls
TBD
1.4. Leveraging the new key infrastructure / next steps
In constrained networks, it is unlikely that an ACP be formed. This In constrained networks, it is unlikely that an ACP be formed. This
document does not preclude such a thing, but it is not mandated. document does not preclude such a thing, but it is not mandated.
The resulting secure channel MAY be used just to distribute network- The resulting secure channel MAY be used just to distribute network-
wide keys using a protocol such as wide keys using a protocol such as
[I-D.ietf-6tisch-minimal-security]. (XXX - do we need to signal this [I-D.ietf-6tisch-minimal-security]. (XXX - do we need to signal this
somehow?) somehow?)
The resulting secure channel MAY be instead used to do an enrollment The resulting secure channel MAY be instead used to do an enrollment
of an LDevID as in BRSKI, but the resulting certificate is used to do of an LDevID as in BRSKI, but the resulting certificate is used to do
per-pair keying such as described by {{ieee802159}. per-pair keying such as described by {{ieee802159}.
1.3.1. Key Distribution Process 1.4.1. Key Distribution Process
In addition to being used for the initial enrollment process, the In addition to being used for the initial enrollment process, the
secure channel may be kept open (and reversed) to use for network secure channel may be kept open (and reversed) to use for network
rekeying. Such a process is out of scope of this document, please rekeying. Such a process is out of scope of this document, please
see future work such as [I-D.richardson-6tisch-minimal-rekey]. see future work such as [I-D.richardson-6tisch-minimal-rekey].
1.5. Requirements for Autonomic Network Infrastructure (ANI) devices
TBD
2. Architectural Overview 2. Architectural Overview
Section 2 of BRSKI has a diagram with all of the components shown Section 2 of BRSKI has a diagram with all of the components shown
together. There are no significant changes to the diagram. together. There are no significant changes to the diagram.
The use of a circuit proxy is not mandated. Instead the IPIP The use of a circuit proxy is not mandated. Instead the IPIP
mechanism described in appendix C ("IPIP Join Proxy mechanism") mechanism described in appendix C ("IPIP Join Proxy mechanism")
SHOULD be be used instead as it supports both DTLS, EDHOC and OSCOAP SHOULD be be used instead as it supports both DTLS, EDHOC and OSCOAP
protocols. protocols.
The CoAP proxy mechanism MAY be implemented instead: the decision The CoAP proxy mechanism MAY be implemented instead: the decision
depends upon the capabilities of the Registrar and the proxy. A depends upon the capabilities of the Registrar and the proxy. A
mechanism is included for the Registrar to announce it's capabilities mechanism is included for the Registrar to announce it's capabilities
(XXX) (XXX)
2.1. Behaviour of a Pledge 2.1. Behavior of a Pledge
The pledge goes through a series of steps which are outlined here at The pledge goes through a series of steps which are outlined here at
a high level. a high level.
+--------------+ +--------------+
| Factory | | Factory |
| default | | default |
+------+-------+ +------+-------+
| |
+------v-------+ +------v-------+
| Discover | | (1) Discover |
+------------> | +------------> |
| +------+-------+ | +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | Identity | | | (2) Identity |
^------------+ | ^------------+ |
| rejected +------+-------+ | rejected +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | Request | | | (3) Request |
| | Join | | | Join |
| +------+-------+ | +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | Imprint | Optional | | (4) Imprint |
^------------+ <--+Manual input (Appendix C) ^------------+ |
| Bad Vendor +------+-------+ | Bad MASA +------+-------+
| response | send Voucher Status Telemetry | response | send Voucher Status Telemetry
| +------v-------+ | +------v-------+
| | Enroll | | | (5) Enroll |
^------------+ | ^------------+ |
| Enroll +------+-------+ | Enroll +------+-------+
| Failure | | Failure |
| +------v-------+ | +------v-------+
| | Enrolled | | | (6) Enrolled |
^------------+ | ^------------+ |
Factory +--------------+ Factory +--------------+
reset reset
State descriptions for the pledge are as follows: State descriptions for the pledge are as follows:
1. Discover a communication channel to a Registrar. This is done by 1. Discover a communication channel to a Registrar. This is done by
listening for beacons as described by listening for beacons as described by
[I-D.richardson-anima-6join-discovery] [I-D.richardson-anima-6join-discovery]
2. Identify itself. This is done by presenting an X.509 IDevID 2. Identify itself. This is done by presenting an X.509 IDevID
credential to the discovered Registrar (via the Proxy) in a DTLS credential to the discovered Registrar (via the Proxy) in a DTLS
or EDHOC handshake. (The Registrar credentials are only or EDHOC handshake. (The Registrar credentials are only
skipping to change at page 10, line 32 skipping to change at page 11, line 42
but leaves the exact origin of the voucher serial-number open. This but leaves the exact origin of the voucher serial-number open. This
document restricts the process to being the hwSerialNum OCTET STRING. document restricts the process to being the hwSerialNum OCTET STRING.
As CWT can handle binary formats, no base64 encoding is necessary. As CWT can handle binary formats, no base64 encoding is necessary.
The use of the MASA-URL extension is encouraged if the certificate is The use of the MASA-URL extension is encouraged if the certificate is
sent at all. sent at all.
EDNOTE: here belongs text about sending only a reference to the EDNOTE: here belongs text about sending only a reference to the
IDevID rather than the entire certificate IDevID rather than the entire certificate
2.3.1. Identification of the Pledge
TBD
2.3.2. MASA URI extension
TBD
2.4. Protocol Flow 2.4. Protocol Flow
The diagram from BRSKI is reproduced with some edits: The diagram from BRSKI is reproduced with some edits:
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| Pledge | | IPIP | | Domain | | Vendor | | Pledge | | IPIP | | Domain | | Vendor |
| | | Proxy | | Registrar | | Service | | | | Proxy | | Registrar | | Service |
| | | | | | | (Internet | | | | | | (JRC) | | (MASA) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| | | | | | | |
|<-RFC4862 IPv6 adr | | | |<-RFC4862 IPv6 adr | | |
| | | | | | | |
|<--------------------| | | |<--------------------| | |
| Enhanced Beacon | | | | Enhanced Beacon | | |
| periodic broadcast| | | | periodic broadcast| | |
| | | | | | | |
|<------------------->C<----------------->| | |<------------------->C<----------------->| |
| DTLS via the IPIP Proxy | | | DTLS via the IPIP Proxy | |
skipping to change at page 11, line 36 skipping to change at page 13, line 9
P | | | P | | |
P<------voucher---------------------------| | P<------voucher---------------------------| |
[verify voucher ] | | | [verify voucher ] | | |
[verify provisional cert| | | [verify provisional cert| | |
| | | | | | | |
|<--------------------------------------->| | |<--------------------------------------->| |
| Continue with RFC7030 enrollment | | | Continue with RFC7030 enrollment | |
| using now bidirectionally authenticated | | | using now bidirectionally authenticated | |
| DTLS session. | | | | DTLS session. | | |
| | | | | | | |
| | | | |<--------------------------------------->| |
| | | | | Use 6tisch-minimal-security join request |
Noteable changes are: Noteable changes are:
1. no IPv4 support/options. 1. no IPv4 support/options.
2. no mDNS steps, 6tisch only uses Enhanced Beacon 2. no mDNS steps, 6tisch only uses Enhanced Beacon
3. nonce-full option is always recommended 3. nonce-full option is always mandatory
2.4.1. Architectural component: Pledge 2.5. Architectural Components
The bootstrap process includes the following architectural
components:
2.5.1. Pledge
The Pledge is the device which is attempting to join. Until the The Pledge is the device which is attempting to join. Until the
pledge completes the enrollment process, it has network connectivity pledge completes the enrollment process, it has network connectivity
only to the Proxy. only to the Proxy.
2.4.2. Architectural component: Stateless IPIP Proxy 2.5.2. Stateless IPIP Join Proxy
The stateless CoAP or DTLS Proxy provides CoAP or DTLS connectivity The stateless CoAP or DTLS Proxy provides CoAP or DTLS connectivity
(respectively) between the pledge and the registrar. The stateless (respectively) between the pledge and the registrar. The stateless
CoAP proxy mechanism is described in CoAP proxy mechanism is described in
[I-D.ietf-6tisch-minimal-security] section 5.1. The stateless DTLS [I-D.ietf-6tisch-minimal-security] section 5.1.
mechanism is not yet described (XXX).
2.4.3. Architectural component: Domain Registrar The stateless DTLS mechanism is not yet described (TBD).
2.5.3. 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, terminating the EST
and BRSKI connections. The Registrar is manually configured or 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 Vendor supplied MASA to establish ownership. communicates with the Vendor supplied MASA to establish ownership.
The JRC is typically located on the 6LBR/DODAG root, but it may be The JRC is typically located on the 6LBR/DODAG root, but it may be
located elsewhere, provided IP level connectivity can be established. located elsewhere, provided IP level connectivity can be established.
The 6LBR may also provide a proxy or relay function to connect to the The 6LBR may also provide a proxy or relay function to connect to the
actual registrar in addition to the IPIP proxy described above. The actual registrar in addition to the IPIP proxy described above. The
existence of such an additional proxy is a private matter, and this existence of such an additional proxy is a private matter, and this
documents assumes without loss of generality that the registrar is documents assumes without loss of generality that the registrar is
co-located with the 6LBR. co-located with the 6LBR.
2.4.4. Architectural component: Vendor Service 2.5.4. Manufacturer Service
The Vendor Service provides two logically seperate functions: the The Manufacturer Service provides two logically seperate functions:
Manufacturer Authorized Signing Authority (MASA), and an ownership the Manufacturer Authorized Signing Authority (MASA), and an
tracking/auditing function. This function is identical to that used ownership tracking/auditing function. This function is identical to
by BRSKI, except that a different format voucher is used. that used by BRSKI, except that a different format voucher is used.
2.5. Lack of realtime clock 2.5.5. Public Key Infrastructure (PKI)
TBD
2.6. Certificate Time Validation
2.6.1. Lack of realtime clock
For the constrained situation it is assumed that devices have no real For the constrained situation it is assumed that devices have no real
time clock. These nodes do have access to a monotonically increasing time clock. These nodes do have access to a monotonically increasing
clock that will not go backwards in the form of the Absolute Sequence clock that will not go backwards in the form of the Absolute Sequence
Number. Synchronization to the ASN is required in order to transmit/ Number. Synchronization to the ASN is required in order to transmit/
receive data and most nodes will maintain it in hardware. receive data and most nodes will maintain it in hardware.
The heuristic described in BRSKI under this section SHOULD be applied The heuristic described in BRSKI under this section SHOULD be applied
if there are dates in the CWT format voucher. if there are dates in the CWT format voucher.
Voucher requests SHOULD include a nonce. For devices intended for Voucher requests SHOULD include a nonce. For devices intended for
off-line deployment, the vouchers will have been generated in advance off-line deployment, the vouchers will have been generated in advance
and no nonce-ful operation will not be possible. and no nonce-ful operation will not be possible.
2.6. Cloud Registrar 2.6.2. Infinite Lifetime of IDevID
TBD
2.7. Cloud Registrar
In 6tisch, the pledge never has network connectivity until it is In 6tisch, the pledge never has network connectivity until it is
enrolled, so no alternate registrar is ever possible. enrolled, so no alternate registrar is ever possible.
2.7. Determining the MASA to contact 2.8. Determining the MASA to contact
There are no changes from BRSKI: the IDevID provided by the pledge There are no changes from BRSKI: the IDevID provided by the pledge
will contain a MASA URL extension. will contain a MASA URL extension.
3. Voucher-Request artifact 3. Voucher-Request artifact
As in BRSKI, a voucher-request artifact is derived from the base The voucher-request artifact is defined in
voucher definition. The constrained version differs from the non- [I-D.richardson-anima-ace-constrained-voucher] section 6.1.
constrained version in two ways:
1. it does not include the pinned-domain-cert, but rather than
pinned-domain-subjet-public-key-info entry. This accomodates the
use of a raw public key to identify the registrar.
2. the pledge voucher-request is never signed.
An appendix shows detailed examples of CWT format voucher requests.
3.1. Tree Diagram
module: ietf-cwt-voucher-request
groupings:
voucher-request-cwt-grouping
+---- voucher
+---- created-on yang:date-and-time
+---- expires-on? yang:date-and-time
+---- assertion enumeration
+---- serial-number string
+---- idevid-issuer? binary
+---- pinned-domain-cert binary
+---- domain-cert-revocation-checks? boolean
+---- nonce? binary
+---- last-renewal-date? yang:date-and-time
+---- proximity-registrar-subject-public-key-info? binary
3.2. SID values
SID experimental base 60100 is used for voucher-requests.
dictionary keys are:
60100 ietf-cwt-voucher
60101 assertion
60102 created-on
60103 domain-cert-revocation-checks
60104 expires-on
60105 idevid-issuer
60106 last-renewal-date
60107 nonce
60108 pinned-domain-cert
60109 pinned-domain-subject-public-key-info
60110 prior-signed-voucher
60111 serial-number
60112 proximity-registrar-cert
60113 proximity-registrar-subject-public-key-info
60100 ietf-cwt-voucher-request
3.3. YANG Module
/* -*- c -*- */
module ietf-cwt-voucher-request {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-cwt-voucher-request";
prefix "vcwt";
import ietf-restconf {
prefix rc;
description
"This import statement is only present to access
the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol";
}
import ietf-voucher {
prefix "v";
}
organization
"IETF 6tisch Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/6tisch/>
WG List: <mailto:6tisch@ietf.org>
Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>";
description
"This module defines the format for a voucher, which is produced by
a pledge's manufacturer or delegate (MASA) to securely assign one
or more pledges to an 'owner', so that the pledges may establish a
secure connection to the owner's network infrastructure.
This version provides a very restricted subset appropriate
for very constrained devices.
In particular, it assumes that nonce-ful operation is
always required, that expiration dates are rather weak, as no
clocks can be assumed, and that the Registrar is identified
by a pinned Raw Public Key.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in
the module text are to be interpreted as described in RFC 2119.";
revision "YYYY-MM-DD" {
description
"Initial version";
reference
"RFC XXXX: Voucher Profile for Constrained Devices";
}
// Grouping defined for future usage
grouping voucher-request-cwt-grouping {
description
"Grouping to allow reuse/extensions in future work.";
uses v:voucher-artifact-grouping {
augment "voucher" {
description "Base the CWT voucher-request upon the regular one";
leaf proximity-registrar-subject-public-key-info {
type binary;
description
"The proximity-registrar-subject-public-key-info replaces the
proximit-registrar-cert in constrained uses of
the voucher-request.
The proximity-registrar-subject-public-key-info is the
Raw Public Key of the Registrar. This field is encoded
as specified in RFC7250, section 3.
The ECDSA algorithm MUST be supported.
The EdDSA algorithm as specified in
draft-ietf-tls-rfc4492bis-17 SHOULD be supported.
Support for the DSA algorithm is not recommended.
Support for the RSA algorithm is a MAY.";
}
}
}
}
}
This definition, translated via the rules in For the 6tisch ZSJ protocol defined in this document, only COSE
[I-D.ietf-core-yang-cbor] uses the signed vouchers as described in
[I-D.richardson-anima-ace-constrained-voucher] section 6.3.2 are
supported.
4. Proxy details 4. Proxying details (Pledge - Proxy - Registrar)
The role of the Proxy is to facilitate communication. In the The role of the Proxy is to facilitate communication. In the
constrained situation the proxy needs to be stateless. constrained situation the proxy needs to be stateless as there is
very little ram to begin with, and none can be allocated to keep
state for an unlimited number of potential pledges.
4.1. Pledge discovery of Proxy 4.1. Pledge discovery of Proxy
In BRSKI, the pledge discovers the proxy via use of a GRASP M_FLOOD In BRSKI, the pledge discovers the proxy via use of a GRASP M_FLOOD
messages sent by the proxy. In 6tisch-zero-touch, the existence of messages sent by the proxy. In 6tisch ZSJ, the existence of the
the proxy is related by the Enhanced Beacon. proxy is announced by the Enhanced Beacon defined in
[I-D.richardson-6tisch-join-enhanced-beacon].
4.2. CoAP connection to Registrar 4.2. CoAP connection to Registrar
In BRSKI CoAP is future work. This document represents this work. In BRSKI CoAP is future work. This document represents this work.
4.3. HTTPS proxy connection to Registrar 4.3. HTTPS proxy connection to Registrar
HTTPS connections are not used. HTTPS connections are not used between the Pledge, Proxy and
Registrar. The Proxy relays CoAP or DTLS packets and does not
interpret or terminate either CoAP or DTLS connections. (HTTPS is
still used between the Registrar and MASA)
4.4. Proxy discovery of Registrar 4.4. Proxy discovery of Registrar
In BRSKI, the proxy autonomically discovers the Registrar by In BRSKI, the proxy autonomically discovers the Registrar by
listening for GRASP messages. In the constrained network, the listening for GRASP messages.
proxies are optionally configured with the address of the registrar
by the Join Response in [I-D.ietf-6tisch-minimal-security] section
XX. The address of the registrar otherwise defaults to be that of
the DODAG root.
5. Protocol Details In the constrained network, the proxies are optionally configured
with the address of the JRC by the Join Response in
[I-D.ietf-6tisch-minimal-security] section 8. As specified in that
section, if the address of the registrar otherwise defaults to be
that of the DODAG root.
Whether or not a 6LR will announce itself as a possible Join Proxy is
outside the scope of this document.
5. Protocol Details (Pledge - Registrar - MASA)
BRSKI is specified to run over HTTPS. This document respecifies it BRSKI is specified to run over HTTPS. This document respecifies it
to run over CoAP with either DTLS or EDHOC-provided OSCOAP security. to run over CoAP with either DTLS or EDHOC-provided OSCOAP security.
There is an emerging (hybrid) possibility of DTLS-providing the There is an emerging (hybrid) possibility of DTLS-providing the
OSCOAP security, but such a specification does not yet exist. OSCOAP security, but such a specification does not yet exist, and
this document does at this point specify it.
[I-D.vanderstok-ace-coap-est] specifies that CoAP specifies the use [I-D.ietf-ace-coap-est] specifies that CoAP specifies the use of CoAP
of CoAP Block-Wise Transfer ("Block") [RFC7959] to fragment EST Block-Wise Transfer ("Block") [RFC7959] to fragment EST messages at
messages at the application layer. the application layer.
BRSKI introduces the concept of a provisional state for EST. The BRSKI introduces the concept of a provisional state for EST. The
same situation must also be added to DTLS: a situation where the same situation must also be added to DTLS: a situation where the
connection is active but the identity of the Registar has not yet connection is active but the identity of the Registar has not yet
been confirmed. The DTLS MUST validate that the exchange has been been confirmed.
signed by the Raw Public Key that is presented by the Server, even
though there is as yet no trust in that key. Such a key is often
available through APIs that provide for channel binding, such as
described in [RFC5056].
As in [I-D.vanderstok-ace-coap-est], support for Observe CoAP options The DTLS MUST validate that the exchange has been signed by the Raw
Public Key that is presented by the Server, even though there is as
yet no trust in that key. Such a key is often available through APIs
that provide for channel binding, such as described in [RFC5056].
As in [I-D.ietf-ace-coap-est], support for Observe CoAP options
[RFC7641] with BRSKI is not supported in the current BRSKI/EST [RFC7641] with BRSKI is not supported in the current BRSKI/EST
message flows. Observe options could be used by the server to notify message flows.
clients about a change in the cacerts or csr attributes (resources)
and might be an area of future work. Observe options could be used by the server to notify clients about a
change in the cacerts or csr attributes (resources) and might be an
area of future work.
Redirection as described in [RFC7030] section 3.2.1 is NOT supported. Redirection as described in [RFC7030] section 3.2.1 is NOT supported.
5.1. BRSKI-EST (D)TLS establishment details 5.1. BRSKI-EST (D)TLS establishment details
Zerotouch Join does not use TLS. The connection is either CoAP over 6tisch ZSJ does not use TLS. The connection is either CoAP over
DTLS, or CoAP with EDHOC security. DTLS, or CoAP with EDHOC security.
5.1.1. BRSKI-EST CoAP/DTLS estasblishment details 5.1.1. BRSKI-EST CoAP/DTLS estasblishment details
The details in the BRSKI document apply directly to use of DTLS. The details in the BRSKI document apply directly to use of DTLS.
The registrar SHOULD authenticate itself with a raw public key. The registrar SHOULD authenticate itself with a raw public key. A
256 bit ECDSA raw public key is RECOMMENDED. Pledges SHOULD support
EDDSA keys if they contain hardware that supports doing so
efficiently.
TBD: the Pledge needs to signal what kind of Raw Public Key it
supports before the Registrar sends its ServerCertificate. Can SNI
be used to do this?
The pledge SHOULD authenticate itself with the built-in IDevID The pledge SHOULD authenticate itself with the built-in IDevID
certificate. certificate as a ClientCertificate.
5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details 5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details
[I-D.ietf-6tisch-minimal-security] section YYY details how to setup [I-D.selander-ace-cose-ecdhe] details how to use EDHOC. The EDHOC
EDHOC. description identifiers a party U (the initiator), and a party V.
The Pledge is the party U, and the JRC is the party V.
The communication from the Pledge is via CoAP via the Join Proxy.
The Join proxy relays traffic to the JRC, and using the mechanism
described in [I-D.ietf-6tisch-minimal-security] section 5.1. This is
designed so that the Join Proxy does not need to know if it is
performing the one-touch enrollment described in
[I-D.ietf-6tisch-minimal-security] or the zero-touch enrollment
protocol described in this document. A network could consist of a
mix of nodes of each type.
As generating ephemeral keys is expensive for a low-resource Pledge,
the use of a common E_U by the Pledge for multiple enrollment
attempts (should the first turn out to be the wrong network) is
encouraged.
The first communication detailed in [I-D.ietf-ace-coap-est] is to
query the "/.well-known/core" resource to request the Link for EST.
This is where the initial CoAP request is to sent.
The JRC MAY replace it's E_V ephermal key on a periodic basis, or
even for every communication session.
The Pledge's ID_U is the Pledge's IDevID. It is transmitted in an
x5bag [I-D.schaad-cose-x509]. An x5u (URL) MAY be used. An x5t
(hash) MAY also be used and would be the smallest, but the Registrar
may not know where to find the Pledge's IDevID unless the JRC has
been preloaded will all the IDevIDs via out-of-band mechanism. It is
impossible for the Pledge to know if the JRC has been loaded in such
a way so x5t is discouraged for general use.
The JRC's ID_V is the JRC's Raw Public Key. It is transmitted as a
key in COSE's YYY parameter.
The initial Mandatory to Implement (MTI) of an HKDF of SHA2-256, an
AEAD based upon AES-CCM-16-64-128, a signature verification of BBBB,
and signature generation of BBBB. The Pledge proposes a set of
algorithms that it supports, and Pledge need not support more than
one combination.
JRCs are expected to run on non-constrained servers, and are expected
to support the above initial MTI, and any subsequent ones that become
common. A JRC SHOULD support all available algorithms for a
significant amount of time. Even when algorithms become weak or
suspect, it is likely that it will still have to perform secure join
for older devices. A JRC that responds to such an older device might
not in the end accept the device into the network, but it is
important that it be able to audit the event and communicate the
event to an operator.
While EDHOC supports sending additional data in the message_3, in the
constrained network situation, it is anticipated that the size of the
this message will already be large, and no additional data is to be
sent.
A COAP confirmable message SHOULD be used.
[I-D.ietf-6tisch-minimal-security] section 6 details how to setup
OSCORE context given a shared key derived by EDHOC.
The registrar SHOULD authenticate itself with a raw public key. The registrar SHOULD authenticate itself with a raw public key.
The pledge SHOULD authenticate itself with the built-in IDevID The pledge SHOULD authenticate itself with the built-in IDevID
certificate. certificate.
5.2. Pledge Requests Voucher from the Registrar 5.2. Pledge Requests Voucher from the Registrar
The voucher request and response as defined by BRSKI is modified The voucher request and response as defined by BRSKI is modified
slightly. slightly.
skipping to change at page 18, line 28 skipping to change at page 19, line 8
document defines the voucher request to be unsigned. document defines the voucher request to be unsigned.
5.3. BRSKI-MASA TLS establishment details 5.3. BRSKI-MASA TLS establishment details
There are no changes. The connection from the Registrar to MASA is There are no changes. The connection from the Registrar to MASA is
still HTTPS. still HTTPS.
5.4. Registrar Requests Voucher from MASA 5.4. Registrar Requests Voucher from MASA
There are no change from BRSKI, as this step is between two non- There are no change from BRSKI, as this step is between two non-
constrained devices. The format of the voucher is CWT, which implies constrained devices.
changes to both the Registrar and the MASA, but semantically the
content is the same. The format of the voucher is COSE, which implies changes to both the
Registrar and the MASA, but semantically the content is the same.
The manufacturer will know what algorithms are supported by the The manufacturer will know what algorithms are supported by the
pledge, and will issue a 406 (Conflict) error to the Registrar if the pledge, and will issue a 406 (Conflict) error to the Registrar if the
Registar's public key format is not supported by the pledge. Registar's public key format is not supported by the pledge. It is
however, too late for the Registar to use a different key, but at
least it can log a reason for a failure. It is likely that the ZSJ-
BRSKI-EST connection has already failed, and this step is never
reached.
5.5. Voucher Response 5.4.1. MASA renewal of expired vouchers
The format of the voucher is CWT as described in section YYY. There are assumed to be no useful real-time clocks on constrained
devices, so all vouchers are in effect infinite duration. Pledges
will use nonces for freshness, and a request for a new voucher with a
new voucher for the same Registrar is not unusual. A token-bucket
system SHOULD be used such that no more than 24 vouchers are issued
per-day, but more than one voucher can be issued in a one hour
period. Tokens should not accumulate for more than one day!
5.5.1. Completing authentication of Provisional TLS connection 5.4.2. MASA verification of voucher-request signature consistency
The voucher-request is signed by the Registrar using it's Raw Public
Key. There is no additional certificate authority to sign this key.
The MASA MAY have this key via sales-channel integration, but in most
cases it will be seeing the key for the first time.
XXX-should the TLS connection from Registrar to MASA have a
ClientCertificate? If so, then should it use the same Public Key?
Or a different one?
5.4.3. MASA authentication of registrar (certificate)
IDEA: The MASA SHOULD pin the Raw Public Key (RPK) to the IP address
that was first used to make a request with it. Should the RPK <-> IP
address relationship be 1:1, 1:N, N:1? Should we take IP address to
mean, "IP subnet", essentially the IPv4/24, and IPv6/64? The value
of doing is about DDoS mitigation?
Should above mapping be on a per-Pledge basis?
5.4.4. MASA revocation checking of registrar (certificate)
As the Registrar has a Raw Public Key as an identity, there is no
meaningful standard revocation checking that can be done. The MASA
SHOULD have a blacklist table, and a way to add entries, but this
process is out of scope.
5.4.5. MASA verification of pledge prior-signed-voucher-request
The MASA will know whether or not the Pledge is capable of producing
a signed voucher-request for inclusion by the Registrar. In the case
where the Pledge can sign the voucher-request to the Registrar, then
the Registrar will have put it in the 'prior-signed-voucher-request'.
The MASA can verify the signature from the Pledge using the MASA's
copy of the Pledge's IDevID public key.
In many cases, the Pledge will not be capable of doing signatures in
real time, so no 'prior-signed-voucher-request' will be present. The
MASA will have rely on the audit log as a history function to
determine if the Pledge has previously been claimed, and to identify
situations where the claim from the Registrar is fraudulent.
5.4.6. MASA pinning of registrar
When the MASA creates a voucher, it puts the Registrar's Raw Public
Key into the 'pinned-domain-subject-public-key-info' leaf of the
voucher.
The MASA does not include the 'pinned-domain-cert' field.
5.4.7. MASA nonce handling
Use of nonces is highly RECOMMENDED, but there are situations where
not all components are connected at the same time in which the nonce
will not be present.
There are no significant changes from BRSKI.
5.5. MASA Voucher Response
The MASA responses with a voucher as specified in
[I-D.richardson-anima-ace-constrained-voucher] section 6.2.
This result is communicated back with a MIME Content-Type of
'application/voucher-cose+cbor'
5.5.1. Pledge voucher verification
The Pledge receives the voucher from the Registrar over it's CoAP
connection. It verifies the signature using the MASA anchor built
in, as in the BRSKI case.
5.5.2. Pledge authentication of provisional TLS connection
The BRSKI process uses the pinned-domain-cert field of the voucher to The BRSKI process uses the pinned-domain-cert field of the voucher to
validate the registrar's ServerCertificate. In the ZeroTouch case, validate the registrar's ServerCertificate. In the ZeroTouch case,
the voucher will contain a pinned-domain-subject-public-key-info the voucher will contain a pinned-domain-subject-public-key-info
field containing the raw public key of the certificate. It should field containing the raw public key of the certificate. It should
match, byte-to-byte with the raw public key ServerCertificate. match, byte-to-byte with the raw public key ServerCertificate.
5.6. Voucher Status Telemetry 5.6. Pledge Voucher Status Telemetry
The voucher status telemetry report is communicated from the pledge The voucher status telemetry report is communicated from the pledge
to the registrar over CoAP channel. The shortened URL is as to the registrar over CoAP channel. The shortened URL is as
described in table QQQ. described in table QQQ.
5.7. MASA authorization log Request 5.7. Registrar audit log request
There are no changes to the MASA audit log request. There are no changes to the Registrar audit log request.
5.7.1. MASA authorization log Response 5.7.1. MASA audit log response
There are no changes to the MASA audit log response. There are no changes to the MASA audit log response.
5.7.2. Registrar audit log verification
There are no changes to how the Registrar verifies the audit log.
5.8. EST Integration for PKI bootstrapping 5.8. EST Integration for PKI bootstrapping
There. TBD.
5.8.1. EST Distribution of CA Certificates 5.8.1. EST Distribution of CA Certificates
TBD. TBD.
5.8.2. EST CSR Attributes 5.8.2. EST CSR Attributes
TBD. In 6tisch, no Autonomic Control Plane will be created, so none of the
criteria for SubjectAltname found in
[I-D.ietf-anima-autonomic-control-plane] apply.
The CSR Attributes request SHOULD NOT be performed.
5.8.3. EST Client Certificate Request 5.8.3. EST Client Certificate Request
TBD. 6tisch will use a certificate to:
1. to authenticate an 802.15.9 key agreement protocol.
2. to terminate an incoming DTLS or EDHOC key agreement as part of
application data protection.
It is recommended that the requested subjectAltName contain only the
[RFC4514] hwSerialNum.
5.8.4. Enrollment Status Telemetry 5.8.4. Enrollment Status Telemetry
There are no changes to the status telemetry between Registrar and There are no changes to the status telemetry between Registrar and
MASA. MASA.
5.8.5. EST over CoAP 5.8.5. Multiple certificates
This document and [I-D.vanderstok-ace-coap-est] detail how to run EST Multiple certificates are not supported.
over CoAP.
5.8.6. EST over CoAP
This document and [I-D.ietf-ace-coap-est] detail how to run EST over
CoAP.
5.9. Use of Secure Transport for Minimal Join
Rather than bootstrap to a public key infrastructure, the secure
channel MAY instead be for the minimal security join process
described in [I-D.ietf-6tisch-minimal-security].
The desire to do a minimal-security join process is signaled by the
Registrar in it's voucher-request by including a 'join-process' value
of 'minimal'. The MASA copies this value into the voucher that is
creates, and also logs this to the audit log.
When the secure channel was created with EDHOC, then the keys setup
by EDHOC are simply used by OSCORE exactly as if they had been Pre-
Shared. The keys derived by EDHOC SHOULD be stored by both Registrar
and Pledge as their long term key should the join process need to be
repeated.
6. Reduced security operational modes 6. Reduced security operational modes
TBD This document defines a specific reduced security operational mode,
specifically:
1. X
2. Y
3. Z
6.1. Trust Model 6.1. Trust Model
TBD TBD
6.2. Pledge security reductions 6.2. Pledge security reductions
TBD TBD
6.3. Registrar security reductions 6.3. Registrar security reductions
skipping to change at page 20, line 17 skipping to change at page 23, line 31
TBD TBD
6.4. MASA security reductions 6.4. MASA security reductions
TBD TBD
7. IANA Considerations 7. IANA Considerations
XXX XXX
7.1. MIME-Type Registry 7.1. Well-known EST registration
XXX XXX
8. IANA Considerations 7.2. PKIX Registry
## PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 46 ## TBD
Voucher Status Telemetry . . . . . . . . . . . . . . . . 47
9. Security Considerations 7.3. Voucher Status Telemetry
TBD TBD
9.1. Security of MASA voucher signing key(s) 7.4. DNS Service Names
TBD TBD
10. Privacy Considerations 7.5. MUD File Extension for the MASA server
TBD
8. Privacy Considerations
[I-D.ietf-6lo-privacy-considerations] details a number of privacy [I-D.ietf-6lo-privacy-considerations] details a number of privacy
considerations important in Resource Constrained nodes. There are considerations important in Resource Constrained nodes. There are
two networks and three sets of constrained nodes to consider. They two networks and three sets of constrained nodes to consider. They
are: 1. the production nodes on the production network. 2. the new are: 1. the production nodes on the production network. 2. the new
pledges, which have yet to enroll, and which are on a join network. pledges, which have yet to enroll, and which are on a join network.
3. the production nodes which are also acting as proxy nodes. 3. the production nodes which are also acting as proxy nodes.
10.1. Privacy Considerations for Production network 8.1. Privacy Considerations for Production network
The details of this are out of scope for this document. The details of this are out of scope for this document.
10.2. Privacy Considerations for New Pledges 8.2. Privacy Considerations for New Pledges
New Pledges do not yet receive Router Advertisements with PIO New Pledges do not yet receive Router Advertisements with PIO
options, and so configure link-local addresses only based upon options, and so configure link-local addresses only based upon
layer-2 addresses using the normal SLAAC mechanisms described in layer-2 addresses using the normal SLAAC mechanisms described in
[RFC4191]. [RFC4191].
These link-local addresses are visible to any on-link eavesdropper These link-local addresses are visible to any on-link eavesdropper
(who is synchronized to the same Join Assistant), so regardless of (who is synchronized to the same Join Assistant), so regardless of
what is chosen they can be seen. This link-layer traffic is what is chosen they can be seen. This link-layer traffic is
encapsulated by the Join Proxy into IPIP packets and carried to the encapsulated by the Join Proxy into IPIP packets and carried to the
skipping to change at page 21, line 47 skipping to change at page 25, line 19
visible to passive observers in the 802.11AR IDevID certificate that visible to passive observers in the 802.11AR IDevID certificate that
is sent. is sent.
Even when TLS 1.3 is used, an active attacker could collect the Even when TLS 1.3 is used, an active attacker could collect the
information by creating a rogue proxy. information by creating a rogue proxy.
The use of a manufacturer assigned EUI64 (whether derived from IEEE The use of a manufacturer assigned EUI64 (whether derived from IEEE
assignment or created through another process during manufacturing assignment or created through another process during manufacturing
time) is encouraged. time) is encouraged.
10.2.1. EUI-64 derived address for join time IID 8.2.1. EUI-64 derived address for join time IID
The IID used in the link-local address used during the join process The IID used in the link-local address used during the join process
be a vendor assigned EUI-64. After the join process has concluded, be a vendor assigned EUI-64. After the join process has concluded,
the device SHOULD be assigned a unique randomly generated long the device SHOULD be assigned a unique randomly generated long
address, and a unique short address (not based upon the vendor EUI- address, and a unique short address (not based upon the vendor EUI-
64) for use at link-layer address. At that point, all layer-3 64) for use at link-layer address. At that point, all layer-3
content is encrypted by the layer-2 key. content is encrypted by the layer-2 key.
10.3. Privacy Considerations for Join Proxy 8.3. Privacy Considerations for Join Proxy
TBD. TBD.
11. Acknowledgements 9. Security Considerations
TBD
9.1. Security of MASA voucher signing key(s)
TBD
10. Acknowledgements
Kristofer Pister helped with many non-IETF references. Kristofer Pister helped with many non-IETF references.
12. References 11. References
12.1. Normative References 11.1. Normative References
[cullenCiscoPhoneDeploy] [cullenCiscoPhoneDeploy]
Jennings, C., "Transitive Trust Enrollment for Constrained Jennings, C., "Transitive Trust Enrollment for Constrained
Devices", 2012, <http://www.lix.polytechnique.fr/hipercom/ Devices", 2012, <http://www.lix.polytechnique.fr/hipercom/
SmartObjectSecurity/papers/CullenJennings.pdf>. SmartObjectSecurity/papers/CullenJennings.pdf>.
[I-D.ietf-6lo-privacy-considerations] [I-D.ietf-6lo-privacy-considerations]
Thaler, D., "Privacy Considerations for IPv6 Adaptation Thaler, D., "Privacy Considerations for IPv6 Adaptation
Layer Mechanisms", draft-ietf-6lo-privacy- Layer Mechanisms", draft-ietf-6lo-privacy-
considerations-04 (work in progress), October 2016. considerations-04 (work in progress), October 2016.
[I-D.ietf-6tisch-minimal] [I-D.ietf-6tisch-minimal]
Vilajosana, X., Pister, K., and T. Watteyne, "Minimal Vilajosana, X., Pister, K., and T. Watteyne, "Minimal
6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work
in progress), February 2017. in progress), February 2017.
[I-D.ietf-6tisch-minimal-security] [I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson, Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Minimal Security Framework for 6TiSCH", draft-ietf- "Minimal Security Framework for 6TiSCH", draft-ietf-
6tisch-minimal-security-04 (work in progress), October 6tisch-minimal-security-05 (work in progress), March 2018.
2017.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
802.15.4e", draft-ietf-6tisch-terminology-09 (work in draft-ietf-6tisch-terminology-10 (work in progress), March
progress), June 2017. 2018.
[I-D.ietf-ace-cbor-web-token] [I-D.ietf-ace-cbor-web-token]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-09 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15
(work in progress), October 2017. (work in progress), March 2018.
[I-D.ietf-ace-coap-est]
Stok, P., Kampanakis, P., Kumar, S., Richardson, M.,
Furuhed, M., and S. Raza, "EST over secure CoAP (EST-
coaps)", draft-ietf-ace-coap-est-00 (work in progress),
February 2018.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-08 (work in progress), October 2017. keyinfra-14 (work in progress), April 2018.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-anima-voucher] [I-D.ietf-anima-voucher]
Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"Voucher Profile for Bootstrapping Protocols", draft-ietf- "Voucher Profile for Bootstrapping Protocols", draft-ietf-
anima-voucher-06 (work in progress), October 2017. anima-voucher-07 (work in progress), January 2018.
[I-D.ietf-core-comi] [I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
Management Interface", draft-ietf-core-comi-01 (work in Management Interface", draft-ietf-core-comi-02 (work in
progress), July 2017. progress), December 2017.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-06 (work in (OSCORE)", draft-ietf-core-object-security-12 (work in
progress), October 2017. progress), March 2018.
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
Minaburo, "CBOR Encoding of Data Modeled with YANG", Minaburo, "CBOR Encoding of Data Modeled with YANG",
draft-ietf-core-yang-cbor-05 (work in progress), August draft-ietf-core-yang-cbor-06 (work in progress), February
2017. 2018.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "Keystore Model", draft-ietf-netconf- Watsen, K., "YANG Data Model for a "Keystore" Mechanism",
keystore-02 (work in progress), June 2017. draft-ietf-netconf-keystore-04 (work in progress), October
2017.
[I-D.richardson-6tisch-join-enhanced-beacon] [I-D.richardson-6tisch-join-enhanced-beacon]
Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational
Element encapsulation of 6tisch Join Information", draft- Element encapsulation of 6tisch Join Information", draft-
richardson-6tisch-join-enhanced-beacon-02 (work in richardson-6tisch-join-enhanced-beacon-03 (work in
progress), July 2017. progress), January 2018.
[I-D.richardson-6tisch-minimal-rekey] [I-D.richardson-6tisch-minimal-rekey]
Richardson, M., "Minimal Security rekeying mechanism for Richardson, M., "Minimal Security rekeying mechanism for
6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in 6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in
progress), August 2017. progress), August 2017.
[I-D.richardson-anima-6join-discovery] [I-D.richardson-anima-6join-discovery]
Richardson, M., "GRASP discovery of Registrar by Join Richardson, M., "GRASP discovery of Registrar by Join
Assistant", draft-richardson-anima-6join-discovery-00 Assistant", draft-richardson-anima-6join-discovery-00
(work in progress), October 2016. (work in progress), October 2016.
[I-D.richardson-anima-ace-constrained-voucher]
Richardson, M., Stok, P., and P. Kampanakis, "Constrained
Voucher Profile for Bootstrapping Protocols", draft-
richardson-anima-ace-constrained-voucher-03 (work in
progress), February 2018.
[I-D.schaad-cose-x509]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Headers for carrying and referencing X.509 certificates",
draft-schaad-cose-x509-01 (work in progress), May 2017.
[I-D.selander-ace-cose-ecdhe] [I-D.selander-ace-cose-ecdhe]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
cose-ecdhe-07 (work in progress), July 2017. cose-ecdhe-08 (work in progress), March 2018.
[I-D.vanderstok-ace-coap-est]
Kumar, S., Stok, P., Kampanakis, P., Furuhed, M., and S.
Raza, "EST over secure CoAP (EST-coaps)", draft-
vanderstok-ace-coap-est-02 (work in progress), June 2017.
[iec62591] [iec62591]
IEC, ., "62591:2016 Industrial networks - Wireless IEC, ., "62591:2016 Industrial networks - Wireless
communication network and communication profiles - communication network and communication profiles -
WirelessHART", 2016, WirelessHART", 2016,
<https://webstore.iec.ch/publication/24433>. <https://webstore.iec.ch/publication/24433>.
[ieee802-1AR] [ieee802-1AR]
IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
2009, <http://standards.ieee.org/findstds/ 2009, <http://standards.ieee.org/findstds/
skipping to change at page 25, line 5 skipping to change at page 28, line 39
Recommended Practice for Transport of Key Management Recommended Practice for Transport of Key Management
Protocol (KMP) Datagrams", 2016, Protocol (KMP) Datagrams", 2016,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/802.15.9-2016.html>. standard/802.15.9-2016.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, DOI 10.17487/RFC4514, June 2006,
<https://www.rfc-editor.org/info/rfc4514>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
skipping to change at page 25, line 43 skipping to change at page 29, line 37
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>. <https://www.rfc-editor.org/info/rfc7959>.
12.2. Informative References 11.2. Informative References
[duckling] [duckling]
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>.
[I-D.ietf-ace-actors] [I-D.ietf-ace-actors]
Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
architecture for authorization in constrained architecture for authorization in constrained
environments", draft-ietf-ace-actors-05 (work in environments", draft-ietf-ace-actors-06 (work in
progress), March 2017. progress), November 2017.
[I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-13 (work in progress), December 2017.
[I-D.ietf-core-sid] [I-D.ietf-core-sid]
Veillette, M., Pelov, A., Turner, R., Minaburo, A., and A. Veillette, M. and A. Pelov, "YANG Schema Item iDentifier
Somaraju, "YANG Schema Item iDentifier (SID)", draft-ietf- (SID)", draft-ietf-core-sid-03 (work in progress),
core-sid-01 (work in progress), May 2017. December 2017.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-19 (work in progress), October 2017. useofrplinfo-22 (work in progress), March 2018.
[ISA100] "The Technology Behind the ISA100.11a Standard", June [ISA100] "The Technology Behind the ISA100.11a Standard", June
2010, <http://www.isa100wci.org/Documents/PDF/ 2010, <http://www.isa100wci.org/Documents/PDF/
The-Technology-Behind-ISA100-11a-v-3_pptx>. The-Technology-Behind-ISA100-11a-v-3_pptx>.
[PFS] Wikipedia, ., "Forward Secrecy", August 2016, [PFS] Wikipedia, ., "Forward Secrecy", August 2016,
<https://en.wikipedia.org/w/ <https://en.wikipedia.org/w/
index.php?title=Forward_secrecy&oldid=731318899>. index.php?title=Forward_secrecy&oldid=731318899>.
[pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, [pledge-word]
Dictionary.com, ., "Dictionary.com Unabridged", 2015,
<http://dictionary.reference.com/browse/pledge>. <http://dictionary.reference.com/browse/pledge>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
 End of changes. 97 change blocks. 
388 lines changed or deleted 602 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/