6TiSCH Working Group                                          M. Vucinic
Internet-Draft                                                     Inria
Intended status: Standards Track                                J. Simon
Expires: August 6, September 13, 2017                            Linear Technology
                                                               K. Pister
                                       University of California Berkeley
                                                       February 02,
                                                           M. Richardson
                                                Sandelman Software Works
                                                          March 12, 2017

                 Minimal Security Framework for 6TiSCH
                 draft-ietf-6tisch-minimal-security-01
                 draft-ietf-6tisch-minimal-security-02

Abstract

   This draft document describes the minimal mechanisms required to support
   secure initial configuration in enrollment of a pledge, a device being added to a 6TiSCH an IPv6 over
   the TSCH mode of IEEE 802.15.4e (6TiSCH) network.  It assumes that
   the pledge has been provisioned with a credential that is relevant to
   the deployment - the "one-touch" scenario.  The goal of this
   configuration is to set link-layer keys, and to establish a secure
   end-to-end session between each joining node pledge and the
   JCE join registrar who may
   use that to further configure the joining device. pledge.  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/.

   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 August 6, September 13, 2017.

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
   (http://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  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  One-Touch Assumptions . . . . . . . . . . . . . . . . . . . .   4
   4.  Join Overview . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.
     4.1.  Step 1 - Enhanced Beacon  . . . . . . . . . . . . . . . .   5
     3.2.
     4.2.  Step 2 - Neighbor Discovery . . . . . . . . . . . . . . .   5
     3.3.   6
     4.3.  Step 3 - Security Handshake . . . . . . . . . . . . . . .   5
       3.3.1.  Pre-Shared Key  . . . .   6
     4.4.  Step 4 - Simple Join Protocol - Join Request  . . . . . .   8
     4.5.  Step 5 - Simple Join Protocol - Join Response . . . . . .   8
   5.  Architectural Overview and Communication through Join Proxy .   8
     5.1.  Stateless-Proxy CoAP Option . .   6
       3.3.2.  Asymmetric Keys . . . . . . . . . . . . .   9
   6.  Security Handshake  . . . . . .   6
     3.4.  Step 4 - Join Request . . . . . . . . . . . . . . .  10
     6.1.  Discovery Message . . .   6
     3.5.  Step 5 - Join Response . . . . . . . . . . . . . . . . .   6
   4.  11
   7.  Simple Join Protocol Specification  . . . . . . . . . . . . .  11
     7.1.  OSCOAP Security Context Instantiation . . . . . .   7
     4.1.  Proxy Operation of JA . . . .  12
     7.2.  Specification of Join Request . . . . . . . . . . . . . .   7
       4.1.1.  Implementation  13
     7.3.  Specification of origin_info Join Response  . . . . . . . . . . . .   8
     4.2.  OSCOAP Security Context Instantiation .  13
   8.  Link-layer Requirements . . . . . . . . .   8
     4.3.  Implementation of Join Request . . . . . . . . . .  15
   9.  Asymmetric Keys . . .   9
     4.4.  Implementation of Join Response . . . . . . . . . . . . .   9
   5.  Link-layer requirements . . . . . . .  15
   10. Rekeying and Rejoin . . . . . . . . . . . .  10
     5.1.  Well-known beacon authentication key . . . . . . . . .  16
   11. Key Derivations .  10
     5.2.  Private beacon authentication key . . . . . . . . . . . .  10
   6.  Asymmetric Keys . . . . . . . . . .  16
   12. Security Considerations . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . .  16
   13. Privacy Considerations  . . . . . . . . . . . . .  11
   8.  Privacy Considerations . . . . . .  17
   14. IANA Considerations . . . . . . . . . . . . . .  12
   9.  IANA Considerations . . . . . . .  18
     14.1.  CoAP Option Numbers Registry . . . . . . . . . . . . . .  12
   10.  18
   15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   11.  18
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     11.1.  18
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     11.2.  18
     16.2.  Informative References . . . . . . . . . . . . . . . . .  13  19
   Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .  14  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17  23

1.  Introduction

   When

   This document describes the minimal feature set for a previously unknown device seeks admission new device,
   termed pledge, to securely join a 6TiSCH
   [RFC7554] network (to "join"), it first needs to synchronize to the network.  The device then configures  As a successful
   outcome of this process, the pledge is able to securely communicate
   with its neighbors, participate in the routing structure of the
   network or establish a secure session with an Internet host.

   When a pledge seeks admission to a 6TiSCH [RFC7554] network, it first
   needs to synchronize to the network.  The pledge then configures its
   link-local IPv6 address and authenticates itself, and also validates
   that it is joining the right network.  At this point it can expect to
   interact with the network to configure its link-layer keying
   material.  Only then may the node establish an end-to-end secure
   session with an Internet host using
   DTLS [RFC6347] or OSCOAP [I-D.ietf-core-object-security].
   [I-D.ietf-core-object-security] or DTLS [RFC6347].  Once the
   application requirements are known, the device node interacts with its peers
   to request additional resources as needed, or to be reconfigured as
   the network changes [I-D.ietf-6tisch-6top-protocol].

   This document describes the mechanisms comprising a minimal feature
   set for a device to join a 6TiSCH network, up to the point where it
   can establish a secure session with an Internet host.

   It presumes a network as described by [RFC7554],
   [I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-terminology].
   It assumes the joining device 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 joining device pledge expects one or more
   link-layer key(s) and optionally a temporary network identifier.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   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-core-object-security].
   [I-D.ietf-anima-bootstrapping-keyinfra].  The entities participating in following terms are
   imported: pledge, join proxy, join registrar/coordinator, drop ship,
   imprint, enrollment, ownership voucher.

   Pledge:  the
   protocol that is specified in this document are:

   o  JN: Joining node - prospective device, which has the device attempting identity provided to
      at the factory.

   Joined Node:  the prospective device, after having completed the join
      process, often just called a particular
      6TiSCH network.

   o  JCE: Node.

   Join coordinating entity - Proxy (JP):  a stateless relay that provides connectivity
      between the pledge and the join registrar/coordinator.

   Join Registrar/Coordinator (JRC):  central entity responsible for
      authentication and authorization of joining nodes.

   o  JA: Join assistant -

