6TiSCH Working Group                                     M. Vucinic, Ed.
Internet-Draft                                                     Inria                                  University of Montenegro
Intended status: Standards Track                                J. Simon
Expires: December 17, 2017                             Linear Technology May 3, 2018                                      Analog Devices
                                                               K. Pister
                                       University of California Berkeley
                                                           M. Richardson
                                                Sandelman Software Works
                                                           June 15,
                                                        October 30, 2017

                 Minimal Security Framework for 6TiSCH


   This document describes the minimal mechanisms configuration required to support
   secure enrollment of a pledge, for a device being added new
   device, called "pledge", to an IPv6 securely join a 6TiSCH (IPv6 over the
   TSCH mode of IEEE 802.15.4e (6TiSCH) 802.15.4e) network.  It assumes  The entities involved use CoAP
   (Constrained Application Protocol) and OSCORE (Object Security for
   Constrained RESTful Environments).  The configuration requires that
   the pledge has been provisioned with and the JRC (join registrar/coordinator, a credential that central
   entity), share a symmetric key.  How this key is relevant to
   the deployment - the "one-touch" scenario.  The goal provisioned is out
   of scope of this
   configuration document.  The result of the joining process is to set that
   the JRC configures the pledge with link-layer keys, keying material and to establish a secure
   end-to-end session between each pledge and the join registrar who may
   use that to further configure the pledge.
   short link-layer address.  This specification also defines a new
   Stateless-Proxy CoAP option.  Additional security
   behaviors and mechanisms may be
   added on top of this minimal framework.

Status of This Memo

   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 http://datatracker.ietf.org/drafts/current/. 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 December 17, 2017. May 3, 2018.

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  One-Touch Assumptions Assumption  . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Pre-Shared Key  . . . . . . . . . . . . . . . . . . . . .   4
   4.  Join Overview . . . . . . . . . . . . . . . . . . . . . . . .   4   5
     4.1.  Step 1 - Enhanced Beacon  . . . . . . . . . . . . . . . .   5   6
     4.2.  Step 2 - Neighbor Discovery . . . . . . . . . . . . . . .   6   7
     4.3.  Step 3 - Security Handshake Join Request . . . . . . . . . . . . . . .   6 . . .   7
     4.4.  Step 4 - Simple Join Protocol - Join Request Response  . . . . . . . . . . .   8
     4.5.  Step 5 - Simple Join Protocol - Join Response . . . . . .   8
   5.  Architectural Overview and Communication through Join Proxy .   9   8
     5.1.  Stateless-Proxy CoAP Option . . . . . . . . . . . . . . .   9
   6.  OSCORE Security Handshake  . . Context . . . . . . . . . . . . . . . . . . .  10
   7.  Simple Join Protocol Specification
     6.1.  Persistency . . . . . . . . . . . . .  11
     7.1.  OSCOAP Security Context Instantiation . . . . . . . . . .  12
     7.2.  11
   7.  Specification of Join Request . . . . . . . . . . . . . .  13
     7.3. . .  11
   8.  Specification of Join Response  . . . . . . . . . . . . .  13
   8.  Mandatory to Implement Algorithms and Certificate Format . .  15
   9.  11
     8.1.  Link-layer Requirements Keys Transported in COSE Key Set . . . . . . .  12
     8.2.  Short Address . . . . . . . . . . . .  15
   10. Rekeying and Rejoin . . . . . . . . . .  12
   9.  Error Handling and Retransmission . . . . . . . . . . .  16
   11. Key Derivations . . .  13
   10. Parameters  . . . . . . . . . . . . . . . . . . . .  16
   12. Security Considerations . . . . .  14
   11. Mandatory to Implement Algorithms . . . . . . . . . . . . . .  16
   13. Privacy Considerations  14
   12. Link-layer Requirements . . . . . . . . . . . . . . . . . . .  17
   14. IANA  14
   13. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . .  15
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  16
   16. IANA Considerations . .  18
     14.1. . . . . . . . . . . . . . . . . . . .  16
     16.1.  CoAP Option Numbers Registry . . . . . . . . . . . . . .  18
   15.  16
   17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   16.  17
   18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     16.1.  17
     18.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     16.2.  17
     18.2.  Informative References . . . . . . . . . . . . . . . . .  19  18
   Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .  21  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23  22

1.  Introduction

   This document describes presumes a 6TiSCH network as described by [RFC7554],
   [RFC8180], [I-D.ietf-6tisch-6top-protocol], and
   [I-D.ietf-6tisch-terminology].  By design, nodes in a 6TiSCH network
   [RFC7554] have their radio turned off most of the minimal feature set for time, to conserve
   energy.  As a consequence, the link used by a new device,
   termed pledge, to securely device for joining
   the network has limited bandwidth [RFC8180].  The secure join
   solution defined in this document therefore keeps the number of over-
   the-air exchanges for join purposes to a minimum.

   The micro-controllers at the heart of 6TiSCH network.  As nodes have a successful
   outcome small
   amount of this process, the pledge code memory.  It is able therefore paramount to securely communicate
   with its neighbors, participate in the routing structure reuse existing
   protocols available as part of the
   network or establish 6TiSCH stack.  At the application
   layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web
   transfer, and on OSCORE [I-D.ietf-core-object-security] for its end-
   to-end security.  The secure join solution defined in this document
   therefore reuses those two protocols as its building blocks.

   This document defines a secure session with an Internet host.

   When join solution for a pledge seeks admission new device, called
   "pledge", to securely join a 6TiSCH [RFC7554] network, it first
   needs to synchronize to the network.  The pledge then specification
   configures its
   link-local IPv6 address and authenticates itself, different layers of the 6TiSCH protocol stack and also validates
   that it is joining the right network.  At
   defines a new CoAP option.  It assumes the presence of a JRC (join
   registrar/coordinator), a central entity.  It further assumes that
   the pledge and the JRC share a symmetric key, called PSK (pre-shared
   key).  How the PSK is installed is out of scope of this point document.

   When the pledge seeks admission to a 6TiSCH network, it can expect first
   synchronizes to
   interact it, by initiating the passive scan defined in
   [IEEE802.15.4-2015].  The pledge then exchanges messages with the network
   JRC; these messages can be forwarded by nodes already part of the
   6TiSCH network.  The messages exchanged allow the JRC and the pledge
   to mutually authenticate, based on the PSK.  They also allow the JRC
   to configure its the pledge with link-layer keying
   material.  Only then may material and a short
   link-layer address.  After this secure joining process successfully
   completes, the joined node can establish an end-to-end secure session
   with an Internet host using OSCOAP
   [I-D.ietf-core-object-security] or DTLS [RFC6347].  Once the
   application requirements are known, the host.  The joined node interacts can also interact with its peers
   neighbors to request additional resources as needed, or to be reconfigured as bandwidth using the network changes 6top Protocol

   This document presumes a network as described by [RFC7554],
   [I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-terminology].
   It assumes the pledge pre-configured with either a:

   o  pre-shared key (PSK),

   o  raw public key (RPK),

   o  or a locally-valid certificate and a trust anchor.

   As the outcome of the join process, the pledge expects one or more
   link-layer key(s) and optionally a temporary link-layer identifier.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].  These
   words may also appear in this document in lowercase, absent their
   normative meanings.

   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]. [RFC8152].

   The specification also includes a set of informative examples using
   the CBOR diagnostic notation [I-D.ietf-cbor-cddl].

   The following terms are
   imported: pledge, join proxy, join registrar/coordinator, drop ship,
   imprint, enrollment, ownership voucher.

   Pledge:  the prospective device, which has the identity provided used throughout this document:

   pledge:  The new device that wishes to
      at the factory.

   Joined Node:  the prospective join a 6TiSCH network.

   joined node:  The new device, after having completed the join
      process, often just called a Node.

   Join Proxy node.

   join proxy (JP):  A node already part of the 6TiSCH network that
      serves as a stateless relay that provides to provide connectivity between the pledge and
      the Join Registrar/Coordinator.

   Join Registrar/Coordinator JRC.

   join registrar/coordinator (JRC):  A central entity responsible for
      authentication and
      the authentication, authorization and configuration of joining nodes. the pledge.

