draft-ietf-6tisch-dtsecurity-zerotouch-join-02.txt   draft-ietf-6tisch-dtsecurity-zerotouch-join-03.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 October 22, 2018
Expires: November 1, 2018 Silver Spring Networks Expires: April 25, 2019
April 30, 2018
6tisch Zero-Touch Secure Join protocol 6tisch Zero-Touch Secure Join protocol
draft-ietf-6tisch-dtsecurity-zerotouch-join-02 draft-ietf-6tisch-dtsecurity-zerotouch-join-03
Abstract Abstract
This document describes a Zero-touch Secure Join (ZSJ) mechanism to This document describes a Zero-touch Secure Join (ZSJ) mechanism to
enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network
using the 6tisch signaling mechanisms. The resulting device will using the 6tisch signaling mechanisms. The resulting device will
obtain a domain specific credential that can be used with either obtain a domain specific credential that can be used with either
802.15.9 per-host pair keying protocols, or to obtain the network- 802.15.9 per-host pair keying protocols, or to obtain the network-
wide key from a coordinator. The mechanism describe here is an wide key from a coordinator. The mechanism describe here is an
augmentation to the one-touch mechanism described in augmentation to the one-touch mechanism described in
skipping to change at page 1, line 39 skipping to change at page 1, line 38
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 November 1, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 27
1.3.3. Network Access Controls . . . . . . . . . . . . . . . 8 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 8
1.4. Leveraging the new key infrastructure / next steps . . . 8 1.4. Leveraging the new key infrastructure / next steps . . . 8
1.4.1. Key Distribution Process . . . . . . . . . . . . . . 8 1.4.1. Key Distribution Process . . . . . . . . . . . . . . 8
1.5. Requirements for Autonomic Network Infrastructure (ANI) 1.5. Requirements for Autonomic Network Infrastructure (ANI)
devices . . . . . . . . . . . . . . . . . . . . . . . . . 8 devices . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 9 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 9
2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 10 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 10
2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 10 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 10
2.3.1. Identification of the Pledge . . . . . . . . . . . . 11 2.3.1. Identification of the Pledge . . . . . . . . . . . . 11
2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 11 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 12
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 12 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Architectural Components . . . . . . . . . . . . . . . . 13 2.5. Architectural Components . . . . . . . . . . . . . . . . 13
2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 13 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.2. Stateless IPIP Join Proxy . . . . . . . . . . . . . . 13 2.5.2. Stateless IPIP Join Proxy . . . . . . . . . . . . . . 13
2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 13 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 13
2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 14 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 14
2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 14 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 14
2.6. Certificate Time Validation . . . . . . . . . . . . . . . 14 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 14
2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 14 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 14
2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 14 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 14
2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 14 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 14
2.8. Determining the MASA to contact . . . . . . . . . . . . . 14 2.8. Determining the MASA to contact . . . . . . . . . . . . . 15
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 15 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 15
4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 15 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 15
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 15 5. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 15 5.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 15
4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 15 5.2. CoAP connection to Registrar . . . . . . . . . . . . . . 16
4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 15 5.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 16
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 16 5.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 16
5.1. BRSKI-EST (D)TLS establishment details . . . . . . . . . 16 6. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 16
5.1.1. BRSKI-EST CoAP/DTLS estasblishment details . . . . . 16 6.1. BRSKI-EST (D)TLS establishment details . . . . . . . . . 17
5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details . . . . . 17 6.1.1. BRSKI-EST CoAP/DTLS estasblishment details . . . . . 17
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 18 6.1.2. BRSKI-EST CoAP/EDHOC estasblishment details . . . . . 17
5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 18 6.2. Pledge Requests Voucher from the Registrar . . . . . . . 19
5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 19 6.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 19
5.4.1. MASA renewal of expired vouchers . . . . . . . . . . 19 6.4. Registrar Requests Voucher from MASA . . . . . . . . . . 19
5.4.2. MASA verification of voucher-request signature 6.4.1. MASA renewal of expired vouchers . . . . . . . . . . 20
consistency . . . . . . . . . . . . . . . . . . . . . 19 6.4.2. MASA verification of voucher-request signature
5.4.3. MASA authentication of registrar (certificate) . . . 19 consistency . . . . . . . . . . . . . . . . . . . . . 20
5.4.4. MASA revocation checking of registrar (certificate) . 20 6.4.3. MASA authentication of registrar (certificate) . . . 20
5.4.5. MASA verification of pledge prior-signed-voucher- 6.4.4. MASA revocation checking of registrar (certificate) . 20
request . . . . . . . . . . . . . . . . . . . . . . . 20 6.4.5. MASA verification of pledge prior-signed-voucher-
5.4.6. MASA pinning of registrar . . . . . . . . . . . . . . 20 request . . . . . . . . . . . . . . . . . . . . . . . 21
5.4.7. MASA nonce handling . . . . . . . . . . . . . . . . . 20 6.4.6. MASA pinning of registrar . . . . . . . . . . . . . . 21
5.5. MASA Voucher Response . . . . . . . . . . . . . . . . . . 20 6.4.7. MASA nonce handling . . . . . . . . . . . . . . . . . 21
5.5.1. Pledge voucher verification . . . . . . . . . . . . . 21 6.5. MASA Voucher Response . . . . . . . . . . . . . . . . . . 21
5.5.2. Pledge authentication of provisional TLS connection . 21 6.5.1. Pledge voucher verification . . . . . . . . . . . . . 22
5.6. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 21 6.5.2. Pledge authentication of provisional TLS connection . 22
5.7. Registrar audit log request . . . . . . . . . . . . . . . 21 6.6. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 22
5.7.1. MASA audit log response . . . . . . . . . . . . . . . 21 6.7. Registrar audit log request . . . . . . . . . . . . . . . 22
5.7.2. Registrar audit log verification . . . . . . . . . . 21 6.7.1. MASA audit log response . . . . . . . . . . . . . . . 22
5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 21 6.7.2. Registrar audit log verification . . . . . . . . . . 22
5.8.1. EST Distribution of CA Certificates . . . . . . . . . 21 6.8. EST Integration for PKI bootstrapping . . . . . . . . . . 22
5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 21 6.8.1. EST Distribution of CA Certificates . . . . . . . . . 22
5.8.3. EST Client Certificate Request . . . . . . . . . . . 22 6.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 23
5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 22 6.8.3. EST Client Certificate Request . . . . . . . . . . . 23
5.8.5. Multiple certificates . . . . . . . . . . . . . . . . 22 6.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 23
5.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 22 6.8.5. Multiple certificates . . . . . . . . . . . . . . . . 23
5.9. Use of Secure Transport for Minimal Join . . . . . . . . 22 6.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 23
6. Reduced security operational modes . . . . . . . . . . . . . 22 6.9. Use of Secure Transport for Minimal Join . . . . . . . . 23
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 23 7. Reduced security operational modes . . . . . . . . . . . . . 24
6.2. Pledge security reductions . . . . . . . . . . . . . . . 23 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. Registrar security reductions . . . . . . . . . . . . . . 23 7.2. Pledge security reductions . . . . . . . . . . . . . . . 24
6.4. MASA security reductions . . . . . . . . . . . . . . . . 23 7.3. Registrar security reductions . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7.4. MASA security reductions . . . . . . . . . . . . . . . . 24
7.1. Well-known EST registration . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Well-known EST registration . . . . . . . . . . . . . . . 24
7.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 23 8.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 24
7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 23 8.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 24
7.5. MUD File Extension for the MASA server . . . . . . . . . 23 8.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 25
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 8.5. MUD File Extension for the MASA server . . . . . . . . . 25
8.1. Privacy Considerations for Production network . . . . . . 24 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
8.2. Privacy Considerations for New Pledges . . . . . . . . . 24 9.1. Privacy Considerations for Production network . . . . . . 25
8.2.1. EUI-64 derived address for join time IID . . . . . . 25 9.2. Privacy Considerations for New Pledges . . . . . . . . . 25
8.3. Privacy Considerations for Join Proxy . . . . . . . . . . 25 9.2.1. EUI-64 derived address for join time IID . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9.3. Privacy Considerations for Join Proxy . . . . . . . . . . 26
9.1. Security of MASA voucher signing key(s) . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 10.1. Security of MASA voucher signing key(s) . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Extra text . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Extra text . . . . . . . . . . . . . . . . . . . . . 32
A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 31 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 32
A.1.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 31 A.1.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 32
A.1.2. Factory provided credentials (if any) . . . . . . . . 31 A.1.2. Factory provided credentials (if any) . . . . . . . . 33
A.1.3. Credentials to be introduced . . . . . . . . . . . . 31 A.1.3. Credentials to be introduced . . . . . . . . . . . . 33
A.2. Network Assumptions . . . . . . . . . . . . . . . . . . . 32 A.2. Network Assumptions . . . . . . . . . . . . . . . . . . . 33
A.2.1. Security above and below IP . . . . . . . . . . . . . 32 A.2.1. Security above and below IP . . . . . . . . . . . . . 33
A.2.2. Join network assumptions . . . . . . . . . . . . . . 33 A.2.2. Join network assumptions . . . . . . . . . . . . . . 34
A.2.3. Number and cost of round trips . . . . . . . . . . . 33 A.2.3. Number and cost of round trips . . . . . . . . . . . 35
A.2.4. Size of packets, number of fragments . . . . . . . . 33 A.2.4. Size of packets, number of fragments . . . . . . . . 35
A.3. Target end-state for join process . . . . . . . . . . . . 33 A.3. Target end-state for join process . . . . . . . . . . . . 35
Appendix B. Join Protocol . . . . . . . . . . . . . . . . . . . 34 Appendix B. Join Protocol . . . . . . . . . . . . . . . . . . . 35
B.1. Key Agreement process . . . . . . . . . . . . . . . . . . 34 B.1. Key Agreement process . . . . . . . . . . . . . . . . . . 36
B.2. Provisional Enrollment process . . . . . . . . . . . . . 35 B.2. Provisional Enrollment process . . . . . . . . . . . . . 36
Appendix C. IANA Considerations . . . . . . . . . . . . . . . . 36 Appendix C. IANA Considerations . . . . . . . . . . . . . . . . 37
Appendix D. Protocol Definition . . . . . . . . . . . . . . . . 36 Appendix D. Protocol Definition . . . . . . . . . . . . . . . . 37
D.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 36 D.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 37
D.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 37 D.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 38
D.1.2. Registrar Discovery Protocol Details . . . . . . . . 37 D.1.2. Registrar Discovery Protocol Details . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38
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 46 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. This constrained protocol is called ZSJ. polish ending. This constrained protocol is called ZSJ (pronounced
zees-Jay).
This document follows the same structure as it's parent in order to This document follows the same structure as BRSKI 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 constrained networks of constrained devices. Like
[I-D.ietf-anima-bootstrapping-keyinfra], the networks which are in [I-D.ietf-anima-bootstrapping-keyinfra], the networks which are in
scope for this protocol are deployed by a professional operator. The scope for this protocol are deployed by a professional operator. The
deterministic mechanisms which have been designed into 6tisch have deterministic mechanisms which have been designed into 6tisch have
been created to satisfy the operational needs of industrial settings been created to satisfy the operational needs of industrial settings
where such an operator exists. 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, but preceeding it with either the EDHOC mechanism when appropriate, but preceeding it with either the EDHOC
key agreement protocol, or a DTLS channel. The [RFC7030] EST key agreement protocol, or a DTLS setup process. The [RFC7030] EST
protocol extended in [I-D.ietf-6tisch-minimal-security], has been protocol extended in [I-D.ietf-6tisch-minimal-security], has been
mapped by [I-D.ietf-ace-coap-est] into CoAP. mapped by [I-D.ietf-ace-coap-est] into CoAP, and has the same
security profile as this protocol.
Whenever possible, this document does not introduce new protocols or
mechanisms, but rather integrates them from other documents.
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 43 skipping to change at page 5, line 48
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 unavailable, 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, however, the resulting vouchers have operation is also supported, however, the resulting vouchers have
infinite life. infinite life.
802.1AR Client certificates are retained, but optionally are 802.1AR Client Certificates (IDevID) 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.
NOTE TO RFC-EDITOR: during production of this document, it was NOTE TO RFC-EDITOR: during production of this document, it was
matched against [I-D.ietf-anima-bootstrapping-keyinfra] section by matched against [I-D.ietf-anima-bootstrapping-keyinfra] section by
section. This results in a few sections, such as IANA Considerations section. This results in a few sections, such as IANA Considerations
where there is no requested activity. Those sections are marked "NO where there is no requested activity. Those sections are marked "NO
ACTION, PLEASE REMOVE" and should be removed (along with this ACTION, PLEASE REMOVE" and should be removed (along with this
paragraph) from the final document. paragraph) from the final document. Some sections are marked as "no
changes" and should be left in place so that the section numbering
remains consistent with [I-D.ietf-anima-bootstrapping-keyinfra].
1.1. Prior Bootstrapping Approaches 1.1. Prior Bootstrapping Approaches
Constrained devices as used in industrial control systems are usually Constrained devices as used in industrial control systems are usually
installed (or replaced) by technicians with expertise in the installed (or replaced) by technicians with expertise in the
equipment being serviced, not in secure enrollment of devices. equipment being serviced, not in secure enrollment of devices.
Devices therefore are typically pre-configured in advance, marked for Devices therefore are typically pre-configured in advance, marked for
a particular factory, assembly line, or even down to the specific a particular factory, assembly line, or even down to the specific
machine. It is not uncommon for manufacturers to have a product code machine. It is not uncommon for manufacturers to have a product code
skipping to change at page 11, line 8 skipping to change at page 11, line 8
2.3. Initial Device Identifier 2.3. Initial Device Identifier
The essential component of the zero-touch operation is that the The essential component of the zero-touch operation is that the
pledge is provisioned with an 802.1AR (PKIX) certificate installed pledge is provisioned with an 802.1AR (PKIX) certificate installed
during the manufacturing process. during the manufacturing process.
It is expected that constrained devices will use a signature It is expected that constrained devices will use a signature
algorithm corresponding to the hardware acceleration that they have, algorithm corresponding to the hardware acceleration that they have,
if they have any. The anticipated algorithms are the ECDSA P-256 if they have any. The anticipated algorithms are the ECDSA P-256
(secp256p1) as SHOULD-, while newer devices SHOLD+ begin to appear (secp256p1), and SHOULD be supported. Newer devices SHOULD begin to
using EdDSA curves using the 25519 curves. (EDNOTE details here) appear using EdDSA curves using the 25519 curves.
The manufacturer will always know what algorithms are available in
the Pledge, and will use an appropriate one. The other components
that need to evaluate the IDevID (the Registrar and MASA) are
expected to support all common algorithms.
There are a number of simplications detailed later on in this There are a number of simplications detailed later on in this
document designed to eliminate the need for an ASN.1 parser in the document designed to eliminate the need for an ASN.1 parser in the
pledge. pledge.
The pledge should consider it's 802.1AR certificate to be an opaque The pledge should consider it's 802.1AR certificate to be an opaque
blob of bytes, to be inserted into protocols at appropriate places. blob of bytes, to be inserted into protocols at appropriate places.
The pledge SHOULD have access to it's public and private keys in the The pledge SHOULD have access to it's public and private keys in the
most useable native format for computation. most useable native format for computation.
The pledge MUST have the public key of the MASA built in a The pledge MUST have the public key of the MASA built in a
manufacturer time. This is a seemingly identical requirement as for manufacturer time. This is a seemingly identical requirement as for
BRSKI, but rather than being an abstract trust anchor that can be BRSKI, but rather than being an abstract trust anchor that can be
augmented with a certificate chain, the pledge MUST be provided with augmented with a certificate chain, the pledge MUST be provided with
the Raw Public Key that the MASA will use to sign vouchers for that the Raw Public Key that the MASA will use to sign vouchers for that
pledge. pledge.
There are a number of security concerns with use of a single MASA There are a number of security concerns with use of a single MASA
signing key, and section Section 9.1 addresses some of them with some signing key, and section Section 10.1 addresses some of them with
operational suggestions. some operational suggestions.
BRSKI places some clear requirements upon the contents of the IDevID, BRSKI places some clear requirements upon the contents of the IDevID,
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
skipping to change at page 15, line 8 skipping to change at page 15, line 13
enrolled, so no alternate registrar is ever possible. enrolled, so no alternate registrar is ever possible.
2.8. 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
The voucher-request artifact is defined in The voucher-request artifact is defined in
[I-D.richardson-anima-ace-constrained-voucher] section 6.1. [I-D.ietf-anima-constrained-voucher] section 6.1.
For the 6tisch ZSJ protocol defined in this document, only COSE For the 6tisch ZSJ protocol defined in this document, only COSE
signed vouchers as described in signed vouchers as described in [I-D.ietf-anima-constrained-voucher]
[I-D.richardson-anima-ace-constrained-voucher] section 6.3.2 are section 6.3.2 are supported.
supported.
4. Proxying details (Pledge - Proxy - Registrar) 4. Proxying details (Pledge - Proxy - Registrar)
The voucher-request artifact is defined in
[I-D.ietf-anima-constrained-voucher].
The 6tisch use of the constrained version differs from the non-
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 COSE format voucher requests.
5. Proxy details
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 as there is constrained situation the proxy needs to be stateless as there is
very little ram to begin with, and none can be allocated to keep very little ram to begin with, and none can be allocated to keep
state for an unlimited number of potential pledges. state for an unlimited number of potential pledges.
4.1. Pledge discovery of Proxy 5.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 ZSJ, the existence of the messages sent by the proxy. In 6tisch ZSJ, the existence of the
proxy is announced by the Enhanced Beacon defined in proxy is announced by the Enhanced Beacon message described in
[I-D.richardson-6tisch-join-enhanced-beacon]. [I-D.richardson-6tisch-enrollment-enhanced-beacon]. The proxy as
described by [I-D.ietf-6tisch-minimal-security] section 10 is to be
used in an identical fashion when EDHOC and OSCOAP are used.
4.2. CoAP connection to Registrar When DTLS security is provided, then the proxy mechanism described in
TBD must be used.
5.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 5.3. HTTPS proxy connection to Registrar
HTTPS connections are not used between the Pledge, Proxy and HTTPS connections are not used between the Pledge, Proxy and
Registrar. The Proxy relays CoAP or DTLS packets and does not Registrar. The Proxy relays CoAP or DTLS packets and does not
interpret or terminate either CoAP or DTLS connections. (HTTPS is interpret or terminate either CoAP or DTLS connections. (HTTPS is
still used between the Registrar and MASA) still used between the Registrar and MASA)
4.4. Proxy discovery of Registrar 5.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. listening for GRASP messages.
In the constrained network, the proxies are optionally configured In the constrained network, the proxies are optionally configured
with the address of the JRC by the Join Response in with the address of the JRC by the Join Response in in
[I-D.ietf-6tisch-minimal-security] section 8. As specified in that [I-D.ietf-6tisch-minimal-security] section 9.3.2. (As described in
section, if the address of the registrar otherwise defaults to be that section, the address of the registrar otherwise defaults to be
that of the DODAG root. that of the DODAG root)
Whether or not a 6LR will announce itself as a possible Join Proxy is Whether or not a 6LR will announce itself as a possible Join Proxy is
outside the scope of this document. outside the scope of this document.
5. Protocol Details (Pledge - Registrar - MASA) 6. 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.
BRSKI introduces the concept of a provisional state for EST.
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
been confirmed. 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].
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, and OSCOAP security, but such a specification does not yet exist, and
this document does at this point specify it. this document does at this point specify it.
[I-D.ietf-ace-coap-est] specifies that CoAP specifies the use of CoAP [I-D.ietf-ace-coap-est] specifies that CoAP specifies the use of CoAP
Block-Wise Transfer ("Block") [RFC7959] to fragment EST messages at Block-Wise Transfer ("Block") [RFC7959] to fragment EST 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
skipping to change at page 16, line 38 skipping to change at page 17, line 25
As in [I-D.ietf-ace-coap-est], support for Observe CoAP options 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. message flows.
Observe options could be used by the server to notify clients about a 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 change in the cacerts or csr attributes (resources) and might be an
area of future work. 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 6.1. BRSKI-EST (D)TLS establishment details
6tisch ZSJ 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 6.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. A The registrar SHOULD authenticate itself with a raw public key. A
256 bit ECDSA raw public key is RECOMMENDED. Pledges SHOULD support 256 bit ECDSA raw public key is RECOMMENDED. Pledges SHOULD support
EDDSA keys if they contain hardware that supports doing so EDDSA keys if they contain hardware that supports doing so
efficiently. efficiently.
TBD: the Pledge needs to signal what kind of Raw Public Key it TBD: the Pledge needs to signal what kind of Raw Public Key it
supports before the Registrar sends its ServerCertificate. Can SNI supports before the Registrar sends its ServerCertificate. Can SNI
be used to do this? 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 as a ClientCertificate. certificate as a ClientCertificate.
5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details 6.1.2. BRSKI-EST CoAP/EDHOC estasblishment details
[I-D.selander-ace-cose-ecdhe] details how to use EDHOC. The EDHOC [I-D.selander-ace-cose-ecdhe] details how to use EDHOC. The EDHOC
description identifiers a party U (the initiator), and a party V. 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 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 communication from the Pledge is via CoAP via the Join Proxy.
The Join proxy relays traffic to the JRC, and using the mechanism 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 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 designed so that the Join Proxy does not need to know if it is
performing the one-touch enrollment described in performing the one-touch enrollment described in
skipping to change at page 18, line 32 skipping to change at page 19, line 20
A COAP confirmable message SHOULD be used. A COAP confirmable message SHOULD be used.
[I-D.ietf-6tisch-minimal-security] section 6 details how to setup [I-D.ietf-6tisch-minimal-security] section 6 details how to setup
OSCORE context given a shared key derived by EDHOC. 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 6.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.
In order to simplify the pledge, the use of a certificate (and chain) In order to simplify the pledge, the use of a certificate (and chain)
for the Registrar is not supported. Instead the newly defined for the Registrar is not supported. Instead the newly defined
pinned-domain-subject-public-key-info must contain the (raw) public pinned-domain-subject-public-key-info must contain the (raw) public
key info for the Registrar. It MUST be byte for byte identical to key info for the Registrar. It MUST be byte for byte identical to
that which is transmitted by the Registrar during the TLS that which is transmitted by the Registrar during the TLS
ServerCertificate handshake. ServerCertificate handshake.
BRSKI permits the voucher request to be signed or unsigned. This BRSKI permits the voucher request to be signed or unsigned. This
document defines the voucher request to be unsigned. document defines the voucher request to be unsigned.
5.3. BRSKI-MASA TLS establishment details 6.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 6.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. constrained devices.
The format of the voucher is COSE, which implies changes to both the The format of the voucher is COSE, which implies changes to both the
Registrar and the MASA, but semantically the content is the same. 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. It is 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 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- 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 BRSKI-EST connection has already failed, and this step is never
reached. reached.
5.4.1. MASA renewal of expired vouchers 6.4.1. MASA renewal of expired vouchers
There are assumed to be no useful real-time clocks on constrained There are assumed to be no useful real-time clocks on constrained
devices, so all vouchers are in effect infinite duration. Pledges devices, so all vouchers are in effect infinite duration. Pledges
will use nonces for freshness, and a request for a new voucher with a 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 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 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 per-day, but more than one voucher can be issued in a one hour
period. Tokens should not accumulate for more than one day! period. Tokens should not accumulate for more than one day!
5.4.2. MASA verification of voucher-request signature consistency 6.4.2. MASA verification of voucher-request signature consistency
The voucher-request is signed by the Registrar using it's Raw Public The voucher-request is signed by the Registrar using it's Raw Public
Key. There is no additional certificate authority to sign this key. Key. There is no additional certificate authority to sign this key.
The MASA MAY have this key via sales-channel integration, but in most The MASA MAY have this key via sales-channel integration, but in most
cases it will be seeing the key for the first time. cases it will be seeing the key for the first time.
XXX-should the TLS connection from Registrar to MASA have a XXX-should the TLS connection from Registrar to MASA have a
ClientCertificate? If so, then should it use the same Public Key? ClientCertificate? If so, then should it use the same Public Key?
Or a different one? Or a different one?
5.4.3. MASA authentication of registrar (certificate) 6.4.3. MASA authentication of registrar (certificate)
IDEA: The MASA SHOULD pin the Raw Public Key (RPK) to the IP address 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 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 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 mean, "IP subnet", essentially the IPv4/24, and IPv6/64? The value
of doing is about DDoS mitigation? of doing is about DDoS mitigation?
Should above mapping be on a per-Pledge basis? Should above mapping be on a per-Pledge basis?
5.4.4. MASA revocation checking of registrar (certificate) 6.4.4. MASA revocation checking of registrar (certificate)
As the Registrar has a Raw Public Key as an identity, there is no As the Registrar has a Raw Public Key as an identity, there is no
meaningful standard revocation checking that can be done. The MASA meaningful standard revocation checking that can be done. The MASA
SHOULD have a blacklist table, and a way to add entries, but this SHOULD have a blacklist table, and a way to add entries, but this
process is out of scope. process is out of scope.
5.4.5. MASA verification of pledge prior-signed-voucher-request 6.4.5. MASA verification of pledge prior-signed-voucher-request
The MASA will know whether or not the Pledge is capable of producing 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 a signed voucher-request for inclusion by the Registrar. In the case
where the Pledge can sign the voucher-request to the Registrar, then 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 Registrar will have put it in the 'prior-signed-voucher-request'.
The MASA can verify the signature from the Pledge using the MASA's The MASA can verify the signature from the Pledge using the MASA's
copy of the Pledge's IDevID public key. copy of the Pledge's IDevID public key.
In many cases, the Pledge will not be capable of doing signatures in 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 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 MASA will have rely on the audit log as a history function to
determine if the Pledge has previously been claimed, and to identify determine if the Pledge has previously been claimed, and to identify
situations where the claim from the Registrar is fraudulent. situations where the claim from the Registrar is fraudulent.
5.4.6. MASA pinning of registrar 6.4.6. MASA pinning of registrar
When the MASA creates a voucher, it puts the Registrar's Raw Public 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 Key into the 'pinned-domain-subject-public-key-info' leaf of the
voucher. voucher.
The MASA does not include the 'pinned-domain-cert' field. The MASA does not include the 'pinned-domain-cert' field.
5.4.7. MASA nonce handling 6.4.7. MASA nonce handling
Use of nonces is highly RECOMMENDED, but there are situations where Use of nonces is highly RECOMMENDED, but there are situations where
not all components are connected at the same time in which the nonce not all components are connected at the same time in which the nonce
will not be present. will not be present.
There are no significant changes from BRSKI. There are no significant changes from BRSKI.
5.5. MASA Voucher Response 6.5. MASA Voucher Response
The MASA responses with a voucher as specified in As exaplained in [I-D.ietf-anima-constrained-voucher] section 6.3.2,
[I-D.richardson-anima-ace-constrained-voucher] section 6.2. when a voucher is returned by the MASA to the JRC, a public key or
certificate container that will verify the voucher SHOULD also be
returned.
This result is communicated back with a MIME Content-Type of In order to do this, the MASA MAY return a multipart/mixed return,
'application/voucher-cose+cbor' within that body, two items SHOULD be returned:
5.5.1. Pledge voucher verification 1. An application/voucher-cose+cbor body.
2. An application/pkcs7-mime; smime-type=certs-only, or an
application/SOMETHING containing a Raw Public Key.
A MASA is not obligated to return the public key, and MAY return only
the application/voucher-cose+cbor object. In that case, the JRC will
be unable to validate it.
6.5.1. Pledge voucher verification
The Pledge receives the voucher from the Registrar over it's CoAP The Pledge receives the voucher from the Registrar over it's CoAP
connection. It verifies the signature using the MASA anchor built connection. It verifies the signature using the MASA anchor built
in, as in the BRSKI case. in, as in the BRSKI case.
5.5.2. Pledge authentication of provisional TLS connection 6.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. Pledge Voucher Status Telemetry 6.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. Registrar audit log request 6.7. Registrar audit log request
There are no changes to the Registrar audit log request. There are no changes to the Registrar audit log request.
5.7.1. MASA audit log response 6.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 6.7.2. Registrar audit log verification
There are no changes to how the Registrar verifies the audit log. There are no changes to how the Registrar verifies the audit log.
5.8. EST Integration for PKI bootstrapping 6.8. EST Integration for PKI bootstrapping
TBD. TBD.
5.8.1. EST Distribution of CA Certificates 6.8.1. EST Distribution of CA Certificates
TBD. TBD.
5.8.2. EST CSR Attributes 6.8.2. EST CSR Attributes
In 6tisch, no Autonomic Control Plane will be created, so none of the In 6tisch, no Autonomic Control Plane will be created, so none of the
criteria for SubjectAltname found in criteria for SubjectAltname found in
[I-D.ietf-anima-autonomic-control-plane] apply. [I-D.ietf-anima-autonomic-control-plane] apply.
The CSR Attributes request SHOULD NOT be performed. The CSR Attributes request SHOULD NOT be performed.
5.8.3. EST Client Certificate Request 6.8.3. EST Client Certificate Request
6tisch will use a certificate to: 6tisch will use a certificate to:
1. to authenticate an 802.15.9 key agreement protocol. 1. to authenticate an 802.15.9 key agreement protocol.
2. to terminate an incoming DTLS or EDHOC key agreement as part of 2. to terminate an incoming DTLS or EDHOC key agreement as part of
application data protection. application data protection.
It is recommended that the requested subjectAltName contain only the It is recommended that the requested subjectAltName contain only the
[RFC4514] hwSerialNum. [RFC4514] hwSerialNum.
5.8.4. Enrollment Status Telemetry 6.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. Multiple certificates 6.8.5. Multiple certificates
Multiple certificates are not supported. Multiple certificates are not supported.
5.8.6. EST over CoAP 6.8.6. EST over CoAP
This document and [I-D.ietf-ace-coap-est] detail how to run EST over This document and [I-D.ietf-ace-coap-est] detail how to run EST over
CoAP. CoAP.
5.9. Use of Secure Transport for Minimal Join 6.9. Use of Secure Transport for Minimal Join
Rather than bootstrap to a public key infrastructure, the secure Rather than bootstrap to a public key infrastructure, the secure
channel MAY instead be for the minimal security join process channel MAY instead be for the minimal security join process
described in [I-D.ietf-6tisch-minimal-security]. described in [I-D.ietf-6tisch-minimal-security].
The desire to do a minimal-security join process is signaled by the 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 Registrar in it's voucher-request by including a 'join-process' value
of 'minimal'. The MASA copies this value into the voucher that is of 'minimal'. The MASA copies this value into the voucher that is
creates, and also logs this to the audit log. creates, and also logs this to the audit log.
When the secure channel was created with EDHOC, then the keys setup 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- 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 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 and Pledge as their long term key should the join process need to be
repeated. repeated.
6. Reduced security operational modes 7. Reduced security operational modes
This document defines a specific reduced security operational mode, This document defines a specific reduced security operational mode,
specifically: specifically:
1. X 1. X
2. Y 2. Y
3. Z 3. Z
6.1. Trust Model 7.1. Trust Model
TBD TBD
6.2. Pledge security reductions 7.2. Pledge security reductions
TBD TBD
6.3. Registrar security reductions 7.3. Registrar security reductions
TBD TBD
6.4. MASA security reductions 7.4. MASA security reductions
TBD TBD
7. IANA Considerations 8. IANA Considerations
XXX XXX
7.1. Well-known EST registration 8.1. Well-known EST registration
XXX XXX
7.2. PKIX Registry 8.2. PKIX Registry
TBD TBD
7.3. Voucher Status Telemetry 8.3. Voucher Status Telemetry
TBD TBD
7.4. DNS Service Names 8.4. DNS Service Names
TBD TBD
7.5. MUD File Extension for the MASA server 8.5. MUD File Extension for the MASA server
TBD TBD
8. Privacy Considerations 9. 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.
8.1. Privacy Considerations for Production network 9.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.
8.2. Privacy Considerations for New Pledges 9.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 25, line 19 skipping to change at page 26, line 27
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.
8.2.1. EUI-64 derived address for join time IID 9.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.
8.3. Privacy Considerations for Join Proxy 9.3. Privacy Considerations for Join Proxy
TBD. TBD.
9. Security Considerations 10. Security Considerations
TBD TBD
9.1. Security of MASA voucher signing key(s) 10.1. Security of MASA voucher signing key(s)
TBD TBD
10. Acknowledgements 11. Acknowledgements
Kristofer Pister helped with many non-IETF references. Kristofer Pister helped with many non-IETF references.
11. References 12. References
11.1. Normative References 12.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-05 (work in progress), March 2018. 6tisch-minimal-security-06 (work in progress), May 2018.
[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,
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
draft-ietf-6tisch-terminology-10 (work in progress), March draft-ietf-6tisch-terminology-10 (work in progress), March
2018. 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-15 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15
(work in progress), March 2018. (work in progress), March 2018.
[I-D.ietf-ace-coap-est] [I-D.ietf-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-ietf-ace-coap-est-00 (work in progress), coaps)", draft-ietf-ace-coap-est-06 (work in progress),
February 2018. October 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-14 (work in progress), April 2018. keyinfra-16 (work in progress), June 2018.
[I-D.ietf-anima-constrained-voucher]
Richardson, M., Stok, P., and P. Kampanakis, "Constrained
Voucher Artifacts for Bootstrapping Protocols", draft-
ietf-anima-constrained-voucher-02 (work in progress),
September 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-07 (work in progress), January 2018. 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-02 (work in Management Interface", draft-ietf-core-comi-03 (work in
progress), December 2017. progress), June 2018.
[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-12 (work in (OSCORE)", draft-ietf-core-object-security-15 (work in
progress), March 2018. progress), August 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-06 (work in progress), February draft-ietf-core-yang-cbor-07 (work in progress), September
2018. 2018.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "YANG Data Model for a "Keystore" Mechanism", Watsen, K., "YANG Data Model for a Centralized Keystore
draft-ietf-netconf-keystore-04 (work in progress), October Mechanism", draft-ietf-netconf-keystore-06 (work in
2017. progress), September 2018.
[I-D.richardson-6tisch-enrollment-enhanced-beacon]
Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational
Element encapsulation of 6tisch Join and Enrollment
Information", draft-richardson-6tisch-enrollment-enhanced-
beacon-01 (work in progress), April 2018.
[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-03 (work in richardson-6tisch-join-enhanced-beacon-03 (work in
progress), January 2018. 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] [I-D.schaad-cose-x509]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Headers for carrying and referencing X.509 certificates", Headers for carrying and referencing X.509 certificates",
draft-schaad-cose-x509-01 (work in progress), May 2017. draft-schaad-cose-x509-02 (work in progress), July 2018.
[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-08 (work in progress), March 2018. cose-ecdhe-10 (work in progress), September 2018.
[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 29, line 37 skipping to change at page 31, line 15
[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>.
11.2. Informative References 12.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-06 (work in environments", draft-ietf-ace-actors-07 (work in
progress), November 2017. progress), October 2018.
[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-18 (work in progress), August 2018.
[I-D.ietf-core-sid] [I-D.ietf-core-sid]
Veillette, M. and A. Pelov, "YANG Schema Item iDentifier Veillette, M. and A. Pelov, "YANG Schema Item iDentifier
(SID)", draft-ietf-core-sid-03 (work in progress), (SID)", draft-ietf-core-sid-04 (work in progress), June
December 2017. 2018.
[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-22 (work in progress), March 2018. useofrplinfo-23 (work in progress), May 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-word] [pledge-word]
skipping to change at page 37, line 20 skipping to change at page 38, line 20
D.1.2. Registrar Discovery Protocol Details D.1.2. Registrar Discovery Protocol Details
The Registrar is not discovered by the Proxy. Any device that is The Registrar is not discovered by the Proxy. Any device that is
expected to be able to operate as a Registrar MAY be told the address expected to be able to operate as a Registrar MAY be told the address
of the Registrar when that device joins the network. The address MAY of the Registrar when that device joins the network. The address MAY
be included in the [I-D.ietf-6tisch-minimal-security] Join Response. be included in the [I-D.ietf-6tisch-minimal-security] Join Response.
If the address is NOT included, then Proxy may assume that the If the address is NOT included, then Proxy may assume that the
Registrar can be found at the DODAG root, which is well known in the Registrar can be found at the DODAG root, which is well known in the
6tisch's use of the RPL protocol. 6tisch's use of the RPL protocol.
Authors' Addresses Author's Address
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
Benjamin Damm
Silver Spring Networks
Email: bdamm@ssni.com
 End of changes. 95 change blocks. 
190 lines changed or deleted 252 lines changed or added

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