3.  One-Touch Assumptions

   This document assumes the device within radio range one-touch scenario, where devices are
   provided with some mechanism by which a secure association may be
   made in a controlled environment.  There are many ways in which this
   might be done, and detailing any of them is out of scope for this
   document.  But, some notion of how this might be done is important so
   that the JN underlying assumptions can be reasoned about.

   Some examples of how to do this could include:

   o  JTAG interface

   o  serial (craft) console interface

   o  pushes of physical buttons simultaneous to network attachment

   o  unsecured devices operated in a Faraday cage

   There are likely many other ways as well.  What is assumed is that
      generates Enhanced Beacons (EBs) and facilitates end-to-end
      communications
   there can be a secure, private conversation between the JN Join
   Registrar/Coordinator, and JCE.

3. the pledge, and that the two devices can
   exchange some trusted bytes of information.

4.  Join Overview

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

   1.  The JN pledge listens for an Enhanced Beacon (EB) frame
       [IEEE802154-2015].
       [IEEE8021542015].  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 Assistant
       (JA) Proxy (JP)
       for the JN, pledge, and when it can expect to receive a frame.

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

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

   4.  The JN pledge receives one or more packets from JCE JRC (via the JA) JP)
       that sets up one or more link-layer keys used to authenticate
       subsequent transmissions to peers.

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

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

       +-----+               +----------+              +-----------+
       | JCE

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

                  Figure 1: Message sequence for Overview of the join protocol. process.

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

3.1.

4.1.  Step 1 - Enhanced Beacon

   The JN

   Due 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 by listening on 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 the 16 possible channels.  This search process entails having
   the pledge keep the receiver portion of its radio active for the
   entire period of time.

   Once the pledge hears an EB from the JA and a JP, it synchronizes itself to the
   joining schedule using the cells contained in the EB.  The selection
   of which beacon to start with is outside the scope of this document.
   Implementers SHOULD make use of information such as: whether the L2
   address of the EB has been tried before, any Network Identifier
   [I-D.richardson-6tisch-join-enhanced-beacon] seen, and the strength
   of the signal.  The pledge can be configured with the Network
   Identifier to seek when it is configured with the PSK.

   Once a candidate network has been selected, the pledge can transition
   into a low-power duty cycle, waking up only when the provided
   schedule indicates shared slots which the pledge may use for the join
   process.

   At this point the JN
   MAY pledge may proceed to step 2, or continue to listen
   for additional EBs.  If
   more than one EB is heard, the JN MAY use a metric based on DAG rank
   and received signal level of the EB, or other factors to decide

   A pledge which
   JA to use for receives only Enhanced Beacons containing Network ID
   extensions [I-D.richardson-6tisch-join-enhanced-beacon] with the security handshake in step 3.  Details
   initiate bit cleared, SHOULD NOT proceed with this protocol on how that
   network.  The pledge SHOULD consider that it is in a JN
   chooses the JA are out of scope of this specification.

