draft-ietf-6tisch-dtsecurity-zerotouch-join-00.txt   draft-ietf-6tisch-dtsecurity-zerotouch-join-01.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: March 1, 2018 Silver Spring Networks Expires: May 3, 2018 Silver Spring Networks
August 28, 2017 October 30, 2017
6tisch Zero-Touch Secure Join protocol 6tisch Zero-Touch Secure Join protocol
draft-ietf-6tisch-dtsecurity-zerotouch-join-00 draft-ietf-6tisch-dtsecurity-zerotouch-join-01
Abstract Abstract
This document describes a zero-touch mechanism to enroll a new device This document describes a zero-touch mechanism to enroll a new device
(the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch
signaling mechanisms. The resulting device will obtain a domain signaling mechanisms. The resulting device will obtain a domain
specific credential that can be used with either 802.15.9 per-host specific credential that can be used with either 802.15.9 per-host
pair keying protocols, or to obtain the network-wide key from a pair keying protocols, or to obtain the network-wide key from a
coordinator. The mechanism describe her is an augmentation to the coordinator. The mechanism describe her is an augmentation to the
one-touch mechanism described in [I-D.ietf-6tisch-minimal-security]. one-touch mechanism described in [I-D.ietf-6tisch-minimal-security].
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 http://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 March 1, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Other Bootstrapping Approaches . . . . . . . . . . . . . 6 1.2. Scope of solution . . . . . . . . . . . . . . . . . . . . 6
1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 6 1.3. Leveraging the new key infrastructure / next steps . . . 6
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 6 1.3.1. Key Distribution Process . . . . . . . . . . . . . . 7
2.1. Secure Imprinting using Vouchers . . . . . . . . . . . . 6 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 7
2.2. Initial Device Identifier . . . . . . . . . . . . . . . . 7 2.1. Behaviour of a Pledge . . . . . . . . . . . . . . . . . . 7
2.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 9
2.4. Lack of realtime clock . . . . . . . . . . . . . . . . . 9 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 9
2.5. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 9 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 10
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Architectural component: Pledge . . . . . . . . . . . 11
3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2. Architectural component: Stateless IPIP Proxy . . . . 12
3.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 10 2.4.3. Architectural component: Domain Registrar . . . . . . 12
3.1.2. Registrar Discovery Protocol Details . . . . . . . . 10 2.4.4. Architectural component: Vendor Service . . . . . . . 12
3.2. Pledge Requests Voucher from the Registrar . . . . . . . 10 2.5. Lack of realtime clock . . . . . . . . . . . . . . . . . 12
3.3. Registrar Requests Voucher from MASA . . . . . . . . . . 13 2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 13
3.4. Voucher Response . . . . . . . . . . . . . . . . . . . . 13 2.7. Determining the MASA to contact . . . . . . . . . . . . . 13
3.4.1. Completing authentication of Provisional TLS 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 13
connection . . . . . . . . . . . . . . . . . . . . . 13 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Voucher Status Telemetry . . . . . . . . . . . . . . . . 13 3.2. SID values . . . . . . . . . . . . . . . . . . . . . . . 13
3.6. MASA authorization log Request . . . . . . . . . . . . . 14 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14
3.6.1. MASA authorization log Response . . . . . . . . . . . 14 4. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7. EST Integration for PKI bootstrapping . . . . . . . . . . 14 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 16
3.7.1. EST Distribution of CA Certificates . . . . . . . . . 14 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 16
3.7.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 14 4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 16
3.7.3. EST Client Certificate Request . . . . . . . . . . . 14 4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 16
3.7.4. Enrollment Status Telemetry . . . . . . . . . . . . . 14 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 16
3.7.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 14 5.1. BRSKI-EST (D)TLS establishment details . . . . . . . . . 17
4. Reduced security operational modes . . . . . . . . . . . . . 14 5.1.1. BRSKI-EST CoAP/DTLS estasblishment details . . . . . 17
4.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details . . . . . 17
4.2. Pledge security reductions . . . . . . . . . . . . . . . 14 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 18
4.3. Registrar security reductions . . . . . . . . . . . . . . 15 5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 18
4.4. MASA security reductions . . . . . . . . . . . . . . . . 15 5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 18
5.1. MIME-Type Registry . . . . . . . . . . . . . . . . . . . 15 5.5.1. Completing authentication of Provisional TLS
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 connection . . . . . . . . . . . . . . . . . . . . . 18
6.1. Security of MASA voucher signing key(s) . . . . . . . . . 15 5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 18
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 5.7. MASA authorization log Request . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 5.7.1. MASA authorization log Response . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 19
5.8.3. EST Client Certificate Request . . . . . . . . . . . 19
Appendix A. One-Touch Assumptions . . . . . . . . . . . . . . . 20 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 19
A.1. Factory provided credentials (if any) . . . . . . . . . . 20 5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 19
A.1.1. Credentials to be introduced . . . . . . . . . . . . 21 6. Reduced security operational modes . . . . . . . . . . . . . 19
A.2. Network Assumptions . . . . . . . . . . . . . . . . . . . 21 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 19
A.2.1. Security above and below IP . . . . . . . . . . . . . 21 6.2. Pledge security reductions . . . . . . . . . . . . . . . 19
A.2.2. Join network assumptions . . . . . . . . . . . . . . 22 6.3. Registrar security reductions . . . . . . . . . . . . . . 20
A.2.3. Number and cost of round trips . . . . . . . . . . . 22 6.4. MASA security reductions . . . . . . . . . . . . . . . . 20
A.2.4. Size of packets, number of fragments . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
A.3. Target end-state for join process . . . . . . . . . . . . 22 7.1. MIME-Type Registry . . . . . . . . . . . . . . . . . . . 20
Appendix B. Join Protocol . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
B.1. Key Agreement process . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
B.2. Provisional Enrollment process . . . . . . . . . . . . . 24 9.1. Security of MASA voucher signing key(s) . . . . . . . . . 20
B.3. Key Distribution Process . . . . . . . . . . . . . . . . 25 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
Appendix C. YANG model for BRSKI objects . . . . . . . . . . . . 25 10.1. Privacy Considerations for Production network . . . . . 20
C.1. Description of Pledge States in Join Process . . . . . . 26 10.2. Privacy Considerations for New Pledges . . . . . . . . . 20
Appendix D. Definition of managed objects for zero-touch 10.2.1. EUI-64 derived address for join time IID . . . . . . 21
bootstrap . . . . . . . . . . . . . . . . . . . . . 26 10.3. Privacy Considerations for Join Proxy . . . . . . . . . 22
Appendix E. Privacy Considerations . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
E.1. Privacy Considerations for Production network . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
E.2. Privacy Considerations for New Pledges . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
E.2.1. EUI-64 derived address for join time IID . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 25
E.3. Privacy Considerations for Join Assistant . . . . . . . . 28 Appendix A. Extra text . . . . . . . . . . . . . . . . . . . . . 27
Appendix F. Security Considerations . . . . . . . . . . . . . . 28 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix G. IANA Considerations . . . . . . . . . . . . . . . . 28 A.1.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 27
Appendix H. Protocol Definition . . . . . . . . . . . . . . . . 28 A.1.2. Factory provided credentials (if any) . . . . . . . . 27
Appendix I. Acknowledgements . . . . . . . . . . . . . . . . . . 28 A.1.3. Credentials to be introduced . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 A.2. Network Assumptions . . . . . . . . . . . . . . . . . . . 28
A.2.1. Security above and below IP . . . . . . . . . . . . . 28
A.2.2. Join network assumptions . . . . . . . . . . . . . . 29
A.2.3. Number and cost of round trips . . . . . . . . . . . 29
A.2.4. Size of packets, number of fragments . . . . . . . . 29
A.3. Target end-state for join process . . . . . . . . . . . . 29
Appendix B. Join Protocol . . . . . . . . . . . . . . . . . . . 30
B.1. Key Agreement process . . . . . . . . . . . . . . . . . . 30
B.2. Provisional Enrollment process . . . . . . . . . . . . . 31
Appendix C. IANA Considerations . . . . . . . . . . . . . . . . 32
Appendix D. Protocol Definition . . . . . . . . . . . . . . . . 32
D.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 32
D.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 33
D.1.2. Registrar Discovery Protocol Details . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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 6, line 5 skipping to change at page 6, line 19
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. Other Bootstrapping Approaches 1.2. Scope of solution
BRSKI describes a more general, more flexible approach for
bootstrapping devices into an ISP or Enterprise network.
[I-D.ietf-6tisch-minimal-security] provides an extremely streamlined
approach to enrolling from hundreds to thousands of devices into a
network, provided that a unique secret key can be installed in each
device.
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
bootstrapping devices into an ISP or Enterprise network.
[I-D.ietf-6tisch-minimal-security] provides an extremely streamlined
approach to enrolling from hundreds to thousands of devices into a
network, provided that a unique secret key can be installed in each
device.
1.3. Leveraging the new key infrastructure / next steps
In constrained networks, it is unlikely that an ACP be formed. This
document does not preclude such a thing, but it is not mandated.
The resulting secure channel MAY be used just to distribute network-
wide keys using a protocol such as
[I-D.ietf-6tisch-minimal-security]. (XXX - do we need to signal this
somehow?)
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
per-pair keying such as described by {{ieee802159}.
1.3.1. Key Distribution Process
In addition to being used for the initial enrollment process, the
secure channel may be kept open (and reversed) to use for network
rekeying. Such a process is out of scope of this document, please
see future work such as [I-D.richardson-6tisch-minimal-rekey].
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. The CoAP proxy mechanism MAY be implemented instead: the protocols.
decision depends upon the capabilities of the Registrar and the
proxy. A mechanism is included for the Registrar to announce it's
capabilities (XXX).
2.1. Secure Imprinting using Vouchers The CoAP proxy mechanism MAY be implemented instead: the decision
depends upon the capabilities of the Registrar and the proxy. A
mechanism is included for the Registrar to announce it's capabilities
(XXX)
2.1. Behaviour of a Pledge
The pledge goes through a series of steps which are outlined here at
a high level.
+--------------+
| Factory |
| default |
+------+-------+
|
+------v-------+
| Discover |
+------------> |
| +------+-------+
| |
| +------v-------+
| | Identity |
^------------+ |
| rejected +------+-------+
| |
| +------v-------+
| | Request |
| | Join |
| +------+-------+
| |
| +------v-------+
| | Imprint | Optional
^------------+ <--+Manual input (Appendix C)
| Bad Vendor +------+-------+
| response | send Voucher Status Telemetry
| +------v-------+
| | Enroll |
^------------+ |
| Enroll +------+-------+
| Failure |
| +------v-------+
| | Enrolled |
^------------+ |
Factory +--------------+
reset
State descriptions for the pledge are as follows:
1. Discover a communication channel to a Registrar. This is done by
listening for beacons as described by
[I-D.richardson-anima-6join-discovery]
2. Identify itself. This is done by presenting an X.509 IDevID
credential to the discovered Registrar (via the Proxy) in a DTLS
or EDHOC handshake. (The Registrar credentials are only
provisionally accepted at this time).
The registrar identifies itself using a raw public key, while the
the pledge identifies itself to the registrar using an IDevID
credential.
3. Requests to Join the discovered Registrar. A unique nonce can be
included ensuring that any responses can be associated with this
particular bootstrapping attempt.
4. Imprint on the Registrar. This requires verification of the
vendor service (MASA) provided voucher. A voucher contains
sufficient information for the Pledge to complete authentication
of a Registrar. The voucher is signed by the vendor (MASA) using
a raw public key, previously installed into the pledge at
manufacturing time.
5. Optionally Enroll. By accepting the domain specific information
from a Registrar, and by obtaining a domain certificate from a
Registrar using a standard enrollment protocol, e.g. Enrollment
over Secure Transport (EST) [RFC7030].
6. The Pledge is now a member of, and can be managed by, the domain
and will only repeat the discovery aspects of bootstrapping if it
is returned to factory default settings.
2.2. Secure Imprinting using Vouchers
As in BRSKI, the format and cryptographic mechansim of vouchers is As in BRSKI, the format and cryptographic mechansim of vouchers is
described in detail in [I-D.ietf-anima-voucher]. As described in described in detail in [I-D.ietf-anima-voucher]. As described in
section YYY, the physical format for vouchers in this document section YYY, the physical format for vouchers in this document
differs from that of BRSKI, in that it uses differs from that of BRSKI, in that it uses
[I-D.ietf-ace-cbor-web-token] to encode the voucher and to sign it. [I-D.ietf-ace-cbor-web-token] to encode the voucher and to sign it.
2.2. 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) as SHOULD-, while newer devices SHOLD+ begin to appear
using EdDSA curves using the 25519 curves. (EDNOTE details here) using EdDSA curves using the 25519 curves. (EDNOTE details here)
skipping to change at page 7, line 34 skipping to change at page 10, line 18
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 6.1 addresses some of them with some signing key, and section Section 9.1 addresses some of them with some
operational suggestions. 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
IDevID rather than the entire certificate]] IDevID rather than the entire certificate
2.3. 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 | | | | | | | | (Internet |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| | | | | | | |
|<-RFC4862 IPv6 adr | | | |<-RFC4862 IPv6 adr | | |
skipping to change at page 9, line 15 skipping to change at page 11, line 47
| | | | | | | |
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 recommended
2.4. Lack of realtime clock 2.4.1. Architectural component: Pledge
The Pledge is the device which is attempting to join. Until the
pledge completes the enrollment process, it has network connectivity
only to the Proxy.
2.4.2. Architectural component: Stateless IPIP Proxy
The stateless CoAP or DTLS Proxy provides CoAP or DTLS connectivity
(respectively) between the pledge and the registrar. The stateless
CoAP proxy mechanism is described in
[I-D.ietf-6tisch-minimal-security] section 5.1. The stateless DTLS
mechanism is not yet described (XXX).
2.4.3. Architectural component: Domain Registrar
The Domain Registrar (having the formal name Join Registrar/
Coordinator (JRC)), operates as a CMC Registrar, terminating the EST
and BRSKI connections. The Registrar is manually configured or
distributed with a list of trust anchors necessary to authenticate
any Pledge device expected on the network. The Registrar
communicates with the Vendor supplied MASA to establish ownership.
The JRC is typically located on the 6LBR/DODAG root, but it may be
located elsewhere, provided IP level connectivity can be established.
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
existence of such an additional proxy is a private matter, and this
documents assumes without loss of generality that the registrar is
co-located with the 6LBR.
2.4.4. Architectural component: Vendor Service
The Vendor Service provides two logically seperate functions: the
Manufacturer Authorized Signing Authority (MASA), and an ownership
tracking/auditing function. This function is identical to that used
by BRSKI, except that a different format voucher is used.
2.5. 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.5. Cloud Registrar 2.6. 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.
3. Protocol Details 2.7. Determining the MASA to contact
There are no changes from BRSKI: the IDevID provided by the pledge
will contain a MASA URL extension.
3. Voucher-Request artifact
As in BRSKI, a voucher-request artifact is derived from the base
voucher definition. 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 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
[I-D.ietf-core-yang-cbor] uses the
4. Proxy details
The role of the Proxy is to facilitate communication. In the
constrained situation the proxy needs to be stateless.
4.1. Pledge discovery of Proxy
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
the proxy is related by the Enhanced Beacon.
4.2. CoAP connection to Registrar
In BRSKI CoAP is future work. This document represents this work.
4.3. HTTPS proxy connection to Registrar
HTTPS connections are not used.
4.4. Proxy discovery of Registrar
In BRSKI, the proxy autonomically discovers the Registrar by
listening for GRASP messages. In the constrained network, the
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
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.
[I-D.vanderstok-ace-coap-est] specifies that CoAP specifies the use [I-D.vanderstok-ace-coap-est] specifies that CoAP specifies the use
of CoAP Block-Wise Transfer ("Block") [RFC7959] to fragment EST of CoAP Block-Wise Transfer ("Block") [RFC7959] to fragment EST
messages at the application layer. messages at the application layer.
skipping to change at page 10, line 15 skipping to change at page 17, line 26
described in [RFC5056]. described in [RFC5056].
As in [I-D.vanderstok-ace-coap-est], support for Observe CoAP options As in [I-D.vanderstok-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. Observe options could be used by the server to notify
clients about a change in the cacerts or csr attributes (resources) clients about a change in the cacerts or csr attributes (resources)
and might be an area of future work. 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.
3.1. Discovery 5.1. BRSKI-EST (D)TLS establishment details
Only IPv6 operations using Link-Local addresses are supported. Use Zerotouch Join does not use TLS. The connection is either CoAP over
of a temporary address is NOT encouraged as the critial resource on DTLS, or CoAP with EDHOC security.
the Proxy device is the number of Neighbour Cache Entries that can be
used for untrusted pledge entries.
3.1.1. Proxy Discovery Protocol Details 5.1.1. BRSKI-EST CoAP/DTLS estasblishment details
The Proxy is discovered using the enhanced beacon defined in The details in the BRSKI document apply directly to use of DTLS.
[I-D.richardson-6tisch-join-enhanced-beacon].
3.1.2. Registrar Discovery Protocol Details The registrar SHOULD authenticate itself with a raw public key.
The Registrar is not discovered by the Proxy. Any device that is The pledge SHOULD authenticate itself with the built-in IDevID
expected to be able to operate as a Registrar MAY be told the address certificate.
of the Registrar when that device joins the network. The address MAY
be included in the [I-D.ietf-6tisch-minimal-security] Join Response.
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
6tisch's use of the RPL protocol.
3.2. Pledge Requests Voucher from the Registrar 5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details
[I-D.ietf-6tisch-minimal-security] section YYY details how to setup
EDHOC.
The registrar SHOULD authenticate itself with a raw public key.
The pledge SHOULD authenticate itself with the built-in IDevID
certificate.
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. In order to simplify the pledge, the use of a certificate slightly.
(and chain) for the Registrar is not supported. Instead the newly
defined pinned-domain-subject-public-key-info must contain the (raw) In order to simplify the pledge, the use of a certificate (and chain)
public key info for the Registrar. It MUST be byte for byte for the Registrar is not supported. Instead the newly defined
identical to that which is transmitted by the Registrar during the pinned-domain-subject-public-key-info must contain the (raw) public
TLS ServerCertificate handshake. key info for the Registrar. It MUST be byte for byte identical to
that which is transmitted by the Registrar during the TLS
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.
/* -*- c -*- */ 5.3. BRSKI-MASA TLS establishment details
module ietf-cwt-voucher {
yang-version 1.1;
namespace There are no changes. The connection from the Registrar to MASA is
"urn:ietf:params:xml:ns:yang:ietf-cwt-voucher"; still HTTPS.
prefix "vcwt";
import ietf-restconf { 5.4. Registrar Requests Voucher from MASA
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 { There are no change from BRSKI, as this step is between two non-
prefix "v"; constrained devices. The format of the voucher is CWT, which implies
} changes to both the Registrar and the MASA, but semantically the
content is the same.
organization The manufacturer will know what algorithms are supported by the
"IETF 6tisch Working Group"; pledge, and will issue a 406 (Conflict) error to the Registrar if the
Registar's public key format is not supported by the pledge.
contact 5.5. Voucher Response
"WG Web: <http://tools.ietf.org/wg/6tisch/>
WG List: <mailto:6tisch@ietf.org>
Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>";
description The format of the voucher is CWT as described in section YYY.
"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 5.5.1. Completing authentication of Provisional TLS connection
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', The BRSKI process uses the pinned-domain-cert field of the voucher to
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in validate the registrar's ServerCertificate. In the ZeroTouch case,
the module text are to be interpreted as described in RFC 2119."; the voucher will contain a pinned-domain-subject-public-key-info
field containing the raw public key of the certificate. It should
match, byte-to-byte with the raw public key ServerCertificate.
revision "YYYY-MM-DD" { 5.6. Voucher Status Telemetry
description
"Initial version";
reference
"RFC XXXX: Voucher Profile for Constrained Devices";
}
// Grouping defined for future usage The voucher status telemetry report is communicated from the pledge
grouping voucher-cwt-grouping { to the registrar over CoAP channel. The shortened URL is as
description described in table QQQ.
"Grouping to allow reuse/extensions in future work.";
uses v:voucher-artifact-grouping { 5.7. MASA authorization log Request
augment "voucher" {
description "Base the CWT voucher upon the regular one";
leaf pinned-domain-subject-public-key-info {
type binary;
description
"The pinned-domain-subject replaces the
pinned-domain-certificate in constrained uses of
the voucher. The pinned-domain-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 There are no changes to the MASA audit log request.
[I-D.ietf-core-yang-cbor] produces the following CDDL for an unsigned
voucher (request):
This is a PLACEHOLDER for a CDDL definition derived from the YANG model. 5.7.1. MASA authorization log Response
SID experimental base 60100 is used.
dictionary keys are: There are no changes to the MASA audit log response.
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
3.3. Registrar Requests Voucher from MASA 5.8. EST Integration for PKI bootstrapping
There are no change from BRSKI, as this step is between two non- There.
constrained devices. The format of the voucher is CWT, 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 5.8.1. EST Distribution of CA Certificates
pledge, and will issue a 406 (Conflict) error to the Registrar if the
Registar's public key format is not supported by the pledge.
3.4. Voucher Response TBD.
The voucher response MUST have an additional header called: "pinned- 5.8.2. EST CSR Attributes
domain-rpk".
3.4.1. Completing authentication of Provisional TLS connection TBD.
In order to simplify the pledge as much as possible, the voucher 5.8.3. EST Client Certificate Request
response
3.5. Voucher Status Telemetry TBD.
XXX 5.8.4. Enrollment Status Telemetry
3.6. MASA authorization log Request There are no changes to the status telemetry between Registrar and
MASA.
XXX 5.8.5. EST over CoAP
3.6.1. MASA authorization log Response This document and [I-D.vanderstok-ace-coap-est] detail how to run EST
over CoAP.
XXX 6. Reduced security operational modes
3.7. EST Integration for PKI bootstrapping TBD
XXX 6.1. Trust Model
3.7.1. EST Distribution of CA Certificates TBD
XXX 6.2. Pledge security reductions
3.7.2. EST CSR Attributes TBD
XXX 6.3. Registrar security reductions
3.7.3. EST Client Certificate Request TBD
XXX 6.4. MASA security reductions
3.7.4. Enrollment Status Telemetry TBD
7. IANA Considerations
XXX XXX
3.7.5. EST over CoAP 7.1. MIME-Type Registry
XXX XXX
4. Reduced security operational modes 8. IANA Considerations
XXX ## PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 46 ##
Voucher Status Telemetry . . . . . . . . . . . . . . . . 47
4.1. Trust Model 9. Security Considerations
XXX TBD
4.2. Pledge security reductions 9.1. Security of MASA voucher signing key(s)
XXX TBD
4.3. Registrar security reductions 10. Privacy Considerations
XXX [I-D.ietf-6lo-privacy-considerations] details a number of privacy
considerations important in Resource Constrained nodes. There are
two networks and three sets of constrained nodes to consider. They
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.
3. the production nodes which are also acting as proxy nodes.
4.4. MASA security reductions 10.1. Privacy Considerations for Production network
XXX The details of this are out of scope for this document.
5. IANA Considerations 10.2. Privacy Considerations for New Pledges
XXX New Pledges do not yet receive Router Advertisements with PIO
options, and so configure link-local addresses only based upon
layer-2 addresses using the normal SLAAC mechanisms described in
[RFC4191].
5.1. MIME-Type Registry These link-local addresses are visible to any on-link eavesdropper
(who is synchronized to the same Join Assistant), so regardless of
what is chosen they can be seen. This link-layer traffic is
encapsulated by the Join Proxy into IPIP packets and carried to the
JRC. The traffic SHOULD never leave the operator's network, will be
kept confidential by the layer-2 keys inside the LLN. As no outside
traffic can enter the join network, to do any ICMP scanning as
described in [I-D.ietf-6lo-privacy-considerations].
XXX The join process described herein requires that some identifier
meaningful to the network operator be communicated to the JRC. The
join request with this object occurs within a secured CoAP channel,
although the link-local address configured by the pledge will be
visible in either the CoAP stateless proxy option (section 5.1 of
[I-D.ietf-6tisch-minimal-security]), or in the equivalent DTLS
stateless proxy option (reference TBD).
6. Security Considerations This need not be a manufacturer created EUI-64 as assigned by IEEE;
it could be another value with higher entropy and less interesting
vendor/device information. Regardless of what is chosen, it can be
used to track where the device attaches.
6.1. Security of MASA voucher signing key(s) For most constrained device, network attachment occurs very
infrequently, often only once in their lifetime, so tracking
opportunities may be rare. Once connected, the long 8-byte EUI64
layer-2 address is usually replaced with a short JRC assigned 2-byte
address.
7. Privacy Considerations Additionally, during the enrollment process, a DTLS connection or
EDHOC connection will be created. TLS1.3 will keep contents of the
certificates transmitted private while TLS 1.2 will not. If the
client certificate can be observed, then the device identity will be
visible to passive observers in the 802.11AR IDevID certificate that
is sent.
XXX Even when TLS 1.3 is used, an active attacker could collect the
information by creating a rogue proxy.
8. Acknowledgements The use of a manufacturer assigned EUI64 (whether derived from IEEE
assignment or created through another process during manufacturing
time) is encouraged.
9. References 10.2.1. EUI-64 derived address for join time IID
9.1. Normative References 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,
the device SHOULD be assigned a unique randomly generated long
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
content is encrypted by the layer-2 key.
10.3. Privacy Considerations for Join Proxy
TBD.
11. Acknowledgements
Kristofer Pister helped with many non-IETF references.
12. 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-03 (work in progress), June 2017. 6tisch-minimal-security-04 (work in progress), October
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 "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-09 (work in 802.15.4e", draft-ietf-6tisch-terminology-09 (work in
progress), June 2017. progress), June 2017.
[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-08 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-09
(work in progress), August 2017. (work in progress), October 2017.
[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-07 (work in progress), July 2017. keyinfra-08 (work in progress), October 2017.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[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-05 (work in progress), August 2017. anima-voucher-06 (work in progress), October 2017.
[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-01 (work in
progress), July 2017. progress), July 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 of CoAP (OSCOAP)", draft-ietf-core- "Object Security for Constrained RESTful Environments
object-security-04 (work in progress), July 2017. (OSCORE)", draft-ietf-core-object-security-06 (work in
progress), October 2017.
[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-05 (work in progress), August
2017. 2017.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "Keystore Model", draft-ietf-netconf- Watsen, K., "Keystore Model", draft-ietf-netconf-
keystore-02 (work in progress), June 2017. keystore-02 (work in progress), June 2017.
skipping to change at page 17, line 38 skipping to change at page 24, line 23
cose-ecdhe-07 (work in progress), July 2017. cose-ecdhe-07 (work in progress), July 2017.
[I-D.vanderstok-ace-coap-est] [I-D.vanderstok-ace-coap-est]
Kumar, S., Stok, P., Kampanakis, P., Furuhed, M., and S. Kumar, S., Stok, P., Kampanakis, P., Furuhed, M., and S.
Raza, "EST over secure CoAP (EST-coaps)", draft- Raza, "EST over secure CoAP (EST-coaps)", draft-
vanderstok-ace-coap-est-02 (work in progress), June 2017. 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, <https://webstore.iec.ch/ WirelessHART", 2016,
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/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[ieee802154] [ieee802154]
IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low- IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low-
Rate Wireless Personal Area Networks (WPANs)", 2015, Rate Wireless Personal Area Networks (WPANs)", 2015,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
skipping to change at page 18, line 14 skipping to change at page 24, line 46
[ieee802159] [ieee802159]
IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft
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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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, <https://www.rfc- DOI 10.17487/RFC7030, October 2013,
editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, <https://www.rfc- DOI 10.17487/RFC7217, April 2014,
editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, <https://www.rfc- DOI 10.17487/RFC7228, May 2014,
editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[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, <https://www.rfc- DOI 10.17487/RFC7252, June 2014,
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, <https://www.rfc- DOI 10.17487/RFC7959, August 2016,
editor.org/info/rfc7959>. <https://www.rfc-editor.org/info/rfc7959>.
9.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/papers/1999-StajanoAnd- <https://www.cl.cam.ac.uk/~fms27/
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-05 (work in
progress), March 2017. progress), March 2017.
[I-D.ietf-core-sid] [I-D.ietf-core-sid]
Veillette, M., Pelov, A., Turner, R., Minaburo, A., and A. Veillette, M., Pelov, A., Turner, R., Minaburo, A., and A.
Somaraju, "YANG Schema Item iDentifier (SID)", draft-ietf- Somaraju, "YANG Schema Item iDentifier (SID)", draft-ietf-
core-sid-01 (work in progress), May 2017. core-sid-01 (work in progress), May 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-16 (work in progress), July 2017. useofrplinfo-19 (work in progress), October 2017.
[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] 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, <https://www.rfc- DOI 10.17487/RFC4655, August 2006,
editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<https://www.rfc-editor.org/info/rfc5056>. <https://www.rfc-editor.org/info/rfc5056>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, <https://www.rfc- DOI 10.17487/RFC7554, May 2015,
editor.org/info/rfc7554>. <https://www.rfc-editor.org/info/rfc7554>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, <https://www.rfc- DOI 10.17487/RFC7641, September 2015,
editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
February 2016, <https://www.rfc-editor.org/info/rfc7731>. February 2016, <https://www.rfc-editor.org/info/rfc7731>.
9.3. URIs Appendix A. Extra text
[2] mailto:6tisch@ietf.org The following text is from previous versions of this document. The
document has been re-organized to match the flow of
[I-D.ietf-anima-bootstrapping-keyinfra].
[3] mailto:mcr+ietf@sandelman.ca A.1. Assumptions
Appendix A. One-Touch Assumptions A.1.1. One-Touch Assumptions
This document interacts with the one-touch solution described in This document interacts with the one-touch solution described in
[I-D.ietf-6tisch-minimal-security]. [I-D.ietf-6tisch-minimal-security].
A.1. Factory provided credentials (if any) A.1.2. Factory provided credentials (if any)
When a manufacturer installed certificate is provided as the IDevID, When a manufacturer installed certificate is provided as the IDevID,
it SHOULD contain a number of fields. it SHOULD contain a number of fields.
[I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of [I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of
requirements. requirements.
A manufacturer unique serial number MUST be provided in the A manufacturer unique serial number MUST be provided in the
serialNumber SubjectAltName extension, and MAY be repeated in the serialNumber SubjectAltName extension, and MAY be repeated in the
Common Name. There are no sequential or numeric requirements on the Common Name. There are no sequential or numeric requirements on the
serialNumber, it may be any unique value that the manufacturer wants serialNumber, it may be any unique value that the manufacturer wants
to use. The serialNumber SHOULD be printed on the packaging and/or to use. The serialNumber SHOULD be printed on the packaging and/or
on the device in a discrete way so that failures can be physically on the device in a discrete way so that failures can be physically
traced to the relevant device. traced to the relevant device.
A.1.1. Credentials to be introduced A.1.3. Credentials to be introduced
The goal of the bootstrap process is to introduce one or more new The goal of the bootstrap process is to introduce one or more new
locally relevant credentials: locally relevant credentials:
1. a certificate signed by a local certificate authority/registrar. 1. a certificate signed by a local certificate authority/registrar.
This is the LDevID of [ieee802-1AR]. This is the LDevID of [ieee802-1AR].
2. alternatively, a network-wide key to be used to secure L2 2. alternatively, a network-wide key to be used to secure L2
traffic. traffic.
skipping to change at page 22, line 44 skipping to change at page 29, line 32
o a minimal schedule with some Aloha time. This is usually in the o a minimal schedule with some Aloha time. This is usually in the
same slotframe as the Enhanced Beacon, but a pledge MUST listen same slotframe as the Enhanced Beacon, but a pledge MUST listen
for an unencrypted Enhanced Beacon to so that it can synchronize. for an unencrypted Enhanced Beacon to so that it can synchronize.
A.2.3. Number and cost of round trips A.2.3. Number and cost of round trips
TBD. TBD.
A.2.4. Size of packets, number of fragments A.2.4. Size of packets, number of fragments
TBD
A.3. Target end-state for join process A.3. Target end-state for join process
At the end of the zero-touch join process there will be a symmetric At the end of the zero-touch join process there will be a symmetric
key protected channel between the Join Registrar/Coordinator and the key protected channel between the Join Registrar/Coordinator and the
pledge, now known as a Joined Node. This channel may be rekeyed via pledge, now known as a Joined Node. This channel may be rekeyed via
new exchange of asymmetric exponents (ECDH for instance), new exchange of asymmetric exponents (ECDH for instance),
authenticated using the domain specific credentials created during authenticated using the domain specific credentials created during
the join process. the join process.
This channel is in the form of an OSCOAP protected connection with This channel is in the form of an OSCOAP protected connection with
skipping to change at page 25, line 37 skipping to change at page 32, line 37
| | GET cert request | | | GET cert request |
| |--------------------------------> | |-------------------------------->
| ???? <------------2.05 OK ------------+ | ???? <------------2.05 OK ------------+
|<--------------| CSR | |<--------------| CSR |
|-------------->| | |-------------->| |
| | POST certificate | | | POST certificate |
| |--------------------------------> | |-------------------------------->
| <------------2.05 OK ------------+ | <------------2.05 OK ------------+
| | | | | |
B.3. Key Distribution Process Appendix C. IANA Considerations
The key distribution process utilizes the protocol described
[I-D.richardson-6tisch-minimal-rekey]. The process starts with the
initial key, rather than an actual rekey.
This protocol remains active for subsequent rekey operations.
Appendix C. YANG model for BRSKI objects
module ietf-6tisch-brski { yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:6tisch-brski"; prefix
"ietf6brski";
//import ietf-yang-types { prefix yang; } //import ietf-inet-types {
prefix inet; }
organization "IETF 6tisch Working Group";
contact "WG Web: http://tools.ietf.org/wg/6tisch/ WG List:
6tisch@ietf.org [2] Author: Michael Richardson mcr+ietf@sandelman.ca
[3]";
description "This module defines an interface to set and retrieve
BRSKI objects using CoMI. This interface is used as part of an
enrollment process for constrained nodes and networks.";
revision "2017-03-01" { description "Initial version"; reference "RFC
XXXX: 6tisch zero-touch bootstrap"; }
// top-level container container ietf6brski { leaf requestnonce {
type binary; length XX; // how big can/should it be? mandatory true;
description "Request Nonce."; } leaf voucher { type binary;
description "The voucher as a serialized COSE object"; }
leaf csrattributes {
type binary;
description "A list of attributes that MUST be in the CSR";
}
leaf certificaterequest {
type binary;
description "A PKIX format Certificate Request";
}
leaf certificate {
type binary;
description "The LDevID certificate";
} } }
C.1. Description of Pledge States in Join Process
TBD
Appendix D. Definition of managed objects for zero-touch bootstrap
The following is relevant YANG for use in the bootstrap protocol.
The objects identified are identical in format to the named objects
from [I-D.ietf-anima-bootstrapping-keyinfra].
Appendix E. Privacy Considerations
[I-D.ietf-6lo-privacy-considerations] details a number of privacy
considerations important in Resource Constrained nodes. There are
two networks and three sets of constrained nodes to consider. They
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.
3. the production nodes which are also acting as proxy nodes.
E.1. Privacy Considerations for Production network
The details of this are out of scope for this document.
E.2. Privacy Considerations for New Pledges
New Pledges do not yet receive Router Advertisements with PIO
options, and so configure link-local addresses only based upon
layer-2 addresses using the normal SLAAC mechanisms described in
[RFC4191].
These link-local addresses are visible to any on-link eavesdropper
(who is synchronized to the same Join Assistant), so regardless of
what is chosen they can be seen. This link-layer traffic is
encapsulated by the Join Assistant into IPIP packets and carried to
the JCE. The traffic SHOULD never leave the operator's network, and
no outside traffic should enter, so it should not be possible to do
any ICMP scanning as described in
[I-D.ietf-6lo-privacy-considerations].
The join process described herein requires that some identifier
meaningful to the network operator be communicated to the JCE via the
Neighbor Advertisement's ARO option. This need not be a manufacturer
created EUI-64 as assigned by IEEE; it could be another value with
higher entropy and less interesting vendor/device information.
Regardless of what is chosen, it can be used to track where the
device attaches.
For most constrained device, network attachment occurs very
infrequently, often only once in their lifetime, so tracking
opportunities may be rare.
Further, during the enrollment process, a DTLS connection connection
will be created. Unless TLS1.3 is used, the device identity will be
visible to passive observers in the 802.11AR IDevID certificate that
is sent. Even when TLS1.3 is used, an active attacker could collect
the information by simply connecting to the device; it would not have
to successful complete the negotiation either, or even attempt to
Man-In-The-Middle the device.
There is, at the same time, significant value in avoiding a link-
local DAD process by using an IEEE assigned EUI-64, and there is also
significant advantage to the operator being able to see what the
vendor of the new device is.
E.2.1. EUI-64 derived address for join time IID
It is therefore suggested that the IID used in the link-local address This document allocates one value from the subregistry "Address
used during the join process be a vendor assigned EUI-64. After the Registration Option Status Values": ND_NS_JOIN_DECLINED Join
join process has concluded, the device SHOULD be assigned a unique Assistant, JOIN DECLINED (TBD-AA)
randomly generated long address, and a unique short address (not
based upon the vendor EUI-64) for use at link-layer. At that point,
all layer-3 content is encrypted by the layer-2 key.
E.3. Privacy Considerations for Join Assistant Appendix D. Protocol Definition
Appendix F. Security Considerations D.1. Discovery
Appendix G. IANA Considerations Only IPv6 operations using Link-Local addresses are supported. Use
of a temporary address is NOT encouraged as the critial resource on
the Proxy device is the number of Neighbour Cache Entries that can be
used for untrusted pledge entries.
This document allocates one value from the subregistry "Address D.1.1. Proxy Discovery Protocol Details
Registration Option Status Values": ND_NS_JOIN_DECLINED Join
Assistant, JOIN DECLINED (TBD-AA)
Appendix H. Protocol Definition The Proxy is discovered using the enhanced beacon defined in
[I-D.richardson-6tisch-join-enhanced-beacon].
Appendix I. Acknowledgements D.1.2. Registrar Discovery Protocol Details
Kristofer Pister helped with many non-IETF references. 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
of the Registrar when that device joins the network. The address MAY
be included in the [I-D.ietf-6tisch-minimal-security] Join Response.
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
6tisch's use of the RPL protocol.
Authors' Addresses Authors' Addresses
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
Benjamin Damm Benjamin Damm
Silver Spring Networks Silver Spring Networks
 End of changes. 118 change blocks. 
425 lines changed or deleted 638 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/