3.  One-Touch Assumptions Assumption

   This document assumes the a one-touch scenario, where devices are
   provided scenario.  The pledge is
   provisioned with some mechanism by which a secure association may be
   made in a controlled environment. PSK before attempting to join the network, and the
   same PSK (as well as the uniquer identifier of the pledge) is
   provisioned on the JRC.

   There are many ways in by which this
   might be done, and detailing any of them is out of scope for this
   document.  But, some notion of how this might provisioning can be done is important so
   that done.
   Physically, the underlying assumptions PSK can be reasoned about.

   Some examples written into the pledge using a number of how to do this could include:

   mechanisms, such as a JTAG interface

   o interface, a serial (craft) console interface

   o  pushes of physical
   interface, pushing buttons simultaneous to network attachment

   o  unsecured devices operated simultaneously on different devices, over-
   the-air configuration in a Faraday cage

   There are likely many other ways as well. cage, etc.  The provisioning can
   be done by the vendor, the manufacturer, the integrator, etc.

   Details of how this provisioning is done is out of scope of this
   document.  What is assumed is that there can be a secure, private
   conversation between the Join
   Registrar/Coordinator, JRC and the pledge, and that the two devices
   can exchange some trusted bytes of information. the PSK.

3.1.  Pre-Shared Key

   The PSK SHOULD be at least 128 bits in length, generated uniformly at
   random.  It is RECOMMENDED to generate the PSK with a
   cryptographically secure pseudorandom number generator.  Each pledge
   SHOULD be provisioned with a unique PSK.

4.  Join Overview

   This section describes the steps taken by a pledge in a 6TiSCH
   network.  When a previously unknown device pledge seeks admission to a 6TiSCH [RFC7554] network, the
   following exchange occurs:

   1.  The pledge listens for an Enhanced Beacon (EB) frame
       [IEEE802.15.4-2015].  This frame provides network synchronization
       information, and tells the device when it can send a frame to the
       node sending the beacons, which plays the role of Join Proxy join proxy (JP)
       for the pledge, and when it can expect to receive a frame.

   2.  The pledge configures its link-local IPv6 address and advertizes advertises
       it to Join Proxy the join proxy (JP).

   3.  The pledge sends packets a Join Request to JP in order to securely
       identify itself to the network.  These packets are  The Join Request is directed to
       the Join
       Registrar/Coordinator (JRC), JRC, which may be co-located on the JP or another device.

   4.  The  In case of successful processing of the request, the pledge
       receives one or more packets a join response from JRC (via the JP) that sets up one
       or more link-layer keys used to authenticate and encrypt
       subsequent transmissions to peers. peers, and a short link-layer address
       for the pledge.

   From the pledge's perspective, minimal joining is a local phenomenon
   - the pledge only interacts with the JP, and it need not know how far
   it is from the 6LBR, or how to route to the JRC.  Only after
   establishing one or more link-layer keys does it need to know about
   the particulars of a 6TiSCH network.

   The handshake process is shown as a transaction diagram in Figure 1:

      +--------+                 +-------+                 +--------+
      | pledge |                 |  JP   |                 |  JRC   |
      |        |                 |       |                 |        |
      +--------+                 +-------+                 +--------+
         |                          |                          |
   |<----ENH BEACON (1)-------|
         |<---Enhanced Beacon (1)---|                          |
         |                          |                          |
         |<-Neighbor Discovery (2)->|                          |
         |                          |                          |
   |<---Sec. Handshake (3)----|---Sec. Handshake (3a)--->|
   |                          |                          |
         |-----Join Request (4)-----|------Join (3)-----|------Join Request (4a)-->|             .
 . (3a)-->|
         |                          |                          | Simple Join .
         |<---Join Response (5)-----|-----Join (4)-----|-----Join Response (5a)---|   Protocol  .
 . (4a)---|
         |                          |                          |             .

             Figure 1: Overview of the a successful join process.

   The details of each step are described in the following sections.

4.1.  Step 1 - Enhanced Beacon


   The pledge synchronizes to the channel hopping nature of 6TiSCH, transmissions take place
   on physical channels in a circular fashion.  For that reason,
   Enhanced Beacons (EBs) are expected to be found network by listening on for, and
   receiving, an Enhanced Beacon (EB) sent by a
   single channel.  However, because some channels may be blacklisted, a
   new pledge must listen for Enhanced Beacons for a certain period on
   each of node already in the 16 possible channels.
   network.  This search process entails having
   the pledge keep the receiver portion of its radio active for the
   entire period of time. is entirely defined by [IEEE802.15.4-2015],
   and described in [RFC7554].

   Once the pledge hears an EB from a JP, EB, it synchronizes itself to the joining schedule
   using the cells contained in the EB.  The pledge can hear multiple
   EBs; the selection of which beacon EB to start with use is outside out of the scope of for this document.
   document, and is discussed in [RFC7554].  Implementers SHOULD make
   use of information such as: what Personal Area Network Identifier
   (PAN ID) [IEEE802.15.4-2015] the EB contains, whether the L2 source
   link-layer address of the EB has been tried before, any Network Identifier
   [I-D.richardson-6tisch-join-enhanced-beacon] seen, and the what signal
   of the signal.  The different EBs were received at, etc.  In addition, the
   pledge can may be configured with the Network
   Identifier pre-configured to seek when it is configured search for EBs with the PSK.

   Once a candidate network has been selected, specific PAN

   Once the pledge can transition selects the EB, it synchronizes to it and transitions
   into a low-power mode.  It deeply duty cycle, waking up only cycles its radio, switching
   the radio on when the provided schedule indicates shared slots which the
   pledge may use for the join process.  During the remainder of the
   join process, the node that has sent the EB to the pledge plays the
   role of JP.

   At this point point, the pledge may proceed to step 2, or continue to
   listen for additional EBs.

   A pledge which receives only Enhanced Beacons containing Network ID
   extensions [I-D.richardson-6tisch-join-enhanced-beacon] with the
   initiate bit cleared, SHOULD NOT proceed with this protocol on that
   network.  The pledge SHOULD consider that it is in a network which
   manages join traffic, it SHOULD switch to