3.2. network which
   manages join traffic, it SHOULD switch to
   [I-D.ietf-6tisch-dtsecurity-secure-join].

4.2.  Step 2 - Neighbor Discovery

   At this point, JN the pledge forms its link-local IPv6 address based on
   EUI64 and MAY further follow may register it at JP, in order to bootstrap the IPv6
   neighbor tables.  The Neighbor Discovery (ND) process described exchange shown in Section 5 of [RFC6775].

3.3.  Step 3 - Security Handshake

   The 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 of [RFC6775].

4.3.  Step 3 - Security Handshake

   The security handshake between JN pledge and JCE JRC uses Ephemeral Diffie-
   Hellman over COSE (EDHOC) [I-D.selander-ace-cose-ecdhe] to establish
   the shared session secret used to encrypt the join request and join response. Simple Join Protocol.

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

   When using certificates, the process continues as described in
   [I-D.selander-ace-cose-ecdhe], but MAY result in no network key being
   returned.  In that case, the pledge enters a provisional situation
   where it provides access to an enrollment mechanism described in
   [I-D.ietf-6tisch-dtsecurity-secure-join].

   If using a locally relevant certificate, the pledge will be able to
   validate the certificate of the JRC via a local trust anchor.  In
   that case, the JRC will return networks keys as in the PSK case.
   This would typically be the case for a device which has slept so long
   that it no longer has valid network keys and must go through a
   partial join process again.

   In case the handshake step is omitted, the shared secret used for
   protection of the join request
   and join response Simple Join Protocol in the next step is the PSK.  This means that the
   protocol trades off perfect forward secrecy for reduced traffic load
   between JN and JCE.

   A consequence is that if the long-term PSK is compromised, keying
   material transferred as part of the join response is compromised as
   well.  Physical compromise of the JN, pledge, however, would also imply
   the compromise of the same keying material, as it is likely to be
   found in node's memory.

3.3.1.

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 JCE JRC and JN, pledge, but requires pre-configuration of the shared
   key on both devices.

   It is REQUIRED to use unique PSKs for each JN.

3.3.2. 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

   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 JN pledge and JCE 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 pre-configured at JN pledge and JCE, JRC, they can directly
   proceed to the handshake.

3.4.

4.4.  Step 4 - Simple Join Protocol - Join Request

   The join request Join Request that makes part of the Simple Join Protocol is sent
   from the JN pledge to the JA JP using the shared slot
   information from as described in the
   EB, and forwarded to the JCE. JRC.  Which slot the JP uses to transmit to
   the JRC is out of scope: some networks may wish to dedicate specific
   slots for this join traffic.

   The join request is typically authenticated/encrypted end-to-end
   using AES-CCM-
   16-64-128 AES-CCM-16-64-128 algorithm from [I-D.ietf-cose-msg] and a key
   derived from the shared secret from step 3.  Algorithm negotiation is
   described in detail in [I-D.selander-ace-cose-ecdhe].

   The nonce is derived from the shared secret, JN's the pledge's EUI64 and a
   monotonically increasing counter initialized to 0 when first
   starting.

3.5.

4.5.  Step 5 - Simple Join Protocol - Join Response

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

   The join response is typically authenticated/encrypted using AES-CCM-16-64-128 AES-CCM-
   16-64-128 algorithm from [I-D.ietf-cose-msg] and a key derived from
   the shared secret from step 3.

   The nonce is derived from the shared secret,
   JN's pledge's EUI64 and a
   monotonically increasing counter matching that of the join request.

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

4.  Protocol Specification JRC.

5.  Architectural Overview and Communication through Join Proxy

   The join protocol in Figure 1 is implemented over Constrained Application
   Protocol (CoAP) [RFC7252].  JN  The Pledge plays the role of a CoAP
   client, JCE JRC the role of a CoAP server, while JA JP implements CoAP
   forward proxy functionality [RFC7252].  Since JA JP is also likely a
   constrained device, it does not need to implement a cache but rather
   process forwarding-related CoAP options and make requests on behalf
   of JN pledge that is not yet part of the network.

   JN and JCE MUST protect their exchange end-to-end (i.e. through the
   proxy) using Object Security of CoAP (OSCOAP)
   [I-D.ietf-core-object-security].

