| 6tisch Working Group | M. Richardson |
| Internet-Draft | Sandelman Software Works |
| Intended status: Informational | B. Damm |
| Expires: May 3, 2018 | Silver Spring Networks |
| October 30, 2017 |
6tisch Zero-Touch Secure Join protocol
draft-ietf-6tisch-dtsecurity-zerotouch-join-01
This document describes a zero-touch mechanism to enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch signaling mechanisms. The resulting device will obtain a domain 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 coordinator. The mechanism describe her is an augmentation to the one-touch mechanism described in [I-D.ietf-6tisch-minimal-security].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Enrollment of new nodes into LLNs present unique challenges. The constrained nodes has no user interfaces, and even if they did, configuring thousands of such nodes manually is undesireable from a human resources issue, as well as the difficulty in getting consistent results.
This document is about a standard way to introduce new nodes into a 6tisch network that does not involve any direct manipulation of the nodes themselves. This act has been called "zero-touch" provisioning, and it does not occur by chance, but requires coordination between the manufacturer of the node, the service operator running the LLN, and the installers actually taking the devices out of the shipping boxes.
This document is a constrained profile of [I-D.ietf-anima-bootstrapping-keyinfra]. The above document/protocol 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-polish ending.
This document follows the same structure as it's parent in order to emphasize the similarities, but specializes a number of things to constrained networks of constrained devices. Like ANIMA's BRSKI, the networks which are in scope for this protocol are deployed by a professional operator. The deterministic mechanisms which have been designed into 6tisch have been created to satisfy the operational needs of industrial settings.
This document builds upon the "one-touch" provisioning described in [I-D.ietf-6tisch-minimal-security], reusing the OSCOAP Join Request mechanism when appropriate. In addition, it uses the CoAP adaption of EST defined in [I-D.vanderstok-ace-coap-est] in an identical way.
Otherwise, this document follows BRSKI with the following high-level changes:
802.1AR Client certificates are retained, but optionally are specified by reference rather than value.
It is expected that the back-end network operator infrastructure would be able to bootstrap ANIMA BRSKI-type devices over ethernet, while also being able bootstrap 6tisch devices over 802.15.4 with few changes.
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant STuPiD implementations.
The reader is expected to be familiar with the terms and concepts defined in [I-D.ietf-6tisch-terminology], [RFC7252], [I-D.ietf-core-object-security], and [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are imported: drop ship, imprint, enrollment, pledge, join proxy, ownership voucher, join registrar/coordinator. The following terms are repeated here for readability, but this document is not authoritative for their definition:
The solution described in this document is appropriate to enrolling between hundreds to hundreds of thousands of diverse devices into a network without any prior contact with the devices. The devices could be shipped by the manufacturer directly to the customer site 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 by the first network that sees it. In the tracked owner mode of operation, sales channel integration provides a strong connection that the operator of the network is the legitimate owner of the 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.
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}.
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].
Section 2 of BRSKI has a diagram with all of the components shown together. There are no significant changes to the diagram.
The use of a circuit proxy is not mandated. Instead the IPIP mechanism described in appendix C ("IPIP Join Proxy mechanism") SHOULD be be used instead as it supports both DTLS, EDHOC and OSCOAP protocols.
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)
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:
As in BRSKI, the format and cryptographic mechansim of vouchers is described in detail in [I-D.ietf-anima-voucher]. As described in section YYY, the physical format for vouchers in this document differs from that of BRSKI, in that it uses [I-D.ietf-ace-cbor-web-token] to encode the voucher and to sign it.
The essential component of the zero-touch operation is that the pledge is provisioned with an 802.1AR (PKIX) certificate installed during the manufacturing process.
It is expected that constrained devices will use a signature algorithm corresponding to the hardware acceleration that they have, if they have any. The anticipated algorithms are the ECDSA P-256 (secp256p1) as SHOULD-, while newer devices SHOLD+ begin to appear using EdDSA curves using the 25519 curves. (EDNOTE details here)
There are a number of simplications detailed later on in this document designed to eliminate the need for an ASN.1 parser in the pledge.
The pledge should consider it's 802.1AR certificate to be an opaque 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 most useable native format for computation.
The pledge MUST have the public key of the MASA built in a manufacturer time. This is a seemingly identical requirement as for BRSKI, but rather than being an abstract trust anchor that can be 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 pledge.
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 operational suggestions.
BRSKI places some clear requirements upon the contents of the IDevID, but leaves the exact origin of the voucher serial-number open. This document restricts the process to being the hwSerialNum OCTET STRING. As CWT can handle binary formats, no base64 encoding is necessary.
The use of the MASA-URL extension is encouraged if the certificate is sent at all.
EDNOTE: here belongs text about sending only a reference to the IDevID rather than the entire certificate
The diagram from BRSKI is reproduced with some edits:
+--------+ +---------+ +------------+ +------------+
| Pledge | | IPIP | | Domain | | Vendor |
| | | Proxy | | Registrar | | Service |
| | | | | | | (Internet |
+--------+ +---------+ +------------+ +------------+
| | | |
|<-RFC4862 IPv6 adr | | |
| | | |
|<--------------------| | |
| Enhanced Beacon | | |
| periodic broadcast| | |
| | | |
|<------------------->C<----------------->| |
| DTLS via the IPIP Proxy | |
|<--Registrar DTLS server authentication--| |
[PROVISIONAL accept of server cert] | |
P---X.509 client authentication---------->| |
P | | |
P---Voucher Request (include nonce)------>| |
P | | |
P | | |
P | [accept device?] |
P | [contact Vendor] |
P | |--Pledge ID-------->|
P | |--Domain ID-------->|
P | |--nonce------------>|
P | | [extract DomainID]
P | | |
P | | [update audit log]
P | | |
P | | |
P | | |
P | | |
P | | |
P | |<-device audit log--|
P | |<- voucher ---------|
P | | |
P | | |
P | [verify audit log and voucher] |
P | | |
P<------voucher---------------------------| |
[verify voucher ] | | |
[verify provisional cert| | |
| | | |
|<--------------------------------------->| |
| Continue with RFC7030 enrollment | |
| using now bidirectionally authenticated | |
| DTLS session. | | |
| | | |
| | | |
| | | |
Noteable changes are:
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.
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).
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.
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.
For the constrained situation it is assumed that devices have no real time clock. These nodes do have access to a monotonically increasing clock that will not go backwards in the form of the Absolute Sequence Number. Synchronization to the ASN is required in order to transmit/receive data and most nodes will maintain it in hardware.
The heuristic described in BRSKI under this section SHOULD be applied if there are dates in the CWT format voucher.
Voucher requests SHOULD include a nonce. For devices intended for off-line deployment, the vouchers will have been generated in advance and no nonce-ful operation will not be possible.
In 6tisch, the pledge never has network connectivity until it is enrolled, so no alternate registrar is ever possible.
There are no changes from BRSKI: the IDevID provided by the pledge will contain a MASA URL extension.
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:
An appendix shows detailed examples of CWT format voucher requests.
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
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
/* -*- 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
The role of the Proxy is to facilitate communication. In the constrained situation the proxy needs to be stateless.
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.
In BRSKI CoAP is future work. This document represents this work.
HTTPS connections are not used.
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.
BRSKI is specified to run over HTTPS. This document respecifies it to run over CoAP with either DTLS or EDHOC-provided OSCOAP security. There is an emerging (hybrid) possibility of DTLS-providing the OSCOAP security, but such a specification does not yet exist.
[I-D.vanderstok-ace-coap-est] specifies that CoAP specifies the use of CoAP Block-Wise Transfer ("Block") [RFC7959] to fragment EST messages at the application layer.
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].
As in [I-D.vanderstok-ace-coap-est], support for Observe CoAP options [RFC7641] with BRSKI is not supported in the current BRSKI/EST message flows. Observe options could be used by the server to notify clients about a change in the cacerts or csr attributes (resources) and might be an area of future work.
Redirection as described in [RFC7030] section 3.2.1 is NOT supported.
Zerotouch Join does not use TLS. The connection is either CoAP over DTLS, or CoAP with EDHOC security.
The details in the BRSKI document apply directly to use of DTLS.
The registrar SHOULD authenticate itself with a raw public key.
The pledge SHOULD authenticate itself with the built-in IDevID certificate.
[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.
The voucher request and response as defined by BRSKI is modified slightly.
In order to simplify the pledge, the use of a certificate (and chain) for the Registrar is not supported. Instead the newly defined pinned-domain-subject-public-key-info must contain the (raw) public 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 document defines the voucher request to be unsigned.
There are no changes. The connection from the Registrar to MASA is still HTTPS.
There are no change from BRSKI, as this step is between two non-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 pledge, and will issue a 406 (Conflict) error to the Registrar if the Registar's public key format is not supported by the pledge.
The format of the voucher is CWT as described in section YYY.
The BRSKI process uses the pinned-domain-cert field of the voucher to validate the registrar's ServerCertificate. In the ZeroTouch case, 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.
The voucher status telemetry report is communicated from the pledge to the registrar over CoAP channel. The shortened URL is as described in table QQQ.
There are no changes to the MASA audit log request.
There are no changes to the MASA audit log response.
There.
TBD.
TBD.
TBD.
There are no changes to the status telemetry between Registrar and MASA.
This document and [I-D.vanderstok-ace-coap-est] detail how to run EST over CoAP.
TBD
TBD
TBD
TBD
TBD
XXX
XXX
## PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 46 ## Voucher Status Telemetry . . . . . . . . . . . . . . . . 47
TBD
TBD
[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.
The details of this are out of scope for this document.
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 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].
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).
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. Once connected, the long 8-byte EUI64 layer-2 address is usually replaced with a short JRC assigned 2-byte address.
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.
Even when TLS 1.3 is used, an active attacker could collect the information by creating a rogue proxy.
The use of a manufacturer assigned EUI64 (whether derived from IEEE assignment or created through another process during manufacturing time) is encouraged.
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.
TBD.
Kristofer Pister helped with many non-IETF references.
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].
This document interacts with the one-touch solution described in [I-D.ietf-6tisch-minimal-security].
When a manufacturer installed certificate is provided as the IDevID, it SHOULD contain a number of fields. [I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of requirements.
A manufacturer unique serial number MUST be provided in the serialNumber SubjectAltName extension, and MAY be repeated in the Common Name. There are no sequential or numeric requirements on the serialNumber, it may be any unique value that the manufacturer wants 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 traced to the relevant device.
The goal of the bootstrap process is to introduce one or more new locally relevant credentials:
This document is about enrollment of constrained devices [RFC7228] to a constrained network. Constrained networks is such as [ieee802154], and in particular the time-slotted, channel hopping (tsch) mode, feature low bandwidths, and limited opportunities to transmit. A key feature of these networks is that receivers are only listening at certain times.
802.15.4 networks have three kinds of layer-2 security:
Setting up the credentials to bootstrap one of these kinds of security, (or directly configuring the key itself for the first case) is required. This is the security below the IP layer.
Security is required above the IP layer: there are three aspects which the credentials in the previous section are to be used.
Perfert Forward Secrecy (PFS) is the property of a protocol such that complete knowledge of the crypto state (for instance, via a memory dump) at time X does not imply that data from a disjoint time Y can also be recovered. ([PFS]).
PFS is important for two reasons: one is that it offers protection against the compromise of a node. It does this by changing the keys in a non-deterministic way. This second property also makes it much easier to remove a node from the network, as any node which has not participated in the key changing process will find itself no longer connected.
The network which the new pledge will connect to will have to have the following properties:
TBD.
TBD
At the end of the zero-touch join process there will be a symmetric key protected channel between the Join Registrar/Coordinator and the pledge, now known as a Joined Node. This channel may be rekeyed via new exchange of asymmetric exponents (ECDH for instance), authenticated using the domain specific credentials created during the join process.
This channel is in the form of an OSCOAP protected connection with [I-D.ietf-core-comi] encoded objects. This document includes definition of a [I-D.ietf-netconf-keystore] compatible objects for encoding of the relevant [I-D.ietf-anima-bootstrapping-keyinfra] objects.
The pledge join protocol state machine is described in [I-D.ietf-6tisch-minimal-security], in section XYZ. The pledge recognizes that it is in zero-touch configuration by the following situation:
All of these conditions MUST be true. If any of these are not true, then the pledge has either been connected to the wrong network, or it has already been bootstrapped into a different network, and it should wait until it finds that network.
The zero-touch process consists of three stages:
The key agreement process is identical to [I-D.ietf-6tisch-minimal-security]. The process uses EDHOC with certificates.
The pledge will have to trust the JRC provisionally, as described in [I-D.ietf-anima-bootstrapping-keyinfra], section 3.1.2, and in section 4.1.1 of [RFC7030].
The JRC will be able to validate the IDevID of the pledge using the manufacturer's CA.
The pledge may not know if it is in a zero-touch or one-touch situation: the pledge may be able to verify the JRC based upon trust anchors that were installed at manufacturing time. In that case, the pledge runs the simplified one-touch process.
The pledge signals in the EDHOC message_2 if it has accepted the JRC certificate. The JRC will in general, not trust the pledge with the network keys until it has provided the pledge with a voucher. The pledge will notice the absence of the provisioning keys.
XXX - there could be some disconnect here. May need additional signals here.
When the pledge determines that it can not verify the certificate of the JRC using built-in trust anchors, then it enters a provisional state. In this state, it keeps the channel created by EDHOC open.
A new EDHOC key derivation is done by the JRC and pledge using a new label, "6tisch-provisional".
The pledge runs as a passive CoMI server, leaving the JRC to drive the enrollment process. The JRC can interrogate the pledge in a variety of fashions as shown below: the process terminates when the JRC provides the pledge with an ownership voucher and the pledge leaves the provisional state.
A typical interaction involves the following requests:
+-----------+ +----------+ +-----------+ +----------+
| | | | | Circuit | | New |
| Vendor | | Registrar| | Proxy | | Entity |
| (MASA) | | | | | | |
++----------+ +--+-------+ +-----------+ +----------+
| | GET request voucher |
| |-------------------------------->
| <----------voucher-token---------|
|/requestvoucher| |
<---------------+ |
+---------------> |
|/requestlog | |
<---------------+ |
+---------------> |
| | POST voucher |
| |-------------------------------->
| <------------2.05 OK ------------+
| | |
| | POST csr attributes |
| |-------------------------------->
| <------------2.05 OK ------------+
| | |
| | GET cert request |
| |-------------------------------->
| ???? <------------2.05 OK ------------+
|<--------------| CSR |
|-------------->| |
| | POST certificate |
| |-------------------------------->
| <------------2.05 OK ------------+
| | |
This document allocates one value from the subregistry "Address Registration Option Status Values": ND_NS_JOIN_DECLINED Join Assistant, JOIN DECLINED (TBD-AA)
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.
The Proxy is discovered using the enhanced beacon defined in [I-D.richardson-6tisch-join-enhanced-beacon].
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.