4.2.  Step 2 - Neighbor Discovery

   At this point, the

   The pledge forms its link-local IPv6 address based on
   EUI64 and may register it at JP, in order to bootstrap the IPv6
   neighbor tables. EUI-64, as per
   [RFC4944].  The Neighbor Discovery exchange shown in Figure 1 refers
   to a single round trip Neighbor Solicitation / Neighbor Advertisement
   exchange between the pledge and the JP.  The pledge may
   further follow the Neighbor Discovery (ND) process described in
   Section 5 JP (Section 5.5.1 of [RFC6775].

4.3.  Step 3 - Security Handshake [RFC6775]).
   The security handshake between pledge and JRC uses Ephemeral Diffie-
   Hellman over COSE (EDHOC) [I-D.selander-ace-cose-ecdhe] to establish
   the shared session secret used to encrypt the Simple Join Protocol.

   The security handshake step is OPTIONAL in case PSKs are used, while
   it is REQUIRED link-local IPv6 address for RPKs and certificates.

   When using certificates, all subsequent
   communication with the process continues as described in
   [I-D.selander-ace-cose-ecdhe], but MAY result in no network key being
   returned.  In JP during the join process.

   Note that case, ND exchanges at this point are not protected with link-
   layer security as the pledge enters a provisional situation
   where it provides access to an enrollment mechanism described is not in

   If using a locally relevant certificate, possession of the keys.  How
   JP accepts these unprotected frames is discussed in Section 12.

   The pledge will be able to
   validate the certificate of and the JRC via JP SHOULD keep a local trust anchor.  In
   that case, separate neighbor cache for
   untrusted entries and use it to store each other's information during
   the JRC will return networks keys as in join process.  Mixing neighbor entries belonging to pledges and
   nodes that are part of the PSK case.
   This would typically be network opens up the case for JP to a device which has slept so long
   that it no longer has valid network keys DoS attack.
   How the pledge and must go through a
   partial JP decide to transition each other from untrusted
   to trusted cache, once the join process again.

   In case the handshake step completes, is omitted, the shared secret used for
   protection out of the Simple Join Protocol in the next step scope.
   One implementation technique is to use the PSK.

   A consequence is that if information whether the long-term PSK is compromised, keying
   material transferred as part of
   incoming frames are secured at the join response link layer.

4.3.  Step 3 - Join Request

   The Join Request is compromised as
   well.  Physical compromise of a message sent from the pledge, however, would also imply pledge to the compromise of JP using
   the same keying material, shared slot as it is likely to be
   found described in node's memory.

4.3.1.  Pre-Shared Symmetric Key

   The Diffie-Hellman key exchange and the use of EDHOC is optional,
   when using a pre-shared symmetric key.  This cuts down on traffic
   between JRC EB, and pledge, but requires pre-configuration of which the shared
   key on both devices.

   It is REQUIRED JP forwards to use unique PSKs for each pledge.  If there are
   multiple JRCs in
   the network (such as for redundancy), they would
   have to share a database of PSKs.

4.3.2.  Asymmetric Keys JRC.  The Security Handshake step is required, when using asymmetric keys.
   Before conducting the Diffie-Hellman key exchange using EDHOC
   [I-D.selander-ace-cose-ecdhe] the pledge and JRC need to receive and
   validate each other's public key certificate.  As detailed above,
   this can only be done for locally relevant (LDevID) certificates.
   IDevID certificates require entering a provisional state as described
   in [I-D.ietf-6tisch-dtsecurity-secure-join].

   When RPKs are pre-configured at pledge and JRC, they can directly
   proceed to JP forwards the handshake.

4.4.  Step 4 - Simple Join Protocol - Join Request

   The Join Request that makes part of the Simple Join Protocol is sent
   from the pledge to the JP using the shared slot as described in the
   EB, and forwarded to the JRC.  Which slot the JP uses to transmit to the JRC on the existing
   6TiSCH network.  How exactly this happens is out of scope: scope of this
   document; some networks may wish to dedicate specific slots for this
   join traffic.

   The join request Join Request is authenticated/encrypted end-to-end using an AEAD
   algorithm from [I-D.ietf-cose-msg] [RFC8152] and a key derived from the shared
   secret from step 3.  Algorithm negotiation is described in detail in
   [I-D.selander-ace-cose-ecdhe], PSK, the pledge's
   EUI-64 and mandatory to implement algorithms a request-specific constant value.  Algorithms which MUST
   be implemented are specified in Section 8. 11.

   The nonce used when securing the Join Request is derived from the shared secret,
   PSK, the pledge's EUI64 EUI-64 and a monotonically increasing counter
   initialized to 0 when first starting.

4.5.  Step 5 - Simple

   Join Protocol Request construction is specified in Section 7, while the
   details on processing can be found in Section 7 of

4.4.  Step 4 - Join Response

   The Join Response that makes part of the Simple Join Protocol is sent
   from by the JRC to the pledge pledge, and is forwarded
   through the JP that as it serves as a stateless relay.  Packet  The packet
   containing the Join Response travels on the path from the JRC to JP using pre-established the
   operating routes in the 6TiSCH network.  The JP delivers it to the
   pledge using the slot information from it has indicated in the EB. EB it sent.
   The JP operates as the application-layer proxy proxy, and does not keep any
   state to relay the message.  It uses information sent in the clear
   within the join response Join Response to decide where to forward to.

   The join response Join Response is authenticated/encrypted end-to-end using an AEAD
   algorithm from [I-D.ietf-cose-msg] and a [RFC8152].  The key derived used to protect the response is
   different from the shared
   secret one used to protect the request (both are derived
   from step 3. the PSK, as explained in Section 6).  The nonce response is derived from protected
   using the shared secret, pledge's EUI64 and a
   monotonically increasing counter matching that of same nonce as in the join request.

   The join response Join Response contains one or more link-layer key(s) that the
   pledge will use for subsequent communication.  Each key that is
   provided by the JRC is associated with an 802.15.4 key identifier.
   In other link-layer technologies, a different identifier may be
   substituted.  The Join Response optionally also contains an IEEE 802.15.4 short
   address [IEEE8021542015] [IEEE802.15.4-2015] assigned to pledge by JRC, the JRC to the pledge, and
   optionally the IPv6 address of the JRC.

   Join Response construction is specified in Section 8, while the
   details on processing can be found in Section 7 of