4.1.

   The pledge communicates with a Join Proxy Operation of JA

   JN (JP) over link-local IPv6
   addresses.  The pledge designates a JA JP as a proxy by including in the
   CoAP requests to the JA JP the Proxy-Scheme option with value "coap"
   (CoAP-to-CoAP proxy).  JN  The pledge MUST include the Uri-Host option
   with its value set to the well-known JCE's JRC's alias - "6tisch.jce".  JN "6tisch.arpa".
   The pledge does not need to learn the actual IPv6 address of JCE JRC at
   any time during the join protocol.
   JA resolves  The JP knows the address by performing a GET request at "/jce"
   resource of its parent in the DODAG.

   Note
   JRC, via a provisioning process that occured when the JP, acting as a
   pledge, joined.  The initial bootstrap of the DODAG root would
   require explicit provisioning of the JRC address.

5.1.  Stateless-Proxy CoAP Option

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

   In order

   The Stateless-Proxy CoAP option (c.f.  Figure 2) allows the proxy to facilitate a stateless implementation of JA proxying, JN
   shall encode in
   insert within the CoAP message request the state information necessary for the JA
   to send
   relaying the response back - "origin_info".  For this purpose, JN uses to the "Context Identifier (Cid)" parameter of OSCOAP's security context
   structure.  Context Identifier is sent in clear, readable by JA, and
   MUST be echoed back in client.  Note that the response from JCE.  This makes it possible
   to implement JA's CoAP proxy in a stateless manner.  It also allows
   JCE still
   needs to look up the right security context keep some state, such as for communication performing congestion control
   or request retransmission, but what is aimed with a
   given JN.

4.1.1.  Implementation Stateless-Proxy
   option is to free the proxy from keeping per-client state.

   Stateless-Proxy option is critical, Safe-to-Forward, not part of origin_info

   The origin_info the
   cache key, not repeatable and opaque.  When processed by OSCOAP,
   Stateless-Proxy option is implemented as neither encrypted nor integrity protected.

        +-----+---+---+---+---+-----------------+--------+--------+
        | 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 CBOR [RFC7049] array object
   containing:

   o  EUI64: JN's EUI64 address

   o  source_port: JN's UDP source port

   o  token: JN's Stateless-Proxy option, the CoAP token

   origin_info = [
       EUI64 : bstr,
       source_port : uint,
       token : uint
   ]

4.2.  OSCOAP Security Context Instantiation

   The OSCOAP security context server MUST be derived at JN and JCE as per
   Section 3.2 echo
   it in the response.  The value of [I-D.ietf-core-object-security] using HKDF [RFC5869]
   as the key derivation function.

   o  Context Identifier (Cid) Stateless-Proxy option is
   internal proxy state that is opaque to the server.  Example state
   information includes 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] to wrap the origin_info object wrapped state
   information as
      a byte string (bstr).

   o  Algorithm MUST the value of the Stateless-Proxy option.  The key used
   for encryption/authentication of the state information may be set known
   only to AES-CCM-16-64-128 from
      [I-D.ietf-cose-msg]. the proxy.

   Once the proxy has received the CoAP messages 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 therefore protected used for authentication, this document assumes that
   a special certificate with
      an 8-byte CCM authentication tag 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].

                +--------+                       +--------+
                | pledge |                       |  JRC   |
                |        |                       |        |
                +--------+                       +--------+
                    |       Discovery Message         |
                    +-------------------------------->|
                    |                                 |
                    |          Optional ACK           |
                    |< - - - - - - - - - - - - - - - -+
                    |                                 |
                    |                                 |
                    |        EDHOC message_1          |
                    |<--------------------------------+
                    |                                 |
                    |        EDHOC message_2          |
                    +-------------------------------->|
                    |                                 |
                    |        EDHOC message_3          |
                    |<--------------------------------+
                    |                                 |

         Figure 3: Transaction diagram of the security handshake.

6.1.  Discovery Message

   Pledge triggers the security handshake by sending a discovery message
   to the JRC.  This initial message does not make part of the EDHOC
   handshake.  JRC is the initiator of the EDHOC run and is able to
   schedule the execution of many concurrent enrollments at will by
   acknowledging the request and sending a separate, delayed response.
   The Discovery Message SHALL be mapped to a CoAP request:

   o  The request method is POST.

   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 "edhoc".

   o  The payload is optional and contains pledge's EUI-64.

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, based on a shared
   symmetric secret.  In case the pledge was provisioned by an
   asymmetric key (certificate or RPK), Simple Join Protocol is preceded
   by a security handshake, described in Section 6.  When the pledge 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
   the proxy) using Object Security of CoAP (OSCOAP)
   [I-D.ietf-core-object-security].

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

        Figure 4: Transaction diagram of the Simple Join Protocol.

7.1.  OSCOAP Security Context Instantiation

   The OSCOAP security context MUST be derived at pledge and JRC as per
   Section 3.2 of [I-D.ietf-core-object-security] using HKDF [RFC5869]
   as the algorithm uses 13-byte
      long nonces.

   o  Base key (base_key) derivation function.

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

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

   o  Recipient ID (ID of JCE 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  Algorithm MUST be set to AES-CCM-16-64-128 from
      [I-D.ietf-cose-msg].  CoAP messages are therefore protected with
      an 8-byte CCM authentication tag and the algorithm uses 13-byte
      long nonces.

   The hash algorithm that instantiates HKDF MUST be SHA-256 [RFC4231].
   The derivation in [I-D.ietf-core-object-security] results in traffic
   keys and static IVs for each side of the conversation.  Nonces are
   constructed by XOR'ing the static IV with current sequence number.
   The context derivation process occurs exactly once.

   Implementations MUST ensure that multiple CoAP requests to different JCEs
   JRCs result in the use of the same OSCOAP context so that sequence
   numbers are properly incremented for each request.  This may happen
   in a scenario where there are multiple 6TiSCH networks present and
   the JN pledge tries to join one network at a time.

4.3.  Implementation

7.2.  Specification of Join Request

   Message Join Request message SHALL be mapped to a CoAP request:

   o  The request method is GET.

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

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

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

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

4.4.  Implementation

7.3.  Specification of Join Response

   If OSCOAP processing is a success, success and the pledge is authorized to
   join the network, message Join Response message SHALL be mapped to a CoAP
   response:

   o  The response Code is 2.05 (Content).

   o  Content-Format option is set to application/cbor.

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

      *  COSE Key Set, specified in [I-D.ietf-cose-msg], 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.

      *  Optional short address that is assigned to the pledge.  The
         format of the short address follows Section 7.3.2.

   payload = [
       COSE_KeySet,
       ? short_address,
   ]

7.3.1.  Link-layer Keys Transported in COSE Key Set [I-D.ietf-cose-msg].

   Each key in the COSE Key Set [I-D.ietf-cose-msg] SHALL be a symmetric
   key.  A key that is present in  If "kid" parameter of the COSE Key Set
         and does not have an identifier structure is assumed present, the
   corresponding keys SHALL belong to be "K2" link-
         layer key from [I-D.ietf-6tisch-minimal].  Parameter an IEEE 802.15.4 KeyIdMode 0x01
   class.  In that case, parameter "kid" of
         the COSE Key structure SHALL be
   used to denote pair-wise keys
         if present, where carry IEEE 802.15.4 KeyIndex value.  If the value "kid" parameter
   is not present in the transported key, the application SHALL be set 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.

7.3.2.  Short Address

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

   o  Byte string, containing the 16-bit address.

   o  Optional lease time parameter, "lease_asn".  The value of the
      "lease_asn" parameter is the 5-byte Absolute Slot Number (ASN)
      corresponding peer.

      *  Optional byte string representing IEEE 802.15.4 short address
         assigned to JN.  If the length of the its expiration, carried as a byte string is different
         than 2 bytes, the implementation SHOULD ignore it.

   payload in
      network byte order.

   short_address = [
       COSE_KeySet,
       address : bstr,
       ? short_address 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.  The assigned short address is used for configuring
   both Layer 2 short address and Layer 3 addresses.

7.3.3.  Error Handling

   In the case JCE JRC determines that JN pledge is not supposed to join the
   network (e.g. by failing to find an appropriate security context), it
   should respond with a 4.01 Unauthorized error.  Upon reception of a
   4.01 Unauthorized, JN the pledge SHALL attempt to join the next
   advertised 6TiSCH network.  If all join attempts have failed at JN, JN
   pledge, the pledge SHOULD signal to the user by an out-of-band
   mechanism the presence of an error condition.

5.  Link-layer requirements

   All frames

   In the case that the JRC determines that the pledge is not (yet)
   authorized to join the network, but a further zero-touch process
   might permit it, the JRC responds with 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
   of provisioning or device reuse, this could occur even when a one-
   touch PSK authentication process was expected.

8.  Link-layer Requirements

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

   In order for the JN to be able to validate that the Enhanced Beacon
   frame is coming from a 6TiSCH network, EB frames are authenticated at
   the link layer using CCM* per [IEEE802154-2015].

   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 JA JP for EBs) address, as shown in Figure 2: 5:

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

               Figure 2: 5: Link-layer CCM* nonce construction

   The JN uses pledge does not initially do any authentication of the initial key K1 [I-D.ietf-6tisch-minimal] until it is
   configured with a new link-layer key K2 EB frames,
   as described above.  JA
   SHOULD secure/verify DATA it does not know the K1 key.  When sending frames, the pledge
   sends unencrypted and ACKNOWLEDGMENT unauthenticated frames.  JP accepts these
   frames destined/
   originated at JN with K1 only during (exempt mode in 802.15.4) for the duration of the join
   process.  How JA JP learns whether the join process is ongoing is out of
   scope of this specification.

   As the EB itself does not contain security information, where of this specification.

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

9.  Asymmetric Keys

   Certificates or pre-configured RPKs may be used to exchange public
   keys between the pledge and Section 5.2.

5.1.  Well-known beacon authentication JRC.  The key

   For zero-touch operation, where any 6TiSCH device can attempt to join
   any 6TiSCH network out of pair is generated using
   elliptic curve secp256r1, and the box, a well-known EB link-layer certificate containing the public
   key
   MUST is signed using ECDSA.  (XXX: would be used. nice to move to EdDSA)

   The value certificate itself may be a compact representation of this key an X.509
   certificate, or a full X.509 certificate.  Compact representation of
   X.509 certificates is specified in
   [I-D.ietf-6tisch-minimal]

5.2.  Private beacon authentication key

   Some pre-configuration MAY be done when the device out of scope of this specification.  The
   certificate is manufactured or
   designated for signed by a specific network (i.e. the network root CA whose certificate is one-touch) or installed on
   all nodes participating in a network operator may not wish to allow arbitrary devices to try particular 6TiSCH network, allowing each
   node to
   join.  A private (per-vendor, validate the certificate of the JRC or per-installation) EB link-layer key
   MAY be used in place pledge as appropriate.

10.  Rekeying and Rejoin

   This protocol handles initial keying of the pledge.  For reasons such
   as rejoining after a well-known key to create a private network.

6.  Asymmetric Keys

   Certificates long sleep, or pre-configured RPKs may be used to exchange public
   keys between expiry of the short address, the
   joined node MAY send a new Join Request over the JN previously
   established secure end-to-end session with JRC.  JRC responds with
   up-to-date keys and JCE. a short address.  The key pair node may also use the
   Simple Join Protocol exchange for node-initiated rekeying.  How node
   learns that it should be rekeyed is out of scope.  Additional work,
   such as in [I-D.richardson-6tisch-minimal-rekey] can be used.

11.  Key Derivations

   When EDHOC is generated using
   elliptic curve secp256r1, and used to derive keys, the certificate containing cost of the public
   key is signed using ECDSA.  The certificate itself asymmetric
   operation can be amortized over any additional connections that may
   be a compact
   representation of an X.509 certificate, required between the node (during or after joining) and the JRC.

   Each application SHOULD use a full X.509 certificate.
   Compact representation of X.509 certificates is out of scope of unique session key.  EDHOC was designed
   with 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 mind.  In order to validate accomplish this, the certificate EDHOC key
   derivation algorithm can be run with a different label.  Other users
   of this key MUST define the
   JCE or JN as appropriate.

7. label.

12.  Security Considerations

   In case PSKs are used, this document mandates that JN the pledge and JCE JRC
   are pre-configured with unique keys.  The uniqueness of generated
   nonces is guaranteed under the assumption of unique EUI64 identifiers
   for each JN. pledge.  Note that the address of the JCE JRC does not take part
   in nonce construction.  Therefore, even under the assumption of should an error occur, and a
   PSK shared by a group of nodes, the nonces constructed as part of the
   different responses are unique.  The PSK is still important for
   authentication of the pledge and authentication of the JRC to the
   pledge.  Should an attacker come to know the PSK, then a man-in-the-
   middle attack is possible.  The 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 JN pledge and 0x01
   for JCE). JRC).

   Being a stateless relay, JA JP blindly forwards the join traffic into
   the network.  While the exchange between JN pledge and JA JP takes place
   over a shared cell, join traffic is forwarded using dedicated cells
   on the
   JA JP to JCE JRC 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 JA JP is implemented at the application
   layer, JA JP is the only hop on the JA-6LBR JP-6LBR path that can distinguish
   join traffic from regular IP traffic in the network.  It is therefore permitted
   recommended to implement stateless rate limiting at JA. JP: a simple
   bandwidth (in bytes or packets/second) cap would be appropriate.

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

   Because the well-known beacon authentication key does not provide any
   security, it is feasible for an attacker to generate EBs that will
   get accepted at JN.

   At the time of the join, JN the pledge has no means of verifying the
   content in the EB and has to accept it at "face value".
   As  In case the
   pledge tries to join an attacker's network, the join response message
   in such cases will either fail the security check or time out, JN out.  The
   pledge may implement a blacklist in order to filter out undesired
   beacons and try to join the next seemingly valid network.  The
   blacklist alleviates the issue but is effectively limited by the
   node's available memory.  Such bogus beacons will prolong the join
   time of JN the pledge and so the time spent in "minimal"
   [I-D.ietf-6tisch-minimal] duty cycle mode.  The permitted practice is
   to use a private, per-installation beacon authentication key.

8.

13.  Privacy Considerations

   This specification relies on the uniqueness of EUI64 that is
   transferred in clear as part of the security context identifier.
   (EDNOTE: should we say IID here?)  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 are minimal.  In
   addition, the join response message contains an optional short
   address which can be assigned by JCE JRC to JN.  Short the pledge.  The short
   address is independent of the long-term identifier EUI64 and 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
   [I-D.selander-ace-cose-ecdhe].

9.

14.  IANA Considerations

   There is no IANA action required for

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

10. 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.

14.1.  CoAP Option Numbers Registry

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

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

15.  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.  The authors would also like to thank Francesca
   Palombini and Ludwig Seitz for participating in the discussions that
   have helped shape the document.

11.

16.  References

11.1.

16.1.  Normative References

   [I-D.ietf-core-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security of CoAP (OSCOAP)", draft-ietf-core-
              object-security-01 (work in progress), December 2016.

   [I-D.ietf-cose-msg]
              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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7252]  Shelby, Z., Hartke, K.,

   [RFC3172]  Huston, G., Ed., "Management Guidelines & Operational
              Requirements for the Address and C. Bormann, "The Constrained
              Application Protocol (CoAP)", Routing Parameter Area
              Domain ("arpa")", BCP 52, RFC 7252, 3172, DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>. 10.17487/RFC3172,
              September 2001, <http://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>.

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

   [I-D.ietf-core-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security of CoAP (OSCOAP)", draft-ietf-core-
              object-security-01 (work in progress), December 2016.

11.2.  Informative References

   [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,
              <http://www.rfc-editor.org/info/rfc7554>.

   [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,
              <http://www.rfc-editor.org/info/rfc6775>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <http://www.rfc-editor.org/info/rfc5869>.

   [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,
              <http://www.rfc-editor.org/info/rfc4231>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, 7049, DOI 10.17487/RFC7721, March 2016,
              <http://www.rfc-editor.org/info/rfc7721>.

   [I-D.ietf-6tisch-minimal]
              Vilajosana, X., Pister, 10.17487/RFC7049,
              October 2013, <http://www.rfc-editor.org/info/rfc7049>.

   [RFC7252]  Shelby, Z., Hartke, K., and T. Watteyne, "Minimal
              6TiSCH Configuration", draft-ietf-6tisch-minimal-19 (work
              in progress), January 2017. C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

16.2.  Informative References

   [I-D.ietf-6tisch-6top-protocol]
              Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft-
              ietf-6tisch-6top-protocol-03 (work in progress), October
              2016.

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

   [I-D.ietf-6tisch-minimal]
              Vilajosana, X., Pister, K., and T. Watteyne, "Minimal
              6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work
              in progress), February 2017.

   [I-D.ietf-6tisch-terminology]
              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.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-04 (work in progress), October 2016.

   [I-D.richardson-6tisch-join-enhanced-beacon]
              Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational
              Element encapsulation of 6tisch Join Information", draft-
              richardson-6tisch-join-enhanced-beacon-01 (work in
              progress), March 2017.

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

   [I-D.selander-ace-cose-ecdhe]
              Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
              Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
              cose-ecdhe-04 (work in progress), October 2016.

   [IEEE802154-2015]
              IEEE standard for Information Technology, ., "IEEE Std
              802.15.4-2015 Standard F. Palombini, "Ephemeral
              Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
              cose-ecdhe-04 (work in progress), October 2016.

   [IEEE8021542015]
              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,
              <http://www.rfc-editor.org/info/rfc4231>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <http://www.rfc-editor.org/info/rfc5869>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 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,
              <http://www.rfc-editor.org/info/rfc6775>.

   [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,
              <http://www.rfc-editor.org/info/rfc7554>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for Low-Rate Wireless Personal Area
              Networks (WPANs)", 2015. IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <http://www.rfc-editor.org/info/rfc7721>.

Appendix A.  Example

   Figure 3 6 illustrates a join protocol exchange in case PSKs are used.
   JN
   Pledge instantiates the OSCOAP context and derives the traffic keys
   and nonces from the PSK.  It uses the instantiated context to protect
   the CoAP request addressed with Proxy-Scheme option and well-known
   host name of JCE JRC in the Uri-Host option.  The example assumes a JA JP
   that is already aware of JCE's JRC's IPv6 address and does not need to
   resolve the well-known "6tisch.jce" "6tisch.arpa" host name.  Triggered by the
   presence of Proxy-Scheme option, JA JP forwards the request to the JCE. JRC
   and adds the Stateless-Proxy option with value set to the internally
   needed state, authentication tag, and a freshness indicator.  Once JCE
   JRC receives the request, it looks up the correct context based on
   the
   context identifier (cid) field. Sender ID (sid) parameter.  It reconstructs OSCOAP's external
   Additional Authenticated Data (AAD) needed for verification based on:

   o  Version field of the received CoAP header.

   o  Code field of the received CoAP header.

   o  Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg] [I-D.ietf-cose-msg].

   o  Request URI reconstructed following
      [I-D.ietf-core-object-security]. ID being set to pledge's EUI-64 concatenated with 0x00.

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

   Replay protection is ensured by OSCOAP 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 JN. pledge.  Once JA JP
   receives the response, it looks up and decodes authenticates the cid field in order
   to decide Stateless-Proxy option
   before deciding where to forward it.  JA constructs the CoAP response to JN
   by setting the CoAP token forward.  JP sets its internal state to the value decoded from cid and
   constructs the link-local IPv6 address of JN from the EUI64 address that
   found in the cid. Stateless-Proxy option.  Note that JA JP does not posses
   the key to decrypt the COSE object present in the payload so the
   join_response object is opaque to it.  The response is matched to the
   request and verified for replay protection at JN pledge using OSCOAP
   processing rules.  Namely,
   to verify the response JN reconstructs the AAD based on:

   o  Version field of the received CoAP header.

   o  Code field of the received CoAP header.

   o  Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg].

   o  Transaction identifier (Tid) of the corresponding CoAP request.
      Tid contains the context identifier (origin_info object), Sender
      ID (0x00 for JN), and Sender Sequence number (set to 1 in the
      example).

   In addition to AAD, JN also uses the explicit, protected fields in
   the COSE message, present in the payload of the response.  For more
   details, see [I-D.ietf-core-object-security] and [I-D.ietf-cose-msg].

        <--E2E OSCOAP-->
        Client  Proxy Server
        JN     JA     JCE
        Pledge   JP    JRC
          |      |      |
          +----->|      |            Code: [0.01] (GET)
          | GET  |      |           Token: 0x8c
          |      |      |    Proxy-Scheme: [coap]
          |      |      |        Uri-Host: [6tisch.jce] [6tisch.arpa]
          |      |      | Object-Security: [cid:origin_info, [sid:EUI-64 | 0, seq:1,
          |      |      |                   {Uri-Path:"j"},
          |      |      |                   <Tag>]
          |      |      |         Payload: -
          |      |      |
          |      +----->|            Code: [0.01] (GET)
          |      | GET  |           Token: 0x7b
          |      |      |        Uri-Host: [6tisch.jce] [6tisch.arpa]
          |      |      | Object-Security: [cid:origin_info, [sid:EUI-64 | 0, seq:1,
          |      |      |                   {Uri-Path:"j"},
          |      |      |                   <Tag>]
          |      |      | Stateless-Proxy: opaque state
          |      |      |         Payload: -
          |      |      |
          |      |<-----+            Code: [2.05] (Content)
          |      | 2.05 |           Token: 0x7b
          |      |      | Object-Security: -
          |      |      | Stateless-Proxy: opaque state
          |      |      |         Payload: [cid: origin_info, [ seq:7,
          |      |      |                   {join_response}, <Tag>]
          |      |      |
          |<-----+      |            Code: [2.05] (Content)
          | 2.05 |      |           Token: 0x8c
          |      |      | Object-Security: -
          |      |      |         Payload: [cid: origin_info, [ seq:7,
          |      |      |                   {join_response}, <Tag>]
          |      |      |

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

   Where origin_info and join_response are is as follows.

   origin_info:
   [
       h'00170d00060d9f0e', / JN's EUI64 /
       49152, / JN's UDP source port /
       0x8c   / JN's CoAP token /
   ]

   Encodes to h'834800170d00060d9f0e19c000188c' with a size of 15 bytes.

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

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

Authors' Addresses

   Malisa Vucinic
   Inria
   2 Rue Simone Iff
   Paris  75012
   France

   Email: malisa.vucinic@inria.fr

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

   Email: jsimon@linear.com

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

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

   Email: mcr+ietf@sandelman.ca