5.  Architectural Overview and Communication through Join Proxy

   The protocol Join Request/Join Response exchange in Figure 1 is implemented carried over Constrained Application
   Protocol (CoAP) [RFC7252].
   CoAP [RFC7252] and secured using OSCORE
   [I-D.ietf-core-object-security].  The Pledge pledge plays the role of a CoAP
   client; the JRC plays the role of a CoAP server, while server.  The JP implements
   CoAP forward proxy functionality [RFC7252].  Since  Because the JP is can also likely
   be a constrained device, it does not need to cannot implement a cache but rather
   process cache.  Rather, the JP
   processes forwarding-related CoAP options and make makes requests on
   behalf of pledge that is not yet part of the network. pledge, in a stateless manner.

   The pledge communicates with a Join Proxy (JP) JP over link-local IPv6 addresses.
   The pledge designates a JP as a proxy by including in the
   CoAP requests to the JP the Proxy-Scheme
   option with value "coap" (CoAP-to-CoAP proxy). proxy) in CoAP requests it
   sends to the JP.  The pledge MUST include the Uri-Host option with
   its value set to the well-known JRC's alias - "6tisch.arpa".  This
   allows the pledge to join without knowing the IPv6 address of the
   JRC.  The pledge learns the actual IPv6 address of the JRC from the join
   response and
   Join Response; it uses it once joined in order to operate as a JP.

   initial bootstrap of JRC can be co-located on the 6LBR.  Before the 6TiSCH network is
   started, the 6LBR would require explicit provisioning MUST be provisioned with the IPv6 address of the JRC address.

5.1.  Stateless-Proxy CoAP Option

   The CoAP proxy by default defined in [RFC7252] keeps per-client state
   information in order to forward the response towards the originator
   of the request
   (client). request.  This state information comprises includes at least the CoAP
   token, but the
   implementations also need to keep track of the IPv6 address of the host, as well as and the corresponding UDP source port number.  In
   If the
   setting where JP used the stateful CoAP proxy is a constrained device and there are
   potentially many clients, as defined in the case of JP, this makes [RFC7252], it would
   be prone to Denial of Service Denial-of-Service (DoS) attacks, due to the its limited

   The Stateless-Proxy CoAP option (c.f. Figure 2) 2 allows the proxy JP to
   insert within be entirely
   stateless.  This option inserts, in the request request, the state
   information necessary needed for relaying the response back to the client.  Note that the  The
   proxy still
   needs to keep keeps some state, such as general state (e.g. for performing congestion control or
   request retransmission, retransmission), but what is aimed with Stateless-Proxy
   option is to free the proxy from keeping per-client state. no per-client state.

   The Stateless-Proxy CoAP option is critical, Safe-to-Forward, not
   part of the cache key, not repeatable and opaque.  When processed by OSCOAP,
   OSCORE, the Stateless-Proxy option is neither encrypted nor integrity

        | No. | C | U | N | R | Name            | Format | Length |
        | TBD | x |   | x |   | Stateless-Proxy | opaque | 1-255  |
             C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

                   Figure 2: Stateless-Proxy CoAP Option

   Upon reception of a Stateless-Proxy option, the CoAP server MUST echo
   it in the response.  The value of the Stateless-Proxy option is
   internal proxy state that is opaque to the server.  Example state
   information includes the IPv6 address of the client, its UDP source
   port, and the CoAP token.  For security reasons, the state
   information MUST be authenticated, MUST include a freshness indicator
   (e.g. a sequence number or timestamp) and MAY be encrypted.  The
   proxy may use an appropriate COSE structure [I-D.ietf-cose-msg] [RFC8152] to wrap the
   state information as the value of the Stateless-Proxy option.  The
   key used for encryption/authentication of the state information may
   be known only to the proxy.

   Once the proxy has received the CoAP response with Stateless-Proxy
   option present, it decrypts/authenticates it, checks the freshness
   indicator and constructs the response for the client, based on the
   information present in the option value.

   Note that a CoAP proxy using the Stateless-Proxy option is not able
   to return 5.04 Gateway Timeout error in case the request to the
   server times out.  Likewise, if the response to the proxy's request
   does not contain the Stateless-Proxy option, for example when the
   option is not supported by the server, the proxy is not able to
   return the response to the client.

6.  Security Handshake

   In order to derive a shared session key, pledge and JRC run the EDHOC
   protocol [I-D.selander-ace-cose-ecdhe].  During this process, pledge
   and JRC mutually authenticate each other and verify authorization
   information before proceeding with the Simple Join Protocol.  In case
   certificates are used for authentication, this document assumes that
   a special certificate with role attribute set has been provisioned to
   the JRC.  This certificate is verified by pledge in order to
   authorize JRC to continue with the join process.  How such a
   certificate is issued to the JRC is out of scope of this document.

   Figure 3 details the exchanges between the pledge and JRC that take
   place during the execution of the security handshake.  Format of
   EDHOC messages is specified in [I-D.selander-ace-cose-ecdhe].  The
   handshake is initiated by the pledge.  JRC may either respond with an
   empty CoAP acknowledgment, signaling to the pledge that it needs to
   wait, or directly with the second message of EDHOC handshake.  How
   JRC decides whether it will immediately proceed with the handshake is
   out of scope of this document.

                +--------+                       +--------+
                | pledge |                       |  JRC   |
                |        |                       |        |
                +--------+                       +--------+
                    |                                 |
                    |        EDHOC message_1          |
                    |                                 |
                    |          Optional ACK           |
                    |< - - - - - - - - - - - - - - - -+
                    ~                                 ~
                    |                                 |
                    |        EDHOC message_2          |
                    |                                 |
                    |        EDHOC message_3          |
                    |                                 |

         Figure 3: Transaction diagram of present, it decrypts/authenticates it, checks the security handshake.

7.  Simple Join Protocol Specification

   Simple Join Protocol is a single round trip protocol (c.f.  Figure 4)
   that facilitates secure enrollment of a pledge, freshness
   indicator and constructs the response for the client, based on the
   information present in the option value.

   Note that a shared
   symmetric secret.  In case CoAP proxy using the pledge was provisioned by an
   asymmetric key (certificate or RPK), Simple Join Protocol Stateless-Proxy option is preceded
   by not able
   to return a security handshake, described 5.04 Gateway Timeout Response Code in Section 6.  When case the pledge request to
   the server times out.  Likewise, if the response to the proxy's
   request does not contain the Stateless-Proxy option, for example when
   the option is
   provisioned with a PSK, Simple Join Protocol may be run directly.

   Pledge and JRC MUST protect their exchange end-to-end (i.e. through not supported by the proxy) using Object Security of CoAP (OSCOAP)

                +--------+                       +--------+
                | pledge |                       |  JRC   |
                |        |                       |        |
                +--------+                       +--------+
                    |                                 |
                    |           Join Request          |
                    |                                 |
                    |          Join Response          |
                    |                                 |

        Figure 4: Transaction diagram of server, the Simple Join Protocol.

7.1.  OSCOAP proxy is not able to
   return the response to the client.

6.  OSCORE Security Context Instantiation

   The OSCOAP OSCORE security context MUST be derived at the pledge and the JRC
   as per Section 3.2 3 of [I-D.ietf-core-object-security] using HKDF SHA-256
   [RFC5869] as the key derivation function. [I-D.ietf-core-object-security].

   o  the Master Secret MUST be the secret generated by the run of EDHOC as
      per Appendix B of [I-D.selander-ace-cose-ecdhe], or PSK.

   o  the PSK in
      case EDHOC step was omitted. Master Salt MUST be pledge's EUI-64.

   o  the Sender ID of the pledge MUST be set to the concatenation of its
      EUI-64 and byte string 0x00.

   o  the Recipient ID (ID of the JRC) MUST be set to the concatenation of
      pledge's EUI-64 and byte string 0x01.  The construct uses pledge's
      EUI-64 to avoid nonce reuse in the response in the case same PSK
      is shared by a group of pledges.

   o  the Algorithm MUST be set to the value from [I-D.ietf-cose-msg] [RFC8152], agreed out-
      of-band by the run of EDHOC, or out-of-band in case of PSKs. same mechanism used to provision the PSK.  The
      default is AES-CCM-16-64-128.

   o  the Key derivation function MUST be agreed out-of-band.  Default
      is HKDF SHA-256.

   The derivation in [I-D.ietf-core-object-security] results in traffic
   keys and static IVs a common IV for each side of the conversation.  Nonces are
   constructed by XOR'ing the static common IV with the current sequence number.
   The context derivation process occurs exactly once.

   Implementations number
   and sender identifier.  For details on nonce construction, refer to

   It is RECOMMENDED that a PAN ID be provisioned to the pledge out-of-
   band by the same mechanism used to provision the PSK.  This prevents
   the pledge from attempting to join a wrong network.  If the pledge is
   not provisioned with the PAN ID, it SHOULD attempt to join one
   network at a time.  In that case, implementations MUST ensure that
   multiple CoAP requests to different JRCs result in the use of the
   same OSCOAP OSCORE context so that sequence numbers are properly incremented
   for each request.

6.1.  Persistency

   Implementations MUST ensure that mutable OSCORE context parameters
   (Sender Sequence Number, Replay Window) are stored in persistent
   memory.  A technique that prevents reuse of sequence numbers,
   detailed in Section 6.5.1 of [I-D.ietf-core-object-security], MUST be
   implemented.  Each update of the OSCORE Replay Window MUST be written
   to persistent memory.

   This may happen is an important security requirement in a scenario where there are multiple 6TiSCH networks present order to guarantee nonce
   uniqueness and resistance to replay attacks across reboots and
   rejoins.  Traffic between the pledge tries and the JRC is rare, making
   security outweigh the cost of writing to join one network at a time.

7.2. persistent memory.

7.  Specification of Join Request


   The Join Request the pledge sends SHALL be mapped to a CoAP request:

   o  The request method is GET. POST.

   o  The type is Non-confirmable (NON).

   o  The Proxy-Scheme option is set to "coap".

   o  The Uri-Host option is set to "6tisch.arpa".

   o  The Uri-Path option is set to "j".

   o  The object security Object-Security option SHALL be set according to
      [I-D.ietf-core-object-security] and OSCOAP parameters
      [I-D.ietf-core-object-security].  The OSCORE Context Hint SHALL be
      set as
      described above.

7.3. to pledge's EUI-64.  The OSCORE Context Hint allows the JRC to
      retrieve the security context for a given pledge.

   o  The payload is empty.

8.  Specification of Join Response

   If OSCOAP processing is a success the JRC successfully processes the Join Request using OSCORE, and
   if the pledge is authorized to join the network, message the Join Response
   the JRC sends back to the pledge SHALL be mapped to a CoAP response:

   o  The response Code is 2.05 (Content).

   o  Content-Format option is set to application/cbor. 2.04 (Changed).

   o  The payload is a CBOR [RFC7049] array containing, in order:

      *  the COSE Key Set, specified in [I-D.ietf-cose-msg], [RFC8152], containing one or
         more link-layer keys.  The mapping of individual keys to
         802.15.4-specific parameters is described in Section 7.3.1. 8.1.

      *  Optional.  Link layer  the link-layer short address that is assigned to be used by the pledge.  The
         format of the short address follows Section 7.3.2. 8.2.

      *  Optional.  optionally, the IPv6 address of the JRC transported as a byte
         string.  If the IPv6 address of the JRC is not present in the
         response, JRC is co-located with 6LBR.

   payload the
         Join Response, this indicates the JRC is co-located with 6LBR,
         and has the same IPv6 address as the 6LBR.  The address of the
         6LBR can then be learned from DODAGID field in RPL DIOs

   response_payload = [
       ? JRC_address : bstr,


8.1.  Link-layer Keys Transported in COSE Key Set

   Each key in the COSE Key Set [I-D.ietf-cose-msg] [RFC8152] SHALL be a symmetric key.  If
   the "kid" parameter of the COSE Key structure is present, the
   corresponding keys SHALL belong to an IEEE 802.15.4 KeyIdMode 0x01
   class.  In that case, parameter "kid" of the COSE Key structure SHALL
   be used to carry the IEEE 802.15.4 KeyIndex value.  If the "kid"
   parameter is not present in the transported key, the application
   SHALL consider the key to be an IEEE 802.15.4 KeyIdMode 0x00
   (implicit) key.  This document does not support IEEE 802.15.4
   KeyIdMode 0x02 and 0x03 class keys.


8.2.  Short Address


   The "short_address" structure transported as part of the join
   response payload represents the IEEE 802.15.4 short address assigned
   to the pledge.  It is encoded as a CBOR array object, containing containing, in

   o  Byte string, containing the 16-bit address.

   o  Optional  Optionally, the lease time parameter, "lease_asn".  The value of
      the "lease_asn" parameter is the 5-byte Absolute Slot Number (ASN)
      corresponding to its expiration, carried as a byte string in
      network byte order.

   short_address = [
       address : bstr,
       ? lease_asn : bstr,
   It is up to the joined node to request a new short address before the
   expiry of its previous address.  The mechanism by which the node
   requests renewal is the same as during join procedure, as described
   in Section 10. 13.  The assigned short address is used for configuring
   both Layer 2 link-layer short address and Layer 3 IPv6 addresses.


9.  Error Handling

   In and Retransmission

   Since the case JRC determines that pledge Join Request is not supposed mapped to join a Non-confirmable CoAP message,
   OSCORE processing at JRC will silently drop the
   network (e.g. by failing to find request in case of a
   failure.  This may happen for a number of reasons, including failed
   lookup of an appropriate security context), context, failed decryption,
   positive replay window lookup, formatting errors possibly due to
   malicious alterations in transit.  Silent drop at JRC prevents a DoS
   attack where an attacker could force the pledge to attempt joining
   one network at a time, until all networks have been tried.

   Using Non-confirmable CoAP message to transport Join Request also
   helps minimize the required CoAP state at the pledge and the Join
   Proxy, keeping it
   should respond with to a 4.01 Unauthorized error.  Upon reception minimum typically needed to perform CoAP
   congestion control.  It does, however, introduce complexity at the
   application layer, as the pledge needs to implement a retransmission

   The following binary exponential back-off algorithm is inspired by
   the one described in [RFC7252].  For each Join Request the pledge
   sends while waiting for a Join Response, the pledge MUST keep track
   of a
   4.01 Unauthorized, timeout and a retransmission counter.  For a new Join Request,
   the timeout is set to a random value between TIMEOUT and (TIMEOUT *
   TIMEOUT_RANDOM_FACTOR), and the retransmission counter is set to 0.
   When the timeout is triggered and the retransmission counter is less
   than MAX_RETRANSMIT, the Join Request is retransmitted, the
   retransmission counter is incremented, and the timeout is doubled.
   Note that the retransmitted Join Request passes new OSCORE
   processing, such that the sequence number in the OSCORE context is
   properly incremented.  If the retransmission counter reaches
   MAX_RETRANSMIT on a timeout, the pledge SHALL SHOULD attempt to join the
   next advertised 6TiSCH network.  If the pledge receives a Join
   Response that successfully passed OSCORE processing, it cancels the
   pending timeout and processes the response.  The pledge MUST silently
   discard any response not protected with OSCORE, including error
   codes.  For default values of retransmission parameters, see
   Section 10.

   If all join attempts have failed at
   pledge, to advertised networks have failed, the pledge
   SHOULD signal to the user by an out-of-band
   mechanism the presence of an error condition.

   In the case that the JRC determines that condition, through
   some out-of-band mechanism.

10.  Parameters

   This specification uses the pledge is not (yet)
   authorized following parameters:

                | Name                  | Default Value  |
                | TIMEOUT               | 10 s           |
                | TIMEOUT_RANDOM_FACTOR | 1.5            |
                | MAX_RETRANSMIT        | 4              |

   configured to values specific to join the network, but a further zero-touch process
   might permit it, the JRC responds with deployment.  The default values
   have been chosen to accommodate a 2.05 (Content) code, but the
   payload contains the single CBOR string "prov" (for "provisional").
   No link-layer keys or short address is returned.

   This response is typically only expected when in asymmetric
   certificate mode using 802.1AR IDevID certificates.  But for reasons wide range of provisioning or device reuse, this could occur even when a one-
   touch PSK authentication process was expected.

8. deployments, taking
   into account dense networks.

11.  Mandatory to Implement Algorithms and Certificate Format

   The mandatory to implement symmetric-key AEAD algorithm for use with
   OSCOAP OSCORE is AES-CCM-16-64-128 AES-
   CCM-16-64-128 from [I-D.ietf-cose-msg]. [RFC8152].  This is the algorithm used in 802.15.4, for
   securing 802.15.4 frames, and hardware acceleration for it is present
   in hardware on many
   platforms. virtually all compliant radio chips.  With this choice, CoAP
   messages are therefore protected with an 8-byte CCM authentication tag tag, and the
   algorithm uses 13-byte long nonces.

   The mandatory to implement hash algorithm is SHA-256 [RFC4231].

   Certificates or pre-configured RPKs may be used to exchange public
   keys between the pledge and JRC.  The mandatory to implement Elliptic
   Curve is P-256, also known as secp256r1.  The mandatory to implement
   signature algorithm is ECDSA with SHA-256.

   The certificate itself may be a compact representation of an X.509
   certificate, or a full X.509 certificate.  Compact representation of
   X.509 certificates is out of scope of this specification.  The
   certificate is signed by a root CA whose certificate is installed on
   all nodes participating in a particular 6TiSCH network, allowing each
   node to validate the certificate of the JRC or pledge as appropriate.


12.  Link-layer Requirements

   In an operational 6TiSCH network, all frames MUST use link-layer
   frame security.  The frame security options MUST include frame
   authentication, and MAY include frame encryption.

   Link-layer frames are protected with a 16-byte key, and a 13-byte
   nonce constructed from current Absolute Slot Number (ASN) and the
   source (the JP for EBs) address, as shown in Figure 5:

               |  Address (8B or 00-padded 2B) | ASN (5B)  |

               Figure 5: Link-layer CCM* nonce construction 6TiSCH network, all frames MUST use link-layer
   frame security [RFC8180].  The frame security options MUST include
   frame authentication, and MAY include frame encryption.

   The pledge does not initially do any authentication of the EB frames,
   as it does not know the K1 key. key [RFC8180].  When sending frames, the
   pledge sends unencrypted and unauthenticated frames.  The JP accepts
   these frames (exempt mode (using the "exempt mode" in 802.15.4) for the duration
   of the join process.  How the JP learns whether the join process is
   ongoing is out of scope of this specification.

   As the EB itself cannot be authenticated by the pledge, an attacker
   may craft a frame that appears to be a valid EB, since the pledge can
   neither know the ASN a priori nor verify the address of the JP.  This
   opens up a Denial possibility of Service (DoS) attack at the pledge. DoS attack, as discussed in Section 14.
   Beacon authentication keys are discussed in [I-D.ietf-6tisch-minimal].

10. [RFC8180].

13.  Rekeying and Rejoin

   This protocol specification handles initial keying of the pledge.  For reasons
   such as rejoining after a long sleep, or expiry of the short address, or
   node-initiated rekeying, the joined node MAY send a new Join Request over
   using the previously
   established secure end-to-end session with JRC. already-established OSCORE security context.  The JRC then
   responds with up-to-date keys and a (possibly new) short address.  The node may also use the
   Simple Join Protocol exchange for node-initiated rekeying.
   How the joined node
   learns that it should be rekeyed decides when to rekey is out of scope.  Additional work,
   such as in [I-D.richardson-6tisch-minimal-rekey] can be used.

11.  Key Derivations

   When EDHOC is used to derive keys, the cost of the asymmetric
   operation can be amortized over any additional connections that may
   be required between the node (during or after joining) and the JRC.

   Each application SHOULD use a unique session key.  EDHOC was designed
   with this in mind.  In order to accomplish this, the EDHOC key
   derivation algorithm can be run with a different label.  Other users scope of this key MUST define
   document.  Mechanisms for rekeying the label.

12. network are defined in
   companion specifications, such as

14.  Security Considerations

   In case PSKs are used, this

   This document mandates recommends that the pledge and JRC are pre-configured provisioned with
   unique keys. PSKs.  The uniqueness of generated
   nonces is guaranteed under request nonce and the assumption of unique EUI64 response nonce are the same,
   but used under a different key.  The design differentiates between
   keys derived for requests and keys derived for responses by different
   sender identifiers (0x00 for each pledge. pledge and 0x01 for JRC).  Note that the
   address of the JRC does not take part in nonce or key construction.  Therefore, even should an error occur, and
   Even in case of a misconfiguration in which the same PSK shared by a group of is used for
   several nodes, the nonces constructed as part of keys used to protect the requests/responses from/
   towards different responses pledges are unique. different, as they are derived using
   the pledge's EUI-64 as Master Salt.  The PSK is still important for
   mutual authentication of the pledge and authentication of the JRC to the
   pledge. JRC.  Should an attacker come
   to know the PSK, then a man-in-the-
   middle man-in-the-middle attack is possible.  The well known
   well-known problem with Bluetooth headsets with a "0000" pin applies
   here.  The design differentiates
   between nonces constructed for requests and nonces constructed for
   responses by different sender identifiers (0x00 for pledge and 0x01
   for JRC).

   Being a stateless relay, the JP blindly forwards the join traffic
   into the network.  While the exchange between pledge and JP takes
   place over a shared 6TiSCH cell, join traffic is forwarded using
   dedicated cells on the JP to JRC multi-hop path.  In case of
   distributed scheduling, the join traffic may therefore cause
   intermediate nodes to request additional bandwidth.  (EDNOTE: this is a problem that needs to be solved)  Because the
   relay operation of the JP is implemented at the application layer,
   the JP is the only hop on the JP-6LBR path that can distinguish join
   traffic from regular IP traffic in the network.  It is therefore
   recommended to implement stateless rate limiting at JP: JP; a simple
   bandwidth (in bytes or packets/second) cap would be appropriate.

   The shared nature of the "minimal" cell used for the join traffic
   makes the network prone to DoS attacks by congesting the JP with
   bogus radio traffic.  As such an attacker is limited by its emitted
   radio power, the redundancy in the number of deployed JPs alleviates
   the issue and also gives the pledge a possibility to use the best
   available link for join. joining.  How a network node decides to become a
   JP is out of scope of this specification.

   At the time beginning of the join, join process, the pledge has no means of
   verifying the content in the EB EB, and has to accept it at "face
   value".  In case the pledge tries to join an attacker's network, the join response
   Join Response message
   in such cases will either fail the security check or time
   out.  The pledge may implement a blacklist in order to filter out
   beacons EBs and try to join using the next seemingly valid network.  The EB.
   This blacklist alleviates the issue issue, but is effectively limited by
   the node's available memory.  Such bogus  Bogus beacons will prolong the join time of
   the pledge pledge, and so the time spent in "minimal"
   [I-D.ietf-6tisch-minimal] [RFC8180] duty cycle


15.  Privacy Considerations

   This specification relies on the uniqueness of EUI64 the node's EUI-64 that
   is transferred in clear as part of the security context identifier.
   (EDNOTE: should we say IID here?) an OSCORE Context Hint.  Privacy
   implications of using such long-term identifier are discussed in
   [RFC7721] and comprise correlation of activities over time, location
   tracking, address scanning and device-specific vulnerability
   exploitation.  Since the join protocol is executed rarely compared to
   the network lifetime, long-term threats that arise from using EUI64 EUI-64
   are minimal.  In addition, the join response Join Response message contains an optional a short
   address which can be is assigned by JRC to the pledge.  The assigned short
   address is independent of SHOULD be uncorrelated with the long-term identifier EUI64 and EUI-64 identifier.
   The short address is encrypted in the response.  For that reason, it is not possible to
   correlate the short address with the EUI64 used during the join.  Use of short
   addresses once the join protocol completes mitigates the
   aforementioned privacy risks.  In addition, EDHOC may be used for
   identity protection during the join protocol by generating a random
   context identifier in place of the EUI64


16.  IANA Considerations

   Note to RFC Editor: Please replace all occurrences of "[[this
   document]]" with the RFC number of this specification.

   This document allocates a well-known name under the .arpa name space
   according to the rules given in: [RFC3172].  The name "6tisch.arpa"
   is requested.  No subdomains are expected.  No A, AAAA or PTR record
   is requested.


16.1.  CoAP Option Numbers Registry

   The Stateless-Proxy option is added to the CoAP Option Numbers

             | Number | Name            | Reference         |
             |  TBD   | Stateless-Proxy | [[this document]] |


17.  Acknowledgments

   The work on this document has been partially supported by the
   European Union's H2020 Programme for research, technological
   development and demonstration under grant agreement No 644852,
   project ARMOUR.

   The authors are grateful to Thomas Watteyne and Goeran Selander for
   reviewing the draft
   reviewing, and to Klaus Hartke for providing input on the
   Stateless-Proxy Stateless-
   Proxy CoAP option.  The authors would also like to thank Francesca Palombini and
   Palombini, Ludwig Seitz and John Mattsson for participating in the
   discussions that have helped shape the document.


18.  References

18.1.  Normative References

              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security of CoAP (OSCOAP)", draft-ietf-core-
              object-security-03 for Constrained RESTful Environments
              (OSCORE)", draft-ietf-core-object-security-06 (work in
              progress), May October 2017.

              Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              draft-ietf-cose-msg-24 (work in progress), November 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC3172]  Huston, G., Ed., "Management Guidelines & Operational
              Requirements for the Address and Routing Parameter Area
              Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
              September 2001, <http://www.rfc-editor.org/info/rfc3172>. <https://www.rfc-editor.org/info/rfc3172>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <http://www.rfc-editor.org/info/rfc7049>. <https://www.rfc-editor.org/info/rfc7049>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,


   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,

18.2.  Informative References

              Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol
              (6P)", draft-ietf-6tisch-6top-protocol-05 (work in
              progress), May 2017.

              Richardson, M., "6tisch Secure Join protocol", draft-ietf-
              6tisch-dtsecurity-secure-join-01 (work in progress),
              February 2017.

              Vilajosana, X., Pister, K., and T. Watteyne, "Minimal
              6TiSCH Configuration", draft-ietf-6tisch-minimal-21 draft-ietf-6tisch-6top-protocol-09 (work in
              progress), February October 2017.

              Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
              "Terminology in IPv6 over the TSCH mode of IEEE
              802.15.4e", draft-ietf-6tisch-terminology-08 (work in
              progress), December 2016.

              Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-06 draft-ietf-6tisch-terminology-09 (work in
              progress), May June 2017.

              Dujovne, D.

              Birkholz, H., Vigano, C., and M. Richardson, "IEEE802.15.4 Informational
              Element encapsulation of 6tisch Join Information", draft-
              richardson-6tisch-join-enhanced-beacon-01 C. Bormann, "Concise data
              definition language (CDDL): a notational convention to
              express CBOR data structures", draft-ietf-cbor-cddl-00
              (work in progress), March July 2017.

              Richardson, M., "Minimal Security rekeying mechanism for
              6TiSCH", draft-richardson-6tisch-minimal-rekey-01 (work in
              progress), February 2017.

              Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
              Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
              cose-ecdhe-06 draft-richardson-6tisch-minimal-rekey-02 (work in
              progress), April August 2017.


              IEEE standard for Information Technology, ., "IEEE Std
              802.15.4-2015 Standard for Low-Rate Wireless Personal Area
              Networks (WPANs)", 2015.

   [RFC4231]  Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
              224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
              RFC 4231, DOI 10.17487/RFC4231, December 2005,

   [RFC5869]  Krawczyk, H.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 5869, 4944, DOI 10.17487/RFC5869, May 2010,

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", 10.17487/RFC4944, September 2007,

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6347, 6550,
              DOI 10.17487/RFC6347,
              January 10.17487/RFC6550, March 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,

   [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
              IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
              Internet of Things (IoT): Problem Statement", RFC 7554,
              DOI 10.17487/RFC7554, May 2015,

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,

   [RFC8180]  Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
              IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
              Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
              May 2017, <https://www.rfc-editor.org/info/rfc8180>.

Appendix A.  Example

   Figure 6 3 illustrates a successful join protocol exchange in case PSKs are used.
   Pledge exchange.  The pledge
   instantiates the OSCOAP OSCORE context and derives the traffic keys and
   nonces from the PSK.  It uses the instantiated context to protect the CoAP request
   Join Request addressed with a Proxy-Scheme option and option, the well-known
   host name of the JRC in the Uri-Host option. option, and its EUI-64
   identifier as OSCORE Context Hint.  Triggered by the presence of
   Proxy-Scheme option, the JP forwards the request to the JRC and adds
   the Stateless-Proxy option with value set to the internally needed
   state, authentication tag, and a freshness indicator.  The JP learned
   the IPv6 address of JRC when it acted as a pledge and joined the
   network.  Once the JRC receives the request, it looks up the correct
   context based on the Sender ID (sid) Context Hint parameter.  It reconstructs OSCOAP's
   OSCORE's external Additional Authenticated Data (AAD) needed for
   verification based on:

   o  the Version field of the received CoAP header.

   o  Code field of  the received CoAP header.

   o Algorithm value agreed out-of-band, default being the AES-CCM-16-64-128 AES-CCM-
      16-64-128 from [I-D.ietf-cose-msg]. [RFC8152].

   o  the Request ID being set to pledge's EUI-64 concatenated with 0x00. the value of the "kid" field of the
      received COSE object.

   o  the Join Request Sequence sequence number set to the value of "Partial IV"
      field of the received COSE object.

   o  Integrity-protected options received as part of the request.

   Replay protection is ensured by OSCOAP OSCORE and the tracking of sequence
   numbers at each side.  In the example below, the response contains
   sequence number 7 meaning that there have already been some attempts
   to join under a given context, not coming from the pledge.  Once the JP receives the response, Join Response, it
   authenticates the Stateless-Proxy option before deciding where to
   forward.  The JP sets its internal state to that found in the
   Stateless-Proxy option. option, and forwards the Join Response to the correct
   pledge.  Note that the JP does not posses possess the key to decrypt the
   COSE object (join_response) present in the payload so the
   join_response object is opaque to it. payload.  The response Join
   Response is matched to the
   request Join Request and verified for replay
   protection at the pledge using OSCOAP OSCORE processing rules.  The response  In this
   example, the Join Response does not contain JRC's the IPv6 address as in
   this particular example, we assume that of the
   JRC, the pledge hence understands the JRC is co-located with the

        <--E2E OSCOAP-->

       <---E2E OSCORE-->
     Client   Proxy  Server
     Pledge    JP     JRC
       |       |       |
       +------>|       |            Code: [0.01] (GET) { 0.02 } (POST)
       | GET   |       |           Token: 0x8c
       |       |       |    Proxy-Scheme: [coap] [ coap ]
       |       |       |        Uri-Host: [6tisch.arpa] [ 6tisch.arpa ]
       |       |       | Object-Security: [sid:EUI-64 [ kid: 0 ]
       | 0, seq:1,       |       |         Payload: Context-Hint: EUI-64
       |                   {Uri-Path:"j"},       |       |                  [ Partial IV: 1,
       |                   <Tag>]       |       |                    { Uri-Path:"j" },
       |         Payload: -       |       |                    <Tag> ]
       |       |       |      +----->|
       |       +------>|            Code: [0.01] { 0.01 } (GET)
       |       | GET   |           Token: 0x7b
       |       |       |        Uri-Host: [6tisch.arpa] [ 6tisch.arpa ]
       |       |       | Object-Security: [sid:EUI-64 [ kid: 0 ]
       |       |       | 0, seq:1, Stateless-Proxy: opaque state
       |       |       |                   {Uri-Path:"j"},         Payload: Context-Hint: EUI-64
       |       |       |                   <Tag>]                  [ Partial IV: 1,
       |       |       | Stateless-Proxy: opaque state                   { Uri-Path:"j" },
       |       |       |         Payload: -                   <Tag> ]
       |       |       |
       |      |<-----+       |<------+            Code: [2.05] { 2.05 } (Content)
       |       | 2.05  |           Token: 0x7b
       |       |       | Object-Security: -
       |       |       | Stateless-Proxy: opaque state
       |       |       |         Payload: [ seq:7,
          |      |      |                   {join_response}, <Tag>] { join_response }, <Tag> ]
       |       |       |
       |<------+       |            Code: [2.05] { 2.05 } (Content)
       | 2.05  |       |           Token: 0x8c
       |       |       | Object-Security: -
       |       |       |         Payload: [ seq:7,
          |      |      |                   {join_response}, <Tag>] { join_response }, <Tag> ]
       |       |       |

     Figure 6: 3: Example of a successful join protocol exchange with a PSK. {} exchange. { ... }
          denotes encryption and authentication, [] [ ... ] denotes

   Where join_response is as follows.

       [   / COSE Key Set array with a single key /
                1 : 4, / key type symmetric /
                2 : h'01', / key id /
               -1 : h'e6bf4287c2d7618d6a9687445ffd33e6' / key value /
           h'af93' / assigned short address /

   Encodes to
   h'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93' with
   a size of 30 bytes.

Authors' Addresses

   Malisa Vucinic (editor)
   2 Rue Simone Iff
   Paris  75012
   University of Montenegro
   Dzordza Vasingtona bb
   Podgorica  81000

   Email: malisa.vucinic@inria.fr malisav@ac.me

   Jonathan Simon
   Linear Technology
   Analog Devices
   32990 Alvarado-Niles Road, Suite 910
   Union City, CA  94587

   Email: jsimon@linear.com jonathan.simon@analog.com

   Kris Pister
   University of California Berkeley
   512 Cory Hall
   Berkeley, CA  94720

   Email: pister@eecs.berkeley.edu
   Michael Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z5V7

   Email: mcr+ietf@sandelman.ca