6tisch Working Group                                       M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Informational                          October 22, 2018
Expires: April 25,                             July 08, 2019
Expires: January 9, 2020

                 6tisch Zero-Touch Secure Join protocol
             draft-ietf-6tisch-dtsecurity-zerotouch-join-03
             draft-ietf-6tisch-dtsecurity-zerotouch-join-04

Abstract

   This document describes a Zero-touch Secure Join (ZSJ) mechanism to
   enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network
   using the 6tisch signaling mechanisms.  The resulting device will
   obtain a domain specific credential that can be used with either
   802.15.9 per-host pair keying protocols, or to obtain the network-
   wide key from a coordinator.  The mechanism describe here is an
   augmentation to the one-touch mechanism described in
   [I-D.ietf-6tisch-minimal-security], and is a constrained version profile of
   [I-D.ietf-anima-bootstrapping-keyinfra]. the
   constrained voucher mechanism [I-D.ietf-anima-constrained-voucher].

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 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 April 25, 2019. January 9, 2020.

Copyright Notice

   Copyright (c) 2018 2019 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  . . . . . . . . . . . . . . . . . . . . . . . .   4   3
     1.1.  Prior Bootstrapping Approaches  . . . . . . . . . . . . .   6   5
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6   5
     1.3.  Scope of solution . . . . . . . . . . . . . . . . . . . .   7
       1.3.1.  Support environment . . . . . . . . . . . . . . . . .   8
       1.3.2.  Constrained environments  . . . . . . . . . . . . . .   8
       1.3.3.  Network Access Controls . . . . . . . . . . . . . . .   8   6
     1.4.  Leveraging the new key infrastructure / next steps  . . .   8   7
       1.4.1.  Key Distribution Process  . . . . . . . . . . . . . .   8
     1.5.  Requirements for Autonomic Network Infrastructure (ANI)
           devices . . . . . . . . . . . . . . . . . . . . . . . . .   8   7
   2.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   8   7
     2.1.  Behavior of a Pledge  . . . . . . . . . . . . . . . . . .   9   7
     2.2.  Secure Imprinting using Vouchers  . . . . . . . . . . . .  10   9
     2.3.  Initial Device Identifier . . . . . . . . . . . . . . . .  10
       2.3.1.  Identification of the Pledge  . . . . . . . . . . . .  11
       2.3.2.  MASA URI extension  . . . . . . . . . . . . . . . . .  12   9
     2.4.  Protocol Flow . . . . . . . . . . . . . . . . . . . . . .  12  10
     2.5.  Architectural Components  . . . . . . . . . . . . . . . .  13  12
       2.5.1.  Pledge  . . . . . . . . . . . . . . . . . . . . . . .  13  12
       2.5.2.  Stateless IPIP Join Proxy . . . . . . . . . . . . . .  13  12
       2.5.3.  Domain Registrar  . . . . . . . . . . . . . . . . . .  13  12
       2.5.4.  Manufacturer Service  . . . . . . . . . . . . . . . .  14
       2.5.5.  Public Key Infrastructure (PKI) . . . . . . . . . . .  14  12
     2.6.  Certificate Time Validation . . . . . . . . . . . . . . .  14  12
       2.6.1.  Lack of realtime clock  . . . . . . . . . . . . . . .  14
       2.6.2.  Infinite Lifetime of IDevID . . . . . . . . . . . . .  14  13
     2.7.  Cloud Registrar . . . . . . . . . . . . . . . . . . . . .  14  13
     2.8.  Determining the MASA to contact . . . . . . . . . . . . .  15  13
   3.  Voucher-Request artifact  . . . . . . . . . . . . . . . . . .  15  13
   4.  Proxying details (Pledge - Proxy - Registrar) . . . . . . . .  15  13
   5.  Proxy details . . . . . . . . . . . . . . . . . . . . . . . .  15  14
     5.1.  Pledge discovery of Proxy . . . . . . . . . . . . . . . .  15  14
     5.2.  CoAP connection to Registrar  . . . . . . . . . . . . . .  16
     5.3.  HTTPS proxy connection to Registrar . . . . . . . . . . .  16
     5.4.  14
     5.3.  Proxy discovery of Registrar  . . . . . . . . . . . . . .  16  14
   6.  Protocol Details (Pledge - Registrar - MASA)  . . . . . . . .  16  15
     6.1.  BRSKI-EST (D)TLS establishment details  . . . . . . . . .  17  15
       6.1.1.  BRSKI-EST CoAP/DTLS CoAP estasblishment details . . . . .  17 . . .  15
       6.1.2.  BRSKI-EST CoAP/EDHOC estasblishment details . . . . .  17  15
     6.2.  Pledge Requests Voucher from the Registrar  . . . . . . .  19  17
     6.3.  BRSKI-MASA TLS establishment details  . . . . . . . . . .  19
     6.4.  Registrar Requests Voucher from MASA  . . . . . . . . . .  19
       6.4.1.  17
       6.3.1.  MASA renewal of expired vouchers  . . . . . . . . . .  20
       6.4.2.  18
       6.3.2.  MASA verification of voucher-request signature
               consistency . . . . . . . . . . . . . . . . . . . . .  20
       6.4.3.  18
       6.3.3.  MASA authentication of registrar (certificate)  . . .  20
       6.4.4.  18
       6.3.4.  MASA revocation checking of registrar (certificate) .  20
       6.4.5.  18
       6.3.5.  MASA verification of pledge prior-signed-voucher-
               request . . . . . . . . . . . . . . . . . . . . . . .  21
       6.4.6.  18
       6.3.6.  MASA pinning of registrar . . . . . . . . . . . . . .  21
       6.4.7.  19
       6.3.7.  MASA nonce handling . . . . . . . . . . . . . . . . .  21
     6.5.  19

     6.4.  MASA Voucher Response . . . . . . . . . . . . . . . . . .  21
       6.5.1.  19
       6.4.1.  Pledge voucher verification . . . . . . . . . . . . .  22
       6.5.2.  19
       6.4.2.  Pledge authentication of provisional TLS connection .  22
     6.6.  20
     6.5.  Pledge Voucher Status Telemetry . . . . . . . . . . . . .  22
     6.7.  20
     6.6.  Registrar audit log request . . . . . . . . . . . . . . .  22
       6.7.1.  20
       6.6.1.  MASA audit log response . . . . . . . . . . . . . . .  22
       6.7.2.  20
       6.6.2.  Registrar audit log verification  . . . . . . . . . .  22
     6.8.  EST Integration for PKI bootstrapping . . . . . . . . . .  22
       6.8.1.  EST Distribution of CA Certificates . . . . . . . . .  22
       6.8.2.  20
       6.6.3.  EST CSR Attributes  . . . . . . . . . . . . . . . . .  23
       6.8.3.  20
       6.6.4.  EST Client Certificate Request  . . . . . . . . . . .  23
       6.8.4.  20
       6.6.5.  Enrollment Status Telemetry . . . . . . . . . . . . .  23
       6.8.5.  21
       6.6.6.  Multiple certificates . . . . . . . . . . . . . . . .  23
       6.8.6.  21
       6.6.7.  EST over CoAP . . . . . . . . . . . . . . . . . . . .  23
     6.9.  21
     6.7.  Use of Secure Transport for Minimal Join  . . . . . . . .  23  21
   7.  Reduced security operational modes  . . . . . . . . . . . . .  24
     7.1.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .  24
     7.2.  Pledge security reductions  . . . . . . . . . . . . . . .  24
     7.3.  Registrar security reductions . . . . . . . . .  IANA Considerations . . . . .  24
     7.4.  MASA security reductions . . . . . . . . . . . . . . . .  24  21
   8.  IANA  Privacy Considerations  . . . . . . . . . . . . . . . . . . . . .  24  21
     8.1.  Well-known EST registration .  Privacy Considerations for Production network . . . . . .  22
     8.2.  Privacy Considerations for New Pledges  . . . . . . . .  24
     8.2.  PKIX Registry .  22
       8.2.1.  EUI-64 derived address for join time IID  . . . . . .  23
   9.  Security Considerations . . . . . . . . . . . . . . .  24
     8.3.  Voucher Status Telemetry . . . .  23
     9.1.  Security of MASA voucher signing key(s) . . . . . . . . .  23
   10. Acknowledgements  . . .  24
     8.4.  DNS Service Names . . . . . . . . . . . . . . . . . . .  23
   11. References  .  25
     8.5.  MUD File Extension for the MASA server . . . . . . . . .  25
   9.  Privacy Considerations . . . . . . . . . . . . . . .  23
     11.1.  Normative References . . . .  25
     9.1.  Privacy Considerations for Production network . . . . . .  25
     9.2.  Privacy Considerations for New Pledges . . . . . . . .  23
     11.2.  Informative References .  25
       9.2.1.  EUI-64 derived address for join time IID . . . . . .  26
     9.3.  Privacy Considerations for Join Proxy . . . . . . . . . .  26
   10. Security Considerations . . .
   Author's Address  . . . . . . . . . . . . . . . .  26
     10.1.  Security of MASA voucher signing key(s) . . . . . . . .  26
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  27
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     12.2.  Informative References . . . . . . . . . . . . . . . . .  31

   Appendix A.  Extra text . . . . . . . . . . . . . . . . . . . . .  32
     A.1.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .  32
       A.1.1.  One-Touch Assumptions . . . . . . . . . . . . . . . .  32
       A.1.2.  Factory provided credentials (if any) . . . . . . . .  33
       A.1.3.  Credentials to be introduced  . . . . . . . . . . . .  33
     A.2.  Network Assumptions . . . . . . . . . . . . . . . . . . .  33
       A.2.1.  Security above and below IP . . . . . . . . . . . . .  33
       A.2.2.  Join network assumptions  . . . . . . . . . . . . . .  34
       A.2.3.  Number and cost of round trips  . . . . . . . . . . .  35
       A.2.4.  Size of packets, number of fragments  . . . . . . . .  35
     A.3.  Target end-state for join process . . . . . . . . . . . .  35
   Appendix B.  Join Protocol  . . . . . . . . . . . . . . . . . . .  35
     B.1.  Key Agreement process . . . . . . . . . . . . . . . . . .  36
     B.2.  Provisional Enrollment process  . . . . . . . . . . . . .  36
   Appendix C.  IANA Considerations  . . . . . . . . . . . . . . . .  37
   Appendix D.  Protocol Definition  . . . . . . . . . . . . . . . .  37
     D.1.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .  37
       D.1.1.  Proxy Discovery Protocol Details  . . . . . . . . . .  38
       D.1.2.  Registrar Discovery Protocol Details  . . . . . . . .  38
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  38

1.  Introduction

   Enrollment of new nodes into LLNs present unique challenges.  The
   constrained nodes has no user interfaces, and even if they did,
   configuring thousands of such nodes manually is undesireable from a
   human resources issue, as well as the difficulty in getting
   consistent results.

   This document is about a standard way to introduce new nodes into a
   6tisch network that does not involve any direct manipulation of the
   nodes themselves.  This act has been called "zero-touch"
   provisioning, and it does not occur by chance, but requires
   coordination between the manufacturer of the node, the service
   operator running the LLN, and the installers actually taking the
   devices out of the shipping boxes.

   This document is a constrained profile of
   [I-D.ietf-anima-bootstrapping-keyinfra].  The above document/protocol
   is referred by by it's acronym: BRSKI.  The pronounciation of which
   is "brew-ski", a common north american slang for beer with a pseudo-
   polish ending.  This constrained protocol is called ZSJ (pronounced
   zees-Jay).

   This document follows the same structure as BRSKI in order to
   emphasize the similarities, but specializes a number of things to
   constrained networks of constrained devices.  Like
   [I-D.ietf-anima-bootstrapping-keyinfra], the networks which are in
   scope for this protocol are deployed by a professional operator.  The
   deterministic mechanisms which have been designed into 6tisch have
   been created to satisfy the operational needs of industrial settings
   where such an operator exists.

   This document builds upon the "one-touch" provisioning described in
   [I-D.ietf-6tisch-minimal-security], reusing the OSCOAP Join Request
   mechanism when appropriate, but preceeding it with either the EDHOC
   key agreement protocol, or a DTLS setup process.  The [RFC7030] EST
   protocol extended in [I-D.ietf-6tisch-minimal-security], has been
   mapped by [I-D.ietf-ace-coap-est] into CoAP, and has the same
   security profile as this protocol.

   Whenever possible, this document does not introduce new protocols or
   mechanisms, but rather integrates them from other documents.

   Otherwise, this document follows BRSKI with the following high-level
   changes:

   o  HTTP is replaced with CoAP.

   o  TLS (HTTPS) is replaced with either DTLS+CoAP, or EDHOC/
      OSCOAP+CoAP

   o  the domain-registrar anchor certificate is replaced with a Raw
      Public Key (RPK) using [RFC7250].

   o  the PKCS7 signed JSON voucher format is replaced with CWT

   o  the GRASP discovery mechanism for the Proxy is replaced with an
      announcement in the Enhanced Beacon
      [I-D.richardson-6tisch-join-enhanced-beacon]

   o  the TCP circuit proxy mechanism is not used.  The IPIP mechanism
      if mandatory to implement when deployed with DTLS, while the CoAP
      based stateless proxy mechanism is used for OSCOAP/EDHOC.

   o  real time clocks are assumed to be unavailable, so expiry dates in
      ownership vouchers are never used

   o  nonce-full vouchers are encouraged, but off-line nonce-less
      operation is also supported, however, the resulting vouchers have
      infinite life.

   802.1AR Client Certificates (IDevID) are retained, but optionally are
   specified by reference rather than value.

   It is expected that the back-end network operator infrastructure
   would be able to bootstrap ANIMA BRSKI-type devices over ethernet,
   while also being able bootstrap 6tisch devices over 802.15.4 with few
   changes.

   NOTE TO RFC-EDITOR: during production of this document, it was
   matched against [I-D.ietf-anima-bootstrapping-keyinfra] section by
   section.  This results in a few sections, such as IANA Considerations
   where there is no requested activity.  Those sections are marked "NO
   ACTION, PLEASE REMOVE" and should be removed (along with this
   paragraph) from the final document.  Some sections are marked as "no
   changes" and should be left in place so that the section numbering
   remains consistent with [I-D.ietf-anima-bootstrapping-keyinfra].

1.1.  Prior Bootstrapping Approaches

   Constrained devices as used in industrial control systems are usually
   installed (or replaced) by technicians with expertise in the
   equipment being serviced, not in secure enrollment of devices.

   Devices therefore are typically pre-configured in advance, marked for
   a particular factory, assembly line, or even down to the specific
   machine.  It is not uncommon for manufacturers to have a product code
   (stock keeping unit -SKU) for each part, and for each customer as the
   part will be loaded with customer specifc security configuration.
   The resulting customer-specific parts are hard to inventory and
   spare, and should parts be delivered to the wrong customer,
   determining the reason for inability to configure is difficult and
   time consuming.

   End-user actions to configure the part at the time of installation,
   aside from being error prone, also suffer from requiring a part that
   has an interface.

1.2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant STuPiD
   implementations.

   The reader is expected to be familiar with the terms and concepts
   defined in [I-D.ietf-6tisch-terminology], [RFC7252],
   [I-D.ietf-core-object-security], and
   [I-D.ietf-anima-bootstrapping-keyinfra].  The following terms are
   imported: drop ship, imprint, enrollment, pledge, join proxy,
   ownership voucher, join registrar/coordinator.  The following terms
   are repeated here for readability, but this document is not
   authoritative for their definition:

   pledge  the prospective device, which has the identity provided to at
      the factory.  Neither the device nor the network knows if the
      device yet knows if this device belongs with this network.

   Joined Node  the prospective device, after having completing the join
      process, often just called a Node.

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

   Audit Token  A signed token from the manufacturer authorized signing
      authority indicating that the bootstrapping event has been
      successfully logged.  This has been referred to as an
      "authorization token" indicating that it authorizes bootstrapping
      to proceed.

   Ownership Voucher  A signed voucher from the vendor vouching that a
      specific domain "owns" the new entity as defined in
      [I-D.ietf-anima-voucher].

   MIC  manufacturer installed certificate.  An [ieee802-1AR] identity.
      Not to be confused with a (cryptographic) "Message Integrity
      Check"

1.3.  Scope of solution

   The solution described in this document is appropriate to enrolling
   between hundreds to hundreds of thousands of diverse devices into a
   network without any prior contact with the devices.  The devices
   could be shipped by the manufacturer directly to the customer site
   without ever being seen by the operator of the network.  As described
   in BRSKI, in the audit-mode of operation the device will be claimed
   by the first network that sees it.  In the tracked owner mode of
   operation, sales channel integration provides a strong connection
   that the operator of the network is the legitimate owner of the
   device.

   BRSKI describes a more general, more flexible approach for
   bootstrapping devices into an ISP or Enterprise network.

   [I-D.ietf-6tisch-minimal-security] provides an extremely streamlined
   approach to enrolling from hundreds to thousands of devices into a
   network, provided that a unique secret key can be installed in each
   device.

1.3.1.  Support environment

   TBD

1.3.2.  Constrained environments

   TBD

1.3.3.  Network Access Controls

   TBD

1.4.  Leveraging the new key infrastructure / next steps

   In constrained networks, it is unlikely that an ACP be formed.  This
   document does not preclude such a thing, but it is not mandated.

   The resulting secure channel MAY be used just to distribute network-
   wide keys using a protocol such as
   [I-D.ietf-6tisch-minimal-security].  (XXX - do we need to signal this
   somehow?)

   The resulting secure channel MAY be instead used to do an enrollment
   of an LDevID as in BRSKI, but the resulting certificate is used to do
   per-pair keying such as described by {{ieee802159}.

1.4.1.  Key Distribution Process

   In addition to being used for the initial enrollment process, the
   secure channel may be kept open (and reversed) to use for network
   rekeying.  Such a process is out of scope of this document, please
   see future work such as [I-D.richardson-6tisch-minimal-rekey].

1.5.  Requirements for Autonomic Network Infrastructure (ANI) devices

   TBD

2.  Architectural Overview

   Section 2 of BRSKI has a diagram with all of the components shown
   together.  There are no significant changes to the diagram.

   The use of a circuit proxy is not mandated.  Instead the IPIP
   mechanism described in appendix C ("IPIP Join Proxy mechanism")
   SHOULD be be used instead as it supports both DTLS, EDHOC and OSCOAP
   protocols.

   The CoAP proxy mechanism MAY be implemented instead: the decision
   depends upon the capabilities of the Registrar and the proxy.  A
   mechanism is included for the Registrar to announce it's capabilities
   (XXX)

2.1.  Behavior of a Pledge

   The pledge goes through a series of steps which are outlined here at
   a high level.

                +--------------+
                |   Factory    |
                |   default    |
                +------+-------+
                       |
                +------v-------+
                | (1) Discover |
   +------------>              |
   |            +------+-------+
   |                   |
   |            +------v-------+
   |            | (2) Identity |
   ^------------+              |
   | rejected   +------+-------+
   |                   |
   |            +------v-------+
   |            | (3) Request  |
   |            |     Join     |
   |            +------+-------+
   |                   |
   |            +------v-------+
   |            | (4) Imprint  |
   ^------------+              |
   | Bad MASA   +------+-------+
   | response          |  send Voucher Status Telemetry
   |            +------v-------+
   |            | (5) Enroll   |
   ^------------+              |
   | Enroll     +------+-------+
   | Failure           |
   |            +------v-------+
   |            | (6) Enrolled |
   ^------------+              |
    Factory     +--------------+
    reset

   State descriptions for the pledge are as follows:

   1.  Discover a communication channel to a Registrar.  This is done by
       listening for beacons as described by
       [I-D.richardson-anima-6join-discovery]

   2.  Identify itself.  This is done by presenting an X.509 IDevID
       credential to the discovered Registrar (via the Proxy) in a DTLS
       or EDHOC handshake.  (The Registrar credentials are only
       provisionally accepted at this time).

       The registrar identifies itself using a raw public key, while the
       the pledge identifies itself to the registrar using an IDevID
       credential.

   3.  Requests to Join the discovered Registrar.  A unique nonce can be
       included ensuring that any responses can be associated with this
       particular bootstrapping attempt.

   4.  Imprint on the Registrar.  This requires verification of the
       vendor service (MASA) provided voucher.  A voucher contains
       sufficient information for the Pledge to complete authentication
       of a Registrar.  The voucher is signed by the vendor (MASA) using
       a raw public key, previously installed into the pledge at
       manufacturing time.

   5.  Optionally Enroll.  By accepting the domain specific information
       from a Registrar, and by obtaining a domain certificate from a
       Registrar using a standard enrollment protocol, e.g.  Enrollment
       over Secure Transport (EST) [RFC7030].

   6.  The Pledge is now a member of, and can be managed by, the domain
       and will only repeat the discovery aspects of bootstrapping if it
       is returned to factory default settings.

2.2.  Secure Imprinting using Vouchers

   As in BRSKI, the format and cryptographic mechansim of vouchers is
   described in detail in [I-D.ietf-anima-voucher].  As described in
   section YYY, the physical format for vouchers in this document
   differs from that of BRSKI, in that it uses
   [I-D.ietf-ace-cbor-web-token] to encode the voucher and to sign it.

2.3.  Initial Device Identifier

   The essential component of the zero-touch operation is that the
   pledge is provisioned with an 802.1AR (PKIX) certificate installed
   during the manufacturing process.

   It is expected that constrained devices will use a signature
   algorithm corresponding to the hardware acceleration that they have,
   if they have any.  The anticipated algorithms are the ECDSA P-256
   (secp256p1), and SHOULD be supported.  Newer devices SHOULD begin to
   appear using EdDSA curves using the 25519 curves.

   The manufacturer will always know what algorithms are available in
   the Pledge, and will use an appropriate one.  The other components
   that need to evaluate the IDevID (the Registrar and MASA) are
   expected to support all common algorithms.

   There are a number of simplications detailed later on in this
   document designed to eliminate the need for an ASN.1 parser in the
   pledge.

   The pledge should consider it's 802.1AR certificate to be an opaque
   blob of bytes, to be inserted into protocols at appropriate places.
   The pledge SHOULD have access to it's public and private keys in the
   most useable native format for computation.

   The pledge MUST have the public key of the MASA built in a
   manufacturer time.  This is a seemingly identical requirement as for
   BRSKI, but rather than being an abstract trust anchor that can be
   augmented with a certificate chain, the pledge MUST be provided with
   the Raw Public Key that the MASA will use to sign vouchers for that
   pledge.

   There are a number of security concerns with use of a single MASA
   signing key, and section Section 10.1 addresses some of them with
   some operational suggestions.

   BRSKI places some clear requirements upon the contents of the IDevID,
   but leaves the exact origin of the voucher serial-number open.  This
   document restricts the process to being the hwSerialNum OCTET STRING.
   As CWT can handle binary formats, no base64 encoding is necessary.

   The use of the MASA-URL extension is encouraged if the certificate is
   sent at all.

   EDNOTE: here belongs text about sending only a reference to the
   IDevID rather than the entire certificate

2.3.1.  Identification of the Pledge

   TBD

2.3.2.  MASA URI extension

   TBD

2.4.  Protocol Flow

   The diagram from BRSKI is reproduced with some edits:

    +--------+         +---------+    +------------+     +------------+
    | Pledge |         | IPIP    |    | Domain     |     | Vendor     |
    |        |         | Proxy   |    | Registrar  |     | Service    |
    |        |         |         |    | (JRC)      |     | (MASA)     |
    +--------+         +---------+    +------------+     +------------+
      |                     |                   |                    |
      |<-RFC4862 IPv6 adr   |                   |                    |
      |                     |                   |                    |
      |<--------------------|                   |                    |
      | Enhanced Beacon     |                   |                    |
      |   periodic broadcast|                   |                    |
      |                     |                   |                    |
      |<------------------->C<----------------->|                    |
      |             DTLS via the IPIP    Proxy  |                    |
      |<--Registrar DTLS server authentication--|                    |
    [PROVISIONAL accept of server cert]         |                    |
      P---X.509 client authentication---------->|                    |
      P                     |                   |                    |
      P---Voucher Request (include nonce)------>|                    |
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |              [accept device?]          |
      P                     |              [contact Vendor]          |
      P                     |                   |--Pledge ID-------->|
      P                     |                   |--Domain ID-------->|
      P                     |                   |--nonce------------>|
      P                     |                   |     [extract DomainID]
      P                     |                   |                    |
      P                     |                   |     [update audit log]
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |                   |<-device audit log--|
      P                     |                   |<- voucher ---------|
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |       [verify audit log and voucher]   |
      P                     |                   |                    |
      P<------voucher---------------------------|                    |
    [verify voucher ]       |                   |                    |
    [verify provisional cert|                   |                    |
      |                     |                   |                    |
      |<--------------------------------------->|                    |
      | Continue with RFC7030 enrollment        |                    |
      | using now bidirectionally authenticated |                    |
      | DTLS session.       |                   |                    |
      |                     |                   |                    |
      |<--------------------------------------->|                    |
      |  Use 6tisch-minimal-security join request                    |

   Noteable changes are:

   1.  no IPv4 support/options.

   2.  no mDNS steps, 6tisch only uses Enhanced Beacon

   3.  nonce-full option is always mandatory

2.5.  Architectural Components

   The bootstrap process includes the following architectural
   components:

2.5.1.  Pledge

   The Pledge is the device which is attempting to join.  Until the
   pledge completes the enrollment process, it has network connectivity
   only to the Proxy.

2.5.2.  Stateless IPIP Join Proxy

   The stateless CoAP or DTLS Proxy provides CoAP or DTLS connectivity
   (respectively) between the pledge and the registrar.  The stateless
   CoAP proxy mechanism is described in
   [I-D.ietf-6tisch-minimal-security] section 5.1.

   The stateless DTLS mechanism is not yet described (TBD).

2.5.3.  Domain Registrar

   The Domain Registrar (having the formal name Join Registrar/
   Coordinator (JRC)), operates as a CMC Registrar, terminating the EST
   and BRSKI connections.  The Registrar is manually configured or
   distributed with a list of trust anchors necessary to authenticate
   any Pledge device expected on the network.  The Registrar
   communicates with the Vendor supplied MASA to establish ownership.

   The JRC is typically located on the 6LBR/DODAG root, but it may be
   located elsewhere, provided IP level connectivity can be established.
   The 6LBR may also provide a proxy or relay function to connect to the
   actual registrar in addition to the IPIP proxy described above.  The
   existence of such an additional proxy is a private matter, and this
   documents assumes without loss of generality that the registrar is
   co-located with the 6LBR.

2.5.4.  Manufacturer Service

   The Manufacturer Service provides two logically seperate functions:
   the Manufacturer Authorized Signing Authority (MASA), and an
   ownership tracking/auditing function.  This function is identical to
   that used by BRSKI, except that a different format voucher is used.

2.5.5.  Public Key Infrastructure (PKI)

   TBD

2.6.  Certificate Time Validation

2.6.1.  Lack of realtime clock

   For the constrained situation it is assumed that devices have no real
   time clock.  These nodes do have access to a monotonically increasing
   clock that will not go backwards in the form of the Absolute Sequence
   Number.  Synchronization to the ASN is required in order to transmit/
   receive data and most nodes will maintain it in hardware.

   The heuristic described in BRSKI under this section SHOULD be applied
   if there are dates in the CWT format voucher.

   Voucher requests SHOULD include a nonce.  For devices intended for
   off-line deployment, the vouchers will have been generated in advance
   and no nonce-ful operation will not be possible.

2.6.2.  Infinite Lifetime of IDevID

   TBD

2.7.  Cloud Registrar

   In 6tisch, the pledge never has network connectivity until it is
   enrolled, so no alternate registrar is ever possible.

2.8.  Determining the MASA to contact

   There are no changes from BRSKI: the IDevID provided by the pledge
   will contain a MASA URL extension.

3.  Voucher-Request artifact

   The voucher-request artifact is defined in
   [I-D.ietf-anima-constrained-voucher] section 6.1.

   For the 6tisch ZSJ protocol defined in this document, only COSE
   signed vouchers as described in [I-D.ietf-anima-constrained-voucher]
   section 6.3.2 are supported.

4.  Proxying details (Pledge - Proxy - Registrar)

   The voucher-request artifact is defined in
   [I-D.ietf-anima-constrained-voucher].

   The 6tisch use of the constrained version differs from the non-
   constrained version in two ways:

   1.  it does not include the pinned-domain-cert, but rather than
       pinned-domain-subjet-public-key-info entry.  This accomodates the
       use of a raw public key to identify the registrar.

   2.  the pledge voucher-request is never signed.

   An appendix shows detailed examples of COSE format voucher requests.

5.  Proxy details

   The role of the Proxy is to facilitate communication.  In the
   constrained situation the proxy needs to be stateless as there is
   very little ram to begin with, and none can be allocated to keep
   state for an unlimited number of potential pledges.

5.1.  Pledge discovery of Proxy

   In BRSKI, the pledge discovers the proxy via use of a GRASP M_FLOOD
   messages sent by the proxy.  In 6tisch ZSJ, the existence of the
   proxy is announced by the Enhanced Beacon message described in
   [I-D.richardson-6tisch-enrollment-enhanced-beacon].  The proxy as
   described by [I-D.ietf-6tisch-minimal-security] section 10 is to be
   used in an identical fashion when EDHOC and OSCOAP are used.

   When DTLS security is provided, then the proxy mechanism described in
   TBD must be used.

5.2.  CoAP connection to Registrar

   In BRSKI CoAP is future work.  This document represents this work.

5.3.  HTTPS proxy connection to Registrar

   HTTPS connections are not used between the Pledge, Proxy and
   Registrar.  The Proxy relays CoAP or DTLS packets and does not
   interpret or terminate either CoAP or DTLS connections.  (HTTPS is
   still used between the Registrar and MASA)

5.4.  Proxy discovery of Registrar

   In BRSKI, the proxy autonomically discovers the Registrar by
   listening for GRASP messages.

   In the constrained network, the proxies are optionally configured
   with the address of the JRC by the Join Response in in
   [I-D.ietf-6tisch-minimal-security] section 9.3.2.  (As described in
   that section, the address of the registrar otherwise defaults to be
   that of the DODAG root)

   Whether or not a 6LR will announce itself as a possible Join Proxy is
   outside the scope of this document.

6.  Protocol Details (Pledge - Registrar - MASA)

   BRSKI is specified to run over HTTPS.  This document respecifies it
   to run over CoAP with either DTLS or EDHOC-provided OSCOAP security.

   BRSKI introduces the concept of a provisional state for EST.

   The same situation must also be added to DTLS: a situation where the
   connection is active but the identity  27

1.  Introduction

   Enrollment of the Registar has not yet
   been confirmed. new nodes into LLNs present unique challenges.  The DTLS MUST validate that the exchange
   constrained nodes has been
   signed by the Raw Public Key that is presented by the Server, no user interfaces, and even
   though there if they did,
   configuring thousands of such nodes manually is as yet no trust in that key.  Such undesireable from a key is often
   available through APIs that provide for channel binding, such
   human resources issue, as well as
   described in [RFC5056].

   There is an emerging (hybrid) possibility of DTLS-providing the
   OSCOAP security, but such a specification does not yet exist, and
   this difficulty in getting
   consistent results.

   This document does at this point specify it.

   [I-D.ietf-ace-coap-est] specifies that CoAP specifies the use of CoAP
   Block-Wise Transfer ("Block") [RFC7959] to fragment EST messages at
   the application layer.

   BRSKI introduces the concept of is about a provisional state for EST.  The
   same situation must also be added standard way to DTLS: a situation where the
   connection is active but the identity of the Registar has not yet
   been confirmed.

   The DTLS MUST validate that the exchange has been signed by the Raw
   Public Key that is presented by the Server, even though there is as
   yet no trust in that key.  Such introduce new nodes into a key is often available through APIs
   6tisch network that provide for channel binding, such as described in [RFC5056].

   As in [I-D.ietf-ace-coap-est], support for Observe CoAP options
   [RFC7641] with BRSKI is does not supported in involve any direct manipulation of the current BRSKI/EST
   message flows.

   Observe options could be used
   nodes themselves.  This act has been called "zero-touch"
   provisioning, and it does not occur by chance, but requires
   coordination between the server to notify clients about a
   change in manufacturer of the cacerts or csr attributes (resources) node, the service
   operator running the LLN, and might be an
   area the installers actually taking the
   devices out of future work.

   Redirection as the shipping boxes.

   The mechanism described in [RFC7030] section 3.2.1 [I-D.ietf-anima-bootstrapping-keyinfra]
   has been adapted in [I-D.ietf-anima-constrained-voucher] to produce a
   protocol that is NOT supported.

6.1.  BRSKI-EST (D)TLS establishment details

   6tisch ZSJ does not use TLS. suited for constrained devices and constrained
   networks such as 6tisch.  The connection above document/protocol is either CoAP over
   DTLS, or CoAP with EDHOC security.

6.1.1.  BRSKI-EST CoAP/DTLS estasblishment details

   The details in the referred by
   by it's acronym: BRSKI document apply directly to use of DTLS. and constrained-BRSKI.  The registrar SHOULD authenticate itself with a raw public key.  A
   256 bit ECDSA raw public key is RECOMMENDED.  Pledges SHOULD support
   EDDSA keys if they contain hardware that supports doing so
   efficiently.

   TBD: the Pledge needs to signal what kind pronounciation of Raw Public Key it
   supports before the Registrar sends its ServerCertificate.  Can SNI
   be used to do this?

   The pledge SHOULD authenticate itself
   which is "brew-ski", a common north american slang for beer with the built-in IDevID
   certificate as a ClientCertificate.

6.1.2.  BRSKI-EST CoAP/EDHOC estasblishment details

   [I-D.selander-ace-cose-ecdhe] details how to use EDHOC.  The EDHOC
   description identifiers
   pseudo-polish ending.  This constrained protocol is called Zero-touch
   Secure Join.

   This document is a party U (the initiator), profile of [I-D.ietf-anima-constrained-voucher].
   It uses COSE signatures of CBOR voucher [RFC8366] artifacts, and it
   uses [I-D.selander-ace-cose-ecdhe] as a party V.
   The Pledge is the party U, Lightweight authenticated key
   exchange protocol.

   [I-D.ietf-anima-constrained-voucher] has options for CMS signatures
   of CBOR vouchers, and the JRC is the party V. for using DTLS.  The communication from the Pledge is via CoAP via protocol described in this
   document does not make use those options.

   Like [I-D.ietf-anima-bootstrapping-keyinfra], the Join Proxy. networks which are
   in scope for this protocol are deployed by a professional operator.
   The Join proxy relays traffic deterministic mechanisms which have been designed into 6tisch
   have been created to satisfy the JRC, and using operational needs of industrial
   settings where such an operator exists.

   This document builds upon the mechanism "one-touch" provisioning described in [I-D.ietf-6tisch-minimal-security] section 5.1.  This is
   designed so that
   [I-D.ietf-6tisch-minimal-security], reusing the OSCOAP Join Proxy does not need to know if Request
   mechanism when appropriate, but preceeding it is
   performing the one-touch enrollment described in
   [I-D.ietf-6tisch-minimal-security] or with the zero-touch enrollment
   protocol described in this document.  A network could consist of a
   mix of nodes of each type. EDHOC key
   agreement protocol.

   As generating ephemeral keys is expensive for a low-resource Pledge,
   the use of second option, a common E_U by the Pledge for multiple enrollment
   attempts (should the first turn out to certificate may be deployed using the wrong network) is
   encouraged.

   The first communication detailed
   constrained version of [RFC7030] EST described in [I-D.ietf-ace-coap-est] is to
   query the "/.well-known/core" resource to request
   [I-D.ietf-ace-coap-est].

   Otherwise, this document follows BRSKI with the Link for EST.
   This following high-level
   changes:

   o  HTTP is where replaced with CoAP.

   o  TLS (HTTPS) is replaced with EDHOC/OSCOAP+CoAP

   o  the initial CoAP request domain-registrar anchor certificate is to sent.

   The JRC MAY replace it's E_V ephermal key on replaced with a periodic basis, or
   even Raw
      Public Key (RPK) using [RFC7250].

   o  the PKCS7 signed JSON voucher format is replaced with COSE
      signature

   o  the GRASP discovery mechanism for every communication session.

   The Pledge's ID_U the Proxy is replaced with an
      announcement in the Pledge's IDevID.  It Enhanced Beacon
      [I-D.richardson-6tisch-join-enhanced-beacon]

   o  the TCP circuit proxy mechanism is transmitted not used.  The CoAP based
      stateless proxy mechanism described in an
   x5bag [I-D.schaad-cose-x509].  An x5u (URL) MAY be
      [I-D.ietf-6tisch-minimal-security] section 7.1 is used.  An x5t
   (hash) MAY also

   o  real time clocks are assumed to be unavailable, so expiry dates in
      ownership vouchers are never used and would be the smallest,

   o  nonce-full vouchers are encouraged, but off-line nonce-less
      operation is also supported, however, the Registrar
   may not know where to find the Pledge's IDevID unless the JRC has
   been preloaded will all the IDevIDs via out-of-band mechanism. resulting vouchers would
      have infinite life.

   802.1AR Client certificates are retained, but optionally are
   specified by reference rather than value (Work in Progress).

   It is
   impossible for expected that the Pledge back-end network operator infrastructure
   would be able to know if bootstrap ANIMA BRSKI-type devices over ethernet,
   while also being able bootstrap 6tisch devices over 802.15.4 with few
   changes.

1.1.  Prior Bootstrapping Approaches

   Constrained devices as used in industrial control systems are usually
   installed (or replaced) by technicians with expertise in the JRC has been loaded
   equipment being serviced, not in such
   a way so x5t is discouraged secure enrollment of devices.

   Devices therefore are typically pre-configured in advance, marked for general use.

   The JRC's ID_V is
   a particular factory, assembly line, or even down to the JRC's Raw Public Key. specific
   machine.  It is transmitted as a
   key in COSE's YYY parameter.

   The initial Mandatory not uncommon for manufacturers to Implement (MTI) of an HKDF of SHA2-256, an
   AEAD based upon AES-CCM-16-64-128, have a signature verification of BBBB,
   and signature generation of BBBB. unique
   product (stock keeping unit -SKU) for each customer as the part will
   be loaded with customer specifc security configuration.  The Pledge proposes a set of
   algorithms that it supports, and Pledge need not support more than
   one combination.

   JRCs
   resulting customer-specific parts are expected hard to run on non-constrained servers, inventory and are expected very
   expensive to support the above initial MTI, and any subsequent ones that become
   common.  A JRC SHOULD support all available algorithms for provide spares for.  Should a
   significant amount of time.  Even when algorithms become weak or
   suspect, it is likely that it will still have to perform secure join
   for older devices.  A JRC that responds part be delivered to such an older device might
   not in the end accept the device into
   wrong customer, determining the network, but it is
   important that it be able reason for inability to audit the event configure is
   difficult and communicate the
   event time consuming.

   End-user actions to an operator.

   While EDHOC supports sending additional data in the message_3, in configure the
   constrained network situation, it is anticipated that part at the size time of the installation,
   aside from being error prone, also suffer from requiring a part that
   has a user interface.

1.2.  Terminology

   In this message will already document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be large, interpreted as described in BCP 14, RFC 2119
   [RFC2119] and no additional data indicate requirement levels for compliant STuPiD
   implementations.

   The reader is expected to be
   sent.

   A COAP confirmable message SHOULD be used.

   [I-D.ietf-6tisch-minimal-security] section 6 details how to setup
   OSCORE context given a shared key derived by EDHOC.

   The registrar SHOULD authenticate itself with a raw public key.

   The pledge SHOULD authenticate itself familiar with the built-in IDevID
   certificate.

6.2.  Pledge Requests Voucher from the Registrar

   The voucher request terms and response as concepts
   defined by BRSKI is modified
   slightly.

   In order to simplify the in [I-D.ietf-6tisch-terminology], [RFC7252],
   [I-D.ietf-core-object-security],
   [I-D.ietf-anima-bootstrapping-keyinfra] and
   [I-D.ietf-anima-constrained-voucher].  The following terms are
   imported: drop ship, imprint, enrollment, pledge, the use of a certificate (and chain) join proxy,
   ownership voucher, and join registrar/coordinator (JRC).  The
   following terms are repeated here for the Registrar readability, but this document
   is not supported.  Instead the newly defined
   pinned-domain-subject-public-key-info must contain the (raw) public
   key info authoritative for their definition:

   pledge  the Registrar.  It MUST be byte for byte identical to
   that prospective device, which is transmitted by has the Registrar during identity provided to at
      the TLS
   ServerCertificate handshake.

   BRSKI permits factory.  Neither the voucher request to be signed or unsigned.  This
   document defines device nor the voucher request to be unsigned.

6.3.  BRSKI-MASA TLS establishment details

   There are no changes.  The connection network knows if the
      device yet knows if this device belongs with this network.

   Joined Node  the prospective device, after having completing the join
      process, often just called a Node.

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

   Audit Token  A signed token from the Registrar manufacturer authorized signing
      authority indicating that the bootstrapping event has been
      successfully logged.  This has been referred to MASA is
   still HTTPS.

6.4.  Registrar Requests as an
      "authorization token" indicating that it authorizes bootstrapping
      to proceed.

   Ownership Voucher  A signed voucher from MASA

   There are no change from BRSKI, the vendor vouching that a
      specific domain "owns" the new entity as defined in
      [I-D.ietf-anima-voucher].

   MIC  manufacturer installed certificate.  An [ieee802-1AR] identity.
      Not to be confused with a (cryptographic) "Message Integrity
      Check"

1.3.  Scope of solution

   The solution described in this step document is appropriate to enrolling
   between two non-
   constrained devices.

   The format of the voucher is COSE, which implies changes hundreds to both the
   Registrar and the MASA, but semantically the content is hundreds of thousands of diverse devices into a
   network without any prior contact with the same. devices.  The format of devices
   could be shipped by the voucher is COSE, which implies changes manufacturer directly to both the
   Registrar and customer site
   without ever being seen by the MASA, but semantically operator of the content is network.  As described
   in BRSKI, in the same.

   The manufacturer will know what algorithms are supported by audit-mode of operation the
   pledge, and device will issue a 406 (Conflict) error to the Registrar if the
   Registar's public key format is not supported be claimed
   by the pledge.  It is
   however, too late for first network that sees it.  In the Registar to use a different key, but at
   least it can log a reason for tracked owner mode of
   operation, sales channel integration provides a failure.  It is likely strong connection
   that the ZSJ-
   BRSKI-EST connection has already failed, and this step operator of the network is never
   reached.

6.4.1.  MASA renewal the legitimate owner of expired vouchers

   There are assumed to be no useful real-time clocks on constrained
   devices, so all vouchers are in effect infinite duration.  Pledges
   will use nonces for freshness, and the
   device.

   BRSKI describes a request more general, more flexible approach for
   bootstrapping devices into an ISP or Enterprise network.

   [I-D.ietf-6tisch-minimal-security] provides an extremely streamlined
   approach to enrolling from hundreds to thousands of devices into a new voucher with
   network, provided that a
   new voucher for unique secret key can be installed in each
   device.

1.4.  Leveraging the same Registrar new key infrastructure / next steps

   In constrained networks, it is unlikely that an ACP be formed.  This
   document does not unusual.  A token-bucket
   system preclude such a thing, but it is not mandated.

   The resulting secure channel SHOULD be used just to distribute
   network-wide keys using a protocol such that no as
   [I-D.ietf-6tisch-minimal-security].

   As a more than 24 vouchers are issued
   per-day, complex, but but more than one voucher can secure alternative the resulting
   secure channel MAY be issued instead used to do an enrollment of an LDevID
   as in BRSKI.  The resulting certificate is used to do per-pair keying
   such as described by {{ieee802159}.

   XXX - this document does not yet provide a one hour
   period.  Tokens way to signal which mode
   the pledge should not accumulate do.

1.4.1.  Key Distribution Process

   In addition to being used for more than one day!

6.4.2.  MASA verification the initial enrollment process, the
   secure channel SHOULD be kept open to use for network rekeying.  The
   CoJP protocol described in [I-D.ietf-6tisch-minimal-security]
   includes a mechanism for rekeys in section 8.4.3.1.

2.  Architectural Overview

   Section 2 of BRSKI has a diagram with all of voucher-request signature consistency

   The voucher-request is signed by the Registrar using it's Raw Public
   Key. components shown
   together.  There is are no additional certificate authority significant changes to sign this key. the diagram.

   The MASA MAY have this key via sales-channel integration, but use of a circuit proxy is not desireable.  The CoAP based
   stateless proxy mechanism described in most
   cases it will
   [I-D.ietf-6tisch-minimal-security] section 7.1 MUST be seeing the key for the first time.

   XXX-should the TLS connection from Registrar to MASA have used.

2.1.  Behavior of a
   ClientCertificate?  If so, then should it use the same Public Key?
   Or Pledge

   The pledge goes through a different one?

6.4.3.  MASA authentication series of registrar (certificate)

   IDEA: The steps which are outlined here at
   a high level.

                +--------------+
                |   Factory    |
                |   default    |
                +------+-------+
                       |
                +------v-------+
                | (1) Discover |
   +------------>              |
   |            +------+-------+
   |                   |
   |            +------v-------+
   |            | (2) Identity |
   ^------------+              |
   | rejected   +------+-------+
   |                   |
   |            +------v-------+
   |            | (3) Request  |
   |            |     Join     |
   |            +------+-------+
   |                   |
   |            +------v-------+
   |            | (4) Imprint  |
   ^------------+              |
   | Bad MASA SHOULD pin   +------+-------+
   | response          |  send Voucher Status Telemetry
   |            +------v-------+
   |            | (5) Enroll   |
   ^------------+              |
   | Enroll     +------+-------+
   | Failure           |
   |            +------v-------+
   |            | (6) Enrolled |
   ^------------+              |
    Factory     +--------------+
    reset

   State descriptions for the Raw Public Key (RPK) pledge are as follows:

   1.  Discover a communication channel to a Registrar.  This is done by
       listening for beacons as described by
       [I-D.richardson-anima-6join-discovery]

   2.  Identify itself.  This is done by presenting an X.509 IDevID
       credential to the IP address
   that was first used to make a request with it.  Should discovered Registrar (via the RPK <-> IP
   address relationship be 1:1, 1:N, N:1?  Should we take IP address to
   mean, "IP subnet", essentially Proxy) in the IPv4/24, and IPv6/64?
       EDHOC handshake.  The value
   of doing is about DDoS mitigation?

   Should above mapping certificate MAY be on a per-Pledge basis?

6.4.4.  MASA revocation checking of registrar (certificate)

   As the presented by reference.
       (The Registrar has credentials are only provisionally accepted at
       this time).

       The registrar identifies itself using a Raw Public Key as raw public key, while the
       the pledge identifies itself to the registrar using an identity, there is no
   meaningful standard revocation checking IDevID
       credential.

   3.  Requests to Join the discovered Registrar.  A unique nonce SHOULD
       be included ensuring that any responses can be done.  The MASA
   SHOULD have a blacklist table, and a way to add entries, but associated with
       this
   process is out of scope.

6.4.5.  MASA particular bootstrapping attempt.

   4.  Imprint on the Registrar.  This requires verification of pledge prior-signed-voucher-request

   The MASA will know whether or not the
       vendor service (MASA) provided voucher.  A voucher contains
       sufficient information for the Pledge is capable to complete authentication
       of producing a Registrar.  The voucher is signed voucher-request for inclusion by the Registrar.  In vendor (MASA) using
       a raw public key, previously installed into the case
   where pledge at
       manufacturing time.

   5.  Optionally Enroll.  By accepting the domain specific information
       from a Registrar, and by obtaining a domain certificate from a
       Registrar using a standard enrollment protocol, e.g.  Enrollment
       over Secure Transport (EST) [RFC7030].

   6.  The Pledge is now a member of, and can sign the voucher-request to the Registrar, then be managed by, the Registrar domain
       and will have put only repeat the discovery aspects of bootstrapping if it
       is returned to factory default settings.

2.2.  Secure Imprinting using Vouchers

   As in the 'prior-signed-voucher-request'. BRSKI, there is a voucher mechanism based upon [RFC8366].  The MASA can verify the signature from the Pledge using the MASA's
   copy
   format and cryptographic mechansim of the Pledge's IDevID public key.

   In many cases, the Pledge will not be capable of doing signatures constrained vouchers is
   described in
   real time, so no 'prior-signed-voucher-request' will be present.  The
   MASA will have rely on the audit log as a history function to
   determine if the Pledge has previously been claimed, detail in [I-D.ietf-anima-constrained-voucher].

   COSE signed vouchers and to identify
   situations where voucher-requests are MANDATORY.

2.3.  Initial Device Identifier

   The essential component of the claim from zero-touch operation is that the Registrar
   pledge is fraudulent.

6.4.6.  MASA pinning of registrar

   When provisioned with an 802.1AR (PKIX) certificate installed
   during the MASA creates manufacturing process.

   It is expected that constrained devices will use a voucher, it puts signature
   algorithm corresponding to the Registrar's Raw Public
   Key into hardware acceleration that they have,
   if they have any.  The anticipated initial algorithms are the 'pinned-domain-subject-public-key-info' leaf of ECDSA
   P-256 (secp256v1).  Newer devices SHOULD begin to appear using EdDSA
   curves using the
   voucher. 25519 curves.

   The MASA does not include the 'pinned-domain-cert' field.

6.4.7.  MASA nonce handling

   Use of nonces is highly RECOMMENDED, but there are situations where
   not all components manufacturer will always know what algorithms are connected at the same time available in which
   the nonce Pledge, and will not use an appropriate one.  The other components
   that need to evaluate the IDevID (the Registrar and MASA) are
   expected to support all common algorithms.

   The JRC is expected to be present. an easily updated appliance that can learn
   about new algorithms with a regular maintenance cycle.

   There are no significant changes from BRSKI.

6.5.  MASA Voucher Response

   As exaplained in [I-D.ietf-anima-constrained-voucher] section 6.3.2,
   when a voucher is returned by the MASA number of simplications detailed later on in this
   document designed to eliminate the JRC, a public key or
   certificate container that will verify need for an ASN.1 parser in the voucher SHOULD also be
   returned.

   In order
   pledge.

   The pledge should consider it's 802.1AR certificate to do this, the MASA MAY return a multipart/mixed return,
   within that body, two items SHOULD be returned:

   1.  An application/voucher-cose+cbor body.

   2.  An application/pkcs7-mime; smime-type=certs-only, or an
       application/SOMETHING containing a Raw Public Key.

   A MASA is not obligated opaque
   blob of bytes, to be inserted into protocols at appropriate places.
   The pledge SHOULD have access to return the underlying public key, and MAY return only
   the application/voucher-cose+cbor object.  In that case, private
   keys in the JRC will
   be unable to validate it.

6.5.1.  Pledge voucher verification most useable native format for computation.

   The Pledge receives the voucher from the Registrar over it's CoAP
   connection.  It verifies pledge MUST have the signature using public key of the MASA anchor built
   in, as in a
   manufacturer time.  This protocol optimizes for network bandwidth,
   and does not transfer the BRSKI case.

6.5.2.  Pledge authentication of provisional TLS connection

   The BRSKI process uses the pinned-domain-cert field of the voucher public key or certificate chain used to
   validate the registrar's ServerCertificate.  In voucher in-band.

   This is a seemingly identical requirement as for BRSKI, but rather
   than being an abstract trust anchor that can be augmented with a
   certificate chain, the pledge MUST be provided with the ZeroTouch case, Raw Public
   Key that the voucher MASA will contain use to sign vouchers for that pledge.

   This use of a pinned-domain-subject-public-key-info
   field containing the raw public direct key has drawbacks, section Section 9.1 addresses
   some of the certificate.  It should
   match, byte-to-byte them with some operational suggestions.

   BRSKI places some clear requirements upon the contents of the IDevID,
   but leaves the exact origin of the raw public key ServerCertificate.

6.6.  Pledge Voucher Status Telemetry

   The voucher status telemetry report is communicated from serial-number open.  This
   document restricts the pledge process to being the registrar over CoAP channel. hwSerialNum OCTET STRING.
   As CWT can handle binary formats, no base64 encoding is necessary.

   The shortened MASA-URL extension MANDATORY.  The inclusion of a MUD URL
   [RFC8520] is as
   described in table QQQ.

6.7. strongly recommended.

   EDNOTE: here belongs text about sending only a reference to the
   IDevID rather than the entire certificate

2.4.  Protocol Flow

   This diagram from BRSKI is reproduced with some edits:

    +--------+         +---------+    +------------+     +------------+
    | Pledge |         | IPIP    |    | Domain     |     | Vendor     |
    |        |         | Proxy   |    | Registrar  |     | Service    |
    |        |         |         |    | (JRC)      |     | (MASA)     |
    +--------+         +---------+    +------------+     +------------+
      |                     |                   |                    |
      |<-RFC4862 IPv6 adr   |                   |                    |
      |                     |                   |                    |
      |<--------------------|                   |                    |
      | Enhanced Beacon     |                   |                    |
      |   periodic broadcast|                   |                    |
      |                     |                   |                    |
      |<------------------->C<----------------->|                    |
      |<--Registrar EDHOC server authentication-|                    |
    [PROVISIONAL accept of server RPK ]         |                    |
      P-------- client authentication---------->|                    |
      P                     |                   |                    |
      P---Voucher Request (include nonce)------>|                    |
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |              [accept device?]          |
      P                     |              [contact Vendor]          |
      P                     |                   |--Pledge ID-------->|
      P                     |                   |--Domain ID-------->|
      P                     |                   |--nonce------------>|
      P                     |                   |     [extract DomainID]
      P                     |                   |                    |
      P                     |                   |     [update audit log request

   There are no changes to the Registrar log]
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |                   |<-device audit log request.

6.7.1.  MASA log--|
      P                     |                   |<- voucher ---------|
      P                     |                   |                    |
      P                     |                   |                    |
      P                     |       [verify audit log response

   There are no and voucher]   |
      P                     |                   |                    |
      P<------voucher---------------------------|                    |
    [verify voucher ]       |                   |                    |
    [verify provisional cert|                   |                    |
      |                     |                   |                    |
      |<--------------------------------------->|                    |
      | Continue with EST-COAPS enrollment      |                    |
      | using now bidirectionally authenticated |                    |
      |                     |                   |                    |
      |<--------------------------------------->|                    |
      |  Use 6tisch-minimal-security join request                    |

   Noteable changes to the MASA audit log response.

6.7.2.  Registrar audit log verification

   There are are:

   1.  no changes to how the Registrar verifies the audit log.

6.8.  EST Integration for PKI bootstrapping

   TBD.

6.8.1.  EST Distribution of CA Certificates

   TBD.

6.8.2.  EST CSR Attributes

   In 6tisch, IPv4 support/options.

   2.  no Autonomic Control Plane will be created, so none of the
   criteria for SubjectAltname found in
   [I-D.ietf-anima-autonomic-control-plane] apply.

   The CSR Attributes request SHOULD NOT be performed.

6.8.3.  EST Client Certificate Request mDNS steps, 6tisch will use a certificate to:

   1.  to authenticate an 802.15.9 key agreement protocol.

   2.  to terminate an incoming DTLS or EDHOC key agreement as part of
       application data protection.

   It only uses Enhanced Beacon
   3.  nonce-full option is always mandatory

2.5.  Architectural Components

   The bootstrap process includes the following architectural
   components:

2.5.1.  Pledge

   The Pledge is recommended that the requested subjectAltName contain only device which is attempting to join.  Until the
   [RFC4514] hwSerialNum.

6.8.4.  Enrollment Status Telemetry

   There are no changes
   pledge completes the enrollment process, it has network connectivity
   only to the status telemetry Proxy.

2.5.2.  Stateless IPIP Join Proxy

   The stateless CoAP provides CoAP connectivity between Registrar the pledge and
   MASA.

6.8.5.  Multiple certificates

   Multiple certificates are not supported.

6.8.6.  EST over
   the registrar.  The stateless CoAP

   This document proxy mechanism is described in
   [I-D.ietf-6tisch-minimal-security].

2.5.3.  Domain Registrar

   The Domain Registrar (having the formal name Join Registrar/
   Coordinator (JRC)), operates as a CMC Registrar, terminating the
   CoAP-EST and [I-D.ietf-ace-coap-est] detail how to run EST over
   CoAP.

6.9.  Use BRSKI connections.  The Registrar is manually configured
   or distributed with a list of Secure Transport for Minimal Join

   Rather than bootstrap trust anchors necessary to a public key infrastructure, authenticate
   any Pledge device expected on the secure
   channel MAY instead network.  The Registrar
   communicates with the Vendor supplied MASA to establish ownership.

   The JRC is typically located on the 6LBR/DODAG root, but it may be for
   located elsewhere, provided IP level connectivity can be established.
   The 6LBR may also provide a proxy or relay function to connect to the minimal security join process
   described
   actual registrar in [I-D.ietf-6tisch-minimal-security].

   The desire addition to do the IPIP proxy described above.  The
   existence of such an additional proxy is a minimal-security join process private matter, and this
   documents assumes without loss of generality that the registrar is
   co-located with the 6LBR.

2.5.4.  Manufacturer Service

   The Manufacturer Service provides two logically seperate functions:
   the Manufacturer Authorized Signing Authority (MASA), and an
   ownership tracking/auditing function.  This function is signaled by the
   Registrar in it's voucher-request identical to
   that used by including BRSKI, except that a 'join-process' value different format voucher is used.

2.6.  Certificate Time Validation
2.6.1.  Lack of 'minimal'.  The MASA copies this value into realtime clock

   For the voucher that constrained situation it is
   creates, and also logs this assumed that devices have no real
   time clock.  These nodes do have access to a monotonically increasing
   clock that will not go backwards in the audit log.

   When form of the secure channel was created with EDHOC, then Absolute Sequence
   Number.  Synchronization to the keys setup
   by EDHOC are simply used by OSCORE exactly as if they had been Pre-
   Shared. ASN is required in order to transmit/
   receive data and most nodes will maintain it in hardware.

   The keys derived by EDHOC heuristic described in BRSKI under this section SHOULD be stored by both Registrar
   and Pledge as their long term key should applied
   if there are dates in the join process need to be
   repeated.

7.  Reduced security operational modes

   This document defines COSE format voucher.

   Voucher requests SHOULD include a specific reduced security operational mode,
   specifically:

   1.  X

   2.  Y

   3.  Z

7.1.  Trust Model

   TBD

7.2.  Pledge security reductions

   TBD

7.3. nonce.  For devices intended for
   off-line deployment, the vouchers will have been generated in advance
   and no nonce-ful operation will not be possible.

2.7.  Cloud Registrar security reductions

   TBD

7.4.

   In 6tisch, the pledge never has network connectivity until it is
   enrolled, so no alternate registrar is ever possible.

2.8.  Determining the MASA security reductions

   TBD

8.  IANA Considerations

   XXX

8.1.  Well-known EST registration

   XXX

8.2.  PKIX Registry

   TBD

8.3.  Voucher Status Telemetry

   TBD

8.4.  DNS Service Names

   TBD

8.5.  MUD File Extension for to contact

   There are no changes from BRSKI: the MASA server

   TBD

9.  Privacy Considerations

   [I-D.ietf-6lo-privacy-considerations] details IDevID provided by the pledge
   will contain a number of privacy
   considerations important MASA URL extension.

3.  Voucher-Request artifact

   The voucher-request artifact is defined in Resource Constrained nodes.  There
   [I-D.ietf-anima-constrained-voucher] section 6.1.

   For the 6tisch ZSJ protocol defined in this document, only COSE
   signed vouchers as described in [I-D.ietf-anima-constrained-voucher]
   section 6.3.2 are
   two networks and three sets supported.

4.  Proxying details (Pledge - Proxy - Registrar)

   The voucher-request artifact is defined in
   [I-D.ietf-anima-constrained-voucher].

   The 6tisch use of the constrained nodes to consider.  They
   are: version differs from the non-
   constrained version in two ways:

   1.  it does not include the production nodes on proximity-registrar-cert, but rather uses
       the production network. proximity-registrar-subjet-public-key-info entry.  This
       accomodates the use of a raw public key to identify the
       registrar.

   2.  the new
   pledges, which have yet pledge uses the proximity-registrar-subject-public-key-info
       to enroll, verify the raw public key for the JRC.

   An appendix of [I-D.ietf-anima-constrained-voucher] shows example
   requests and which are on a join network.
   3. responses.

5.  Proxy details

   The role of the Proxy is to facilitate communication.  In the
   constrained situation the production nodes which are also acting as proxy nodes.

9.1.  Privacy Considerations needs to be stateless as there is
   very little ram in constrained nodes, and none can be allocated to
   keep state for Production network

   The details an unlimited number of this are out potential pledges.

5.1.  Pledge discovery of scope for this document.

9.2.  Privacy Considerations for New Pledges

   New Pledges do not yet receive Router Advertisements with PIO
   options, and so configure link-local addresses only based upon
   layer-2 addresses using Proxy

   In BRSKI, the pledge discovers the proxy via use of a GRASP M_FLOOD
   messages sent by the normal SLAAC mechanisms proxy.  In 6tisch ZSJ, the existence of the
   proxy is announced by the Enhanced Beacon message described in
   [RFC4191].

   These link-local addresses are visible to any on-link eavesdropper
   (who
   [I-D.richardson-6tisch-enrollment-enhanced-beacon].  The proxy as
   described by [I-D.ietf-6tisch-minimal-security] section 10 is synchronized to the same Join Assistant), so regardless of
   what is chosen they can be seen.  This link-layer traffic is
   encapsulated by
   used in an identical fashion when EDHOC and OSCOAP are used.

5.2.  HTTPS proxy connection to Registrar

   HTTPS connections are not used between the Join Pledge, Proxy into IPIP and
   Registrar.  The Proxy relays CoAP packets and carried to does not interpret or
   terminate CoAP connections.

   HTTPS is still used between the
   JRC.  The traffic SHOULD never leave Registrar and MASA!

5.3.  Proxy discovery of Registrar

   In BRSKI, the operator's network, will be
   kept confidential proxy autonomically discovers the Registrar by
   listening for GRASP messages.

   In the layer-2 keys inside constrained network, the LLN.  As no outside
   traffic can enter proxies are optionally configured
   with the join network, to do any ICMP scanning as
   described address of the JRC by the Join Response in [I-D.ietf-6lo-privacy-considerations].

   The join process in
   [I-D.ietf-6tisch-minimal-security] section 9.3.2.  (As described herein requires in
   that some identifier
   meaningful to section, the network operator be communicated address of the registrar otherwise defaults to be
   that of the JRC.  The
   join request DODAG root)

   Whether or not a 6LR will announce itself as a possible Join Proxy is
   outside the scope of this document.

6.  Protocol Details (Pledge - Registrar - MASA)

   BRSKI is specified to run over HTTPS.  This document respecifies it
   to run over CoAP with this object occurs within either DTLS or EDHOC-provided OSCOAP security.

   BRSKI introduces the concept of a secured provisional state for EST.

   [I-D.ietf-ace-coap-est] specifies that CoAP channel,
   although specifies the link-local address configured by use of CoAP
   Block-Wise Transfer ("Block") [RFC7959] to fragment EST messages at
   the pledge will be
   visible application layer.

   As in either the [I-D.ietf-ace-coap-est], support for Observe CoAP stateless proxy option (section 5.1 of
   [I-D.ietf-6tisch-minimal-security]), or options
   [RFC7641] with BRSKI is not supported in the equivalent DTLS
   stateless proxy option (reference TBD).

   This need not be a manufacturer created EUI-64 as assigned by IEEE;
   it current BRSKI/EST
   message flows.

   Observe options could be another value with higher entropy and less interesting
   vendor/device information.  Regardless of what is chosen, it can be used to track where the device attaches.

   For most constrained device, network attachment occurs very
   infrequently, often only once in their lifetime, so tracking
   opportunities may be rare.  Once connected, by the long 8-byte EUI64
   layer-2 address is usually replaced with server to notify clients about a short JRC assigned 2-byte
   address.

   Additionally, during
   change in the enrollment process, a DTLS connection cacerts or
   EDHOC connection will csr attributes (resources) and might be created.  TLS1.3 will keep contents an
   area of future work.

   Redirection as described in [RFC7030] section 3.2.1 is NOT supported.

6.1.  BRSKI-EST (D)TLS establishment details

   6tisch ZSJ does not use TLS.  The connection is CoAP with EDHOC
   security.

6.1.1.  BRSKI-EST CoAP estasblishment details

   The details in the
   certificates transmitted private while TLS 1.2 will not.  If BRSKI document apply directly to use of DTLS.

   The registrar SHOULD authenticate itself with a raw public key.  A
   256 bit ECDSA raw public key is RECOMMENDED.  Pledges SHOULD support
   EDDSA keys if they contain hardware that supports doing so
   efficiently.

   TBD: the
   client certificate can be observed, then Pledge needs to signal what kind of Raw Public Key it
   supports before the device identity will Registrar sends its ServerCertificate.  Can SNI
   be
   visible used to passive observers in do this?

   The pledge SHOULD authenticate itself with the 802.11AR built-in IDevID
   certificate that
   is sent.

   Even when TLS 1.3 is used, an active attacker could collect the
   information by creating as a rogue proxy.

   The ClientCertificate.

6.1.2.  BRSKI-EST CoAP/EDHOC estasblishment details

   [I-D.selander-ace-cose-ecdhe] details how to use of a manufacturer assigned EUI64 (whether derived from IEEE
   assignment or created through another process during manufacturing
   time) is encouraged.

9.2.1.  EUI-64 derived address for join time IID EDHOC.  The IID used in the link-local address used during the join process
   be a vendor assigned EUI-64.  After the join process has concluded,
   the device SHOULD be assigned EDHOC
   description identifiers a unique randomly generated long
   address, party U (the initiator), and a unique short address (not based upon the vendor EUI-
   64) for use at link-layer address.  At that point, all layer-3
   content party V.
   The Pledge is encrypted by the layer-2 key.

9.3.  Privacy Considerations for Join Proxy

   TBD.

10.  Security Considerations

   TBD

10.1.  Security of MASA voucher signing key(s)

   TBD

11.  Acknowledgements

   Kristofer Pister helped with many non-IETF references.

12.  References

12.1.  Normative References

   [cullenCiscoPhoneDeploy]
              Jennings, C., "Transitive Trust Enrollment for Constrained
              Devices", 2012, <http://www.lix.polytechnique.fr/hipercom/
              SmartObjectSecurity/papers/CullenJennings.pdf>.

   [I-D.ietf-6lo-privacy-considerations]
              Thaler, D., "Privacy Considerations for IPv6 Adaptation
              Layer Mechanisms", draft-ietf-6lo-privacy-
              considerations-04 (work in progress), October 2016.

   [I-D.ietf-6tisch-minimal]
              Vilajosana, X., Pister, K., party U, and T. Watteyne, "Minimal
              6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work the JRC is the party V.

   The communication from the Pledge is via CoAP via the Join Proxy.
   The Join proxy relays traffic to the JRC, and using the mechanism
   described in progress), February 2017. [I-D.ietf-6tisch-minimal-security]
              Vucinic, M., Simon, J., Pister, K., and M. Richardson,
              "Minimal Security Framework for 6TiSCH", draft-ietf-
              6tisch-minimal-security-06 (work section 5.1.  This is
   designed so that the Join Proxy does not need to know if it is
   performing the one-touch enrollment described in progress), May 2018.

   [I-D.ietf-6tisch-terminology]
              Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
              "Terms Used
   [I-D.ietf-6tisch-minimal-security] or the zero-touch enrollment
   protocol described in IPv6 over this document.  A network could consist of a
   mix of nodes of each type.

   As generating ephemeral keys is expensive for a low-resource Pledge,
   the TSCH mode use of IEEE 802.15.4e",
              draft-ietf-6tisch-terminology-10 (work in progress), March
              2018.

   [I-D.ietf-ace-cbor-web-token]
              Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15
              (work a common E_U by the Pledge for multiple enrollment
   attempts (should the first turn out to be the wrong network) is
   encouraged.

   The first communication detailed in progress), March 2018. [I-D.ietf-ace-coap-est]
              Stok, P., Kampanakis, P., Kumar, S., Richardson, M.,
              Furuhed, M., and S. Raza, "EST over secure is to
   query the "/.well-known/core" resource to request the Link for EST.
   This is where the initial CoAP (EST-
              coaps)", draft-ietf-ace-coap-est-06 (work in progress),
              October 2018.

   [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-16 (work in progress), June 2018.

   [I-D.ietf-anima-constrained-voucher]
              Richardson, M., Stok, P., and P. Kampanakis, "Constrained
              Voucher Artifacts request is to sent.

   The JRC MAY replace it's E_V ephermal key on a periodic basis, or
   even for Bootstrapping Protocols", draft-
              ietf-anima-constrained-voucher-02 (work in progress),
              September 2018.

   [I-D.ietf-anima-grasp]
              Bormann, C., Carpenter, B., and B. Liu, "A Generic
              Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
              grasp-15 (work every communication session.

   The Pledge's ID_U is the Pledge's IDevID.  It is transmitted in progress), July 2017.

   [I-D.ietf-anima-voucher]
              Watsen, K., Richardson, M., Pritikin, M., an
   x5bag [I-D.schaad-cose-x509].  An x5u (URL) MAY be used.  An x5t
   (hash) MAY also be used and T. Eckert,
              "Voucher Profile would be the smallest, but the Registrar
   may not know where to find the Pledge's IDevID unless the JRC has
   been preloaded will all the IDevIDs via out-of-band mechanism.  It is
   impossible for Bootstrapping Protocols", draft-ietf-
              anima-voucher-07 (work in progress), January 2018.

   [I-D.ietf-core-comi]
              Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
              Management Interface", draft-ietf-core-comi-03 (work the Pledge to know if the JRC has been loaded in
              progress), June 2018.

   [I-D.ietf-core-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security such
   a way so x5t is discouraged for Constrained RESTful Environments
              (OSCORE)", draft-ietf-core-object-security-15 (work general use.

   The JRC's ID_V is the JRC's Raw Public Key. It is transmitted as a
   key in
              progress), August 2018.

   [I-D.ietf-core-yang-cbor]
              Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
              Minaburo, "CBOR Encoding COSE's YYY parameter.

   The initial Mandatory to Implement (MTI) of Data Modeled with YANG",
              draft-ietf-core-yang-cbor-07 (work in progress), September
              2018.

   [I-D.ietf-netconf-keystore]
              Watsen, K., "YANG Data Model for an HKDF of SHA2-256, an
   AEAD based upon AES-CCM-16-64-128, a Centralized Keystore
              Mechanism", draft-ietf-netconf-keystore-06 (work in
              progress), September 2018.

   [I-D.richardson-6tisch-enrollment-enhanced-beacon]
              Dujovne, D. signature verification of
   TBD:BBBB, and M. Richardson, "IEEE802.15.4 Informational
              Element encapsulation signature generation of 6tisch Join TBD:BBBB.  The Pledge proposes
   a set of algorithms that it supports, and Enrollment
              Information", draft-richardson-6tisch-enrollment-enhanced-
              beacon-01 (work in progress), April 2018.

   [I-D.richardson-6tisch-join-enhanced-beacon]
              Dujovne, D. Pledge need not support
   more than one combination.

   JRCs are expected to run on non-constrained servers, and are expected
   to support the above initial as MTI, and M. Richardson, "IEEE802.15.4 Informational
              Element encapsulation of 6tisch Join Information", draft-
              richardson-6tisch-join-enhanced-beacon-03 (work in
              progress), January 2018.

   [I-D.richardson-6tisch-minimal-rekey]
              Richardson, M., "Minimal Security rekeying mechanism any subsequent ones that
   become common.

   A JRC SHOULD support all available algorithms for
              6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in
              progress), August 2017.

   [I-D.richardson-anima-6join-discovery]
              Richardson, M., "GRASP discovery a significant
   amount of Registrar by Join
              Assistant", draft-richardson-anima-6join-discovery-00
              (work in progress), October 2016.

   [I-D.schaad-cose-x509]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Headers time.

   Even when algorithms become weak or suspect, it is likely that it
   will still have to perform secure join for carrying and referencing X.509 certificates",
              draft-schaad-cose-x509-02 (work older devices.  A JRC that
   responds to such an older device might not in progress), July 2018.

   [I-D.selander-ace-cose-ecdhe]
              Selander, G., Mattsson, J., the end accept the
   device into the network, but it is important that it be able to audit
   the event and F. Palombini, "Ephemeral
              Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
              cose-ecdhe-10 (work communicate the event to an operator.

   While EDHOC supports sending additional data in progress), September 2018.

   [iec62591]
              IEC, ., "62591:2016 Industrial networks - Wireless
              communication the message_3, in the
   constrained network situation, it is anticipated that the size of the
   this message will already be large, and no additional data is to be
   sent.

   A COAP confirmable message SHOULD be used.

   [I-D.ietf-6tisch-minimal-security] section 6 details how to setup
   OSCORE context given a shared key derived by EDHOC.

   The registrar SHOULD authenticate itself with a raw public key.

   The pledge SHOULD authenticate itself with the built-in IDevID
   certificate.

6.2.  Pledge Requests Voucher from the Registrar

   The voucher request and communication profiles -
              WirelessHART", 2016,
              <https://webstore.iec.ch/publication/24433>.

   [ieee802-1AR]
              IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
              2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.

   [ieee802154]
              IEEE Standard, ., "802.15.4-2015 - IEEE Standard response as defined by BRSKI is modified
   slightly.

   In order to simplify the pledge, the use of a certificate (and chain)
   for Low-
              Rate Wireless Personal Area Networks (WPANs)", 2015,
              <http://standards.ieee.org/findstds/
              standard/802.15.4-2015.html>.

   [ieee802159]
              IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft
              Recommended Practice the Registrar is not supported.  Instead the newly defined
   proximity-registrar-subject-public-key-info must contain the (raw)
   public key info for Transport of Key Management
              Protocol (KMP) Datagrams", 2016,
              <http://standards.ieee.org/findstds/
              standard/802.15.9-2016.html>.

   [RFC2119]  Bradner, S., "Key words the Registrar.  It MUST be byte for use in RFCs byte
   identical to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): String Representation that which is transmitted by the Registrar during the
   TLS ServerCertificate handshake.

   BRSKI mandates that all voucher requests be signed.

6.3.  Registrar Requests Voucher from MASA

   There are no change from BRSKI, as this step is between two non-
   constrained devices.

   The format of Distinguished Names",
              RFC 4514, DOI 10.17487/RFC4514, June 2006,
              <https://www.rfc-editor.org/info/rfc4514>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., the voucher-request and voucher response is COSE, which
   implies changes to both the Registrar and the MASA, but semantically
   the content is the same.

   The manufacturer will know what algorithms are supported by the
   pledge, and will issue a 406 (Conflict) error to the Registrar if the
   Registar's public key format is not supported by the pledge.  It is
   however, too late for the Registar to use a different key, but at
   least it can log a reason for a failure.

   It is likely that the ZSJ-BRSKI-EST connection has already failed,
   and C.
              Bormann, "Neighbor Discovery Optimization this step is never reached.

6.3.1.  MASA renewal of expired vouchers

   There are assumed to be no useful real-time clocks on constrained
   devices, so all vouchers are in effect infinite duration.  Pledges
   will use nonces for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., freshness, and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

   [RFC7217]  Gont, F., "A Method a request for Generating Semantically Opaque
              Interface Identifiers a new voucher with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology a
   new voucher for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using the same Registrar is not unusual.

   A token-bucket system SHOULD be used such that no more than 24
   vouchers are issued per-day, but more than one voucher can be issued
   in a one hour period.  Tokens should not accumulate for more than one
   day.

6.3.2.  MASA verification of voucher-request signature consistency

   The voucher-request is signed by the Registrar using it's Raw Public
   Key.  There is no additional certificate authority to sign this key.
   The MASA MAY have this key via sales-channel integration, but in most
   cases it will be seeing the key for the first time.

   XXX-should the TLS connection from Registrar to MASA have a
   ClientCertificate?  If so, then should it use the same Public Key?
   Or a different one?

6.3.3.  MASA authentication of registrar (certificate)

   IDEA: The MASA SHOULD pin the Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <https://www.rfc-editor.org/info/rfc7250>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in Key (RPK) to the Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <https://www.rfc-editor.org/info/rfc7959>.

12.2.  Informative References

   [duckling]
              Stajano, F. IP address
   that was first used to make a request with it.  Should the RPK <-> IP
   address relationship be 1:1, 1:N, N:1?  Should we take IP address to
   mean, "IP subnet", essentially the IPv4/24, and R. Anderson, "The resurrecting duckling:
              security issues for ad-hoc wireless networks", 1999,
              <https://www.cl.cam.ac.uk/~fms27/
              papers/1999-StajanoAnd-duckling.pdf>.

   [I-D.ietf-ace-actors]
              Gerdes, S., Seitz, L., Selander, G., IPv6/64?  The value
   of doing is about DDoS mitigation?

   Should above mapping be on a per-Pledge basis?

6.3.4.  MASA revocation checking of registrar (certificate)

   As the Registrar has a Raw Public Key as an identity, there is no
   meaningful standard revocation checking that can be done.  The MASA
   SHOULD have a blacklist table, and C. Bormann, "An
              architecture for authorization in constrained
              environments", draft-ietf-ace-actors-07 (work a way to add entries, but this
   process is out of scope.

6.3.5.  MASA verification of pledge prior-signed-voucher-request

   The Registrar will put the signed pledge voucher-request into it's
   voucher-request as 'prior-signed-voucher-request'.  The MASA can
   verify the signature from the Pledge using the MASA's copy of the
   Pledge's IDevID public key.

6.3.6.  MASA pinning of registrar

   When the MASA creates a voucher, it puts the Registrar's Raw Public
   Key into the 'pinned-domain-subject-public-key-info' leaf of the
   voucher.

   The MASA does not include the 'pinned-domain-cert' field in
              progress), October 2018.

   [I-D.ietf-anima-autonomic-control-plane]
              Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
              Control Plane (ACP)", draft-ietf-anima-autonomic-control-
              plane-18 (work such
   vouchers.

6.3.7.  MASA nonce handling

   Use of nonces is highly RECOMMENDED, but there are situations where
   not all components are connected at the same time in progress), August 2018.

   [I-D.ietf-core-sid]
              Veillette, M. and A. Pelov, "YANG Schema Item iDentifier
              (SID)", draft-ietf-core-sid-04 (work which the nonce
   will not be present.

   There are no significant changes from BRSKI.

6.4.  MASA Voucher Response

   As exaplained in progress), June
              2018.

   [I-D.ietf-roll-useofrplinfo]
              Robles, I., Richardson, M., [I-D.ietf-anima-constrained-voucher] section 6.3.2,
   when a voucher is returned by the MASA to the JRC, a public key or
   certificate container that will verify the voucher SHOULD also be
   returned.

   In order to do this, the MASA MAY return a multipart/related return,
   within that body, two items SHOULD be returned:

   1.  An application/voucher-cose+cbor body.

   2.  An application/TBD:SOMETHING containing a Raw Public Key.

   A MASA is not obligated to return the public key, and P. Thubert, "When MAY return only
   the application/voucher-cose+cbor object.  In that case, the JRC will
   be unable to use
              RFC 6553, 6554 validate it, and IPv6-in-IPv6", draft-ietf-roll-
              useofrplinfo-23 (work will have to just audit the contents.

6.4.1.  Pledge voucher verification

   The Pledge receives the voucher from the Registrar over it's CoAP
   connection.  It verifies the signature using the MASA anchor built
   in, as in progress), May 2018.

   [ISA100]   "The Technology Behind the ISA100.11a Standard", June
              2010, <http://www.isa100wci.org/Documents/PDF/
              The-Technology-Behind-ISA100-11a-v-3_pptx>.

   [PFS]      Wikipedia, ., "Forward Secrecy", August 2016,
              <https://en.wikipedia.org/w/
              index.php?title=Forward_secrecy&oldid=731318899>.

   [pledge-word]
              Dictionary.com, ., "Dictionary.com Unabridged", 2015,
              <http://dictionary.reference.com/browse/pledge>.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <https://www.rfc-editor.org/info/rfc4191>.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC5056]  Williams, N., "On BRSKI case.

6.4.2.  Pledge authentication of provisional TLS connection

   The BRSKI process uses the pinned-domain-cert field of the voucher to
   validate the registrar's ServerCertificate.  In the Use of Channel Bindings to Secure
              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
              <https://www.rfc-editor.org/info/rfc5056>.

   [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
              IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in ZeroTouch case,
   the
              Internet voucher will contain a pinned-domain-subject-public-key-info
   field containing the raw public key of Things (IoT): Problem Statement", RFC 7554,
              DOI 10.17487/RFC7554, May 2015,
              <https://www.rfc-editor.org/info/rfc7554>.

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <https://www.rfc-editor.org/info/rfc7641>.

   [RFC7731]  Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
              and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
              February 2016, <https://www.rfc-editor.org/info/rfc7731>.

Appendix A.  Extra text certificate.  It should
   match, byte-to-byte with the raw public key ServerCertificate.

6.5.  Pledge Voucher Status Telemetry

   The following text voucher status telemetry report is communicated from previous versions of this document. the pledge
   to the registrar over CoAP channel.  The
   document has been re-organized shortened URL is as
   described in table QQQ.

6.6.  Registrar audit log request

   There are no changes to the Registrar audit log request.

6.6.1.  MASA audit log response

   There are no changes to the MASA audit log response.

6.6.2.  Registrar audit log verification

   There are no changes to match how the Registrar verifies the flow audit log.

6.6.3.  EST CSR Attributes

   In 6tisch, no Autonomic Control Plane will be created, so none of
   [I-D.ietf-anima-bootstrapping-keyinfra].

A.1.  Assumptions

A.1.1.  One-Touch Assumptions

   This document interacts with the one-touch solution described
   criteria for SubjectAltname found in
   [I-D.ietf-6tisch-minimal-security].

A.1.2.  Factory provided credentials (if any)

   When
   [I-D.ietf-anima-autonomic-control-plane] apply.

   The CSR Attributes request SHOULD NOT be performed.

6.6.4.  EST Client Certificate Request

   6tisch will use a manufacturer installed certificate is provided to:

   1.  to authenticate an 802.15.9 key agreement protocol.

   2.  to terminate an incoming DTLS or EDHOC key agreement as the IDevID,
   it SHOULD contain a number of fields.
   [I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set part of
   requirements.

   A manufacturer unique serial number MUST be provided in
       application data protection.

   It is recommended that the
   serialNumber SubjectAltName extension, and MAY be repeated in requested subjectAltName contain only the
   Common Name.
   [RFC4514] hwSerialNum.

6.6.5.  Enrollment Status Telemetry

   There are no sequential or numeric requirements on the
   serialNumber, it may be any unique value that the manufacturer wants
   to use.  The serialNumber SHOULD be printed on the packaging and/or
   on the device in a discrete way so that failures can be physically
   traced changes to the relevant device.

A.1.3.  Credentials status telemetry between Registrar and
   MASA.

6.6.6.  Multiple certificates

   Multiple certificates are not supported.

6.6.7.  EST over CoAP

   This document and [I-D.ietf-ace-coap-est] detail how to be introduced

   The goal run EST over
   CoAP.

6.7.  Use of the Secure Transport for Minimal Join

   Rather than bootstrap process is to introduce one or more new
   locally relevant credentials:

   1.  a certificate signed by a local certificate authority/registrar.
       This is the LDevID of [ieee802-1AR].

   2.  alternatively, a network-wide public key to be used to infrastructure, the secure L2
       traffic.

   3.  alternatively, a network-wide key to
   channel MAY instead be used for the minimal security join process
   described in [I-D.ietf-6tisch-minimal-security].

   The desire to authenticate per-
       peer keying of L2 traffic using do a mechanism such as provided by
       [ieee802159].

A.2.  Network Assumptions

   This document minimal-security join process is about enrollment of constrained devices [RFC7228] to signaled by the
   Registrar in it's voucher-request by including a constrained network.  Constrained networks 'join-process' value
   of 'minimal'.  The MASA copies this value into the voucher that is such as [ieee802154],
   creates, and in particular also logs this to the audit log.

   When the time-slotted, secure channel hopping (tsch) mode,
   feature low bandwidths, was created with EDHOC, then the keys setup
   by EDHOC are simply used by OSCORE exactly as if they had been Pre-
   Shared.  The keys derived by EDHOC SHOULD be stored by both Registrar
   and limited opportunities to transmit.  A Pledge as their long term key
   feature should the join process need to be
   repeated.

7.  IANA Considerations

   No specific requests are made

8.  Privacy Considerations

   [I-D.ietf-6lo-privacy-considerations] details a number of these networks is that receivers privacy
   considerations important in Resource Constrained nodes.  There are only listening at
   certain times.

A.2.1.  Security above and below IP

   802.15.4
   two networks have and three kinds sets of layer-2 security:

   o  a network key that is shared with all constrained nodes to consider.  They
   are: 1. the production nodes on the production network.  2. the new
   pledges, which have yet to enroll, and is used which are on a join network.
   3. the production nodes which are also acting as proxy nodes.

8.1.  Privacy Considerations for
      unicast and multicast. Production network

   The key may be used details of this are out of scope for privacy, and it
      may be used in some cases this document.

8.2.  Privacy Considerations for authentication New Pledges

   New Pledges do not yet receive Router Advertisements with PIO
   options, and so configure link-local addresses only (in based upon
   layer-2 addresses using the case of
      enhanced beacons).

   o  a series of network keys that normal SLAAC mechanisms described in
   [RFC4191].

   These link-local addresses are shared (agreed to) between pairs
      of nodes (the per-peer key)

   o  a network key that visible to any on-link eavesdropper
   (who is shared with all nodes (through a group key
      management system), and synchronized to the same Join Assistant), so regardless of
   what is used for multicast chosen they can be seen.  This link-layer traffic only, while
      a per-pair key is used for unicast traffic

   Setting up
   encapsulated by the credentials Join Proxy into IPIP packets and carried to bootstrap one of these kinds of
   security, (or directly configuring the key itself for the first case)
   is required.  This is
   JRC.  The traffic SHOULD never leave the security below operator's network, will be
   kept confidential by the IP layer.

   Security is required above layer-2 keys inside the IP layer: there are three aspects
   which LLN.  As no outside
   traffic can enter the credentials join network, to do any ICMP scanning as
   described in the previous section are [I-D.ietf-6lo-privacy-considerations].

   The join process described herein requires that some identifier
   meaningful to the network operator be used.

   o communicated to provide for secure connection the JRC.  The
   join request with this object occurs within a Path Computation Element
      [RFC4655], or other LLC (see ({RFC7554}} section 3).

   o  to initiate a connection between a Resource Server (RS) and an
      application layer Authorization Server (AS and CAS from
      [I-D.ietf-ace-actors]).

A.2.1.1.  Perfect Forward Secrecy

   Perfert Forward Secrecy (PFS) is secured CoAP channel,
   although the property of a protocol such that
   complete knowledge of link-local address configured by the crypto state (for instance, via a memory
   dump) at time X does not imply that data from a disjoint time Y can
   also pledge will be recovered.  ([PFS]).

   PFS is important for two reasons: one is that it offers protection
   against
   visible in either the compromise CoAP stateless proxy option (section 5.1 of a node.  It does this by changing the keys
   [I-D.ietf-6tisch-minimal-security]), or in a non-deterministic way. the equivalent DTLS
   stateless proxy option (reference TBD).

   This second property also makes need not be a manufacturer created EUI-64 as assigned by IEEE;
   it could be another value with higher entropy and less interesting
   vendor/device information.  Regardless of what is chosen, it much
   easier can be
   used to remove a node from track where the network, as any node which has not
   participated device attaches.

   For most constrained device, network attachment occurs very
   infrequently, often only once in their lifetime, so tracking
   opportunities may be rare.  Once connected, the key changing process long 8-byte EUI64
   layer-2 address is usually replaced with a short JRC assigned 2-byte
   address.

   Additionally, during the enrollment process, a DTLS connection or
   EDHOC connection will find itself no longer
   connected.

A.2.2.  Join network assumptions

   The network which be created.  TLS1.3 will keep contents of the new pledge
   certificates transmitted private while TLS 1.2 will connect to not.  If the
   client certificate can be observed, then the device identity will have be
   visible to have
   the following properties:

   o  a known PANID.  The PANID 0xXXXX where XXXX is passive observers in the assigned RFC#
      for this document 802.11AR IDevID certificate that
   is suggested.

   o  a minimal schedule with some Aloha time.  This sent.

   Even when TLS 1.3 is usually in the
      same slotframe as used, an active attacker could collect the Enhanced Beacon, but
   information by creating a pledge MUST listen
      for an unencrypted Enhanced Beacon to so that it can synchronize.

A.2.3.  Number and cost of round trips

   TBD.

A.2.4.  Size of packets, number rogue proxy.

   The use of fragments

   TBD

A.3.  Target end-state a manufacturer assigned EUI64 (whether derived from IEEE
   assignment or created through another process during manufacturing
   time) is encouraged.

8.2.1.  EUI-64 derived address for join process

   At time IID

   The IID used in the end of link-local address used during the zero-touch join process there will
   be a symmetric
   key protected channel between vendor assigned EUI-64.  After the Join Registrar/Coordinator and join process has concluded,
   the
   pledge, now known as a Joined Node.  This channel may device SHOULD be rekeyed via
   new exchange of asymmetric exponents (ECDH for instance),
   authenticated using the domain specific credentials created during assigned a unique randomly generated long
   address, and a unique short address (not based upon the join process.

   This channel vendor EUI-
   64) for use at link-layer address.  At that point, all layer-3
   content is encrypted by the layer-2 key.

9.  Security Considerations

   TBD

9.1.  Security of MASA voucher signing key(s)

   TBD

10.  Acknowledgements

   Kristofer Pister helped with many non-IETF references.

11.  References

11.1.  Normative References

   [cullenCiscoPhoneDeploy]
              Jennings, C., "Transitive Trust Enrollment for Constrained
              Devices", 2012, <http://www.lix.polytechnique.fr/hipercom/
              SmartObjectSecurity/papers/CullenJennings.pdf>.

   [I-D.ietf-6lo-privacy-considerations]
              Thaler, D., "Privacy Considerations for IPv6 Adaptation
              Layer Mechanisms", draft-ietf-6lo-privacy-
              considerations-04 (work in progress), October 2016.

   [I-D.ietf-6tisch-minimal-security]
              Vucinic, M., Simon, J., Pister, K., and M. Richardson,
              "Minimal Security Framework for 6TiSCH", draft-ietf-
              6tisch-minimal-security-11 (work in progress), June 2019.

   [I-D.ietf-6tisch-terminology]
              Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
              "Terms Used in IPv6 over the form of an OSCOAP protected connection with
   [I-D.ietf-core-comi] encoded objects.  This document includes
   definition of a [I-D.ietf-netconf-keystore] compatible objects for
   encoding TSCH mode of the relevant [I-D.ietf-anima-bootstrapping-keyinfra]
   objects.

Appendix B.  Join Protocol

   The pledge join protocol state machine is described IEEE 802.15.4e",
              draft-ietf-6tisch-terminology-10 (work in
   [I-D.ietf-6tisch-minimal-security], progress), March
              2018.

   [I-D.ietf-ace-coap-est]
              Stok, P., Kampanakis, P., Richardson, M., and S. Raza,
              "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap-
              est-12 (work in section XYZ.  The pledge
   recognizes that it is progress), June 2019.

   [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-22 (work in zero-touch configuration by the following
   situation:

   o  no PSK has been configured progress), June 2019.

   [I-D.ietf-anima-constrained-voucher]
              Richardson, M., Stok, P., and P. Kampanakis, "Constrained
              Voucher Artifacts for the network Bootstrapping Protocols", draft-
              ietf-anima-constrained-voucher-04 (work in which it has joined.

   o  the pledge has no locally defined certificate (no LDevID), only an
      IDevID.

   o  the network asserts an identity that the pledge does not
      recognize.

   All of these conditions MUST be true.  If any of these are not true,
   then the pledge has either been connected to the wrong network, or it
   has already been bootstrapped into a different network, progress), July
              2019.

   [I-D.ietf-anima-voucher]
              Watsen, K., Richardson, M., Pritikin, M., and it should
   wait until it finds that network.

   The zero-touch process consists of three stages:

   1.  the key agreement process

   2.  the provisional enrollment process
   3.  the key distribution process

B.1.  Key Agreement process

   The key agreement process is identical to
   [I-D.ietf-6tisch-minimal-security].  The process uses EDHOC with
   certificates.

   The pledge will have to trust the JRC provisionally, as described T. Eckert,
              "Voucher Profile for Bootstrapping Protocols", draft-ietf-
              anima-voucher-07 (work in progress), January 2018.

   [I-D.ietf-core-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", draft-ietf-core-object-security-16 (work in
   [I-D.ietf-anima-bootstrapping-keyinfra], section 3.1.2,
              progress), March 2019.

   [I-D.richardson-6tisch-enrollment-enhanced-beacon]
              Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational
              Element encapsulation of 6tisch Join and Enrollment
              Information", draft-richardson-6tisch-enrollment-enhanced-
              beacon-01 (work in
   section 4.1.1 progress), April 2018.

   [I-D.richardson-6tisch-join-enhanced-beacon]
              Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational
              Element encapsulation of [RFC7030].

   The JRC will be able to validate the IDevID 6tisch Join Information", draft-
              richardson-6tisch-join-enhanced-beacon-03 (work in
              progress), January 2018.

   [I-D.richardson-anima-6join-discovery]
              Richardson, M., "GRASP discovery of the pledge using the
   manufacturer's CA.

   The pledge may not know if it is Registrar by Join
              Assistant", draft-richardson-anima-6join-discovery-00
              (work in a zero-touch or one-touch
   situation: the pledge may be able to verify the JRC based upon trust
   anchors that were installed at manufacturing time.  In that case, the
   pledge runs the simplified one-touch process.

   The pledge signals progress), October 2016.

   [I-D.schaad-cose-x509]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Headers for carrying and referencing X.509 certificates",
              draft-schaad-cose-x509-03 (work in the EDHOC message_2 if it has accepted the JRC
   certificate.  The JRC will progress), December
              2018.

   [I-D.selander-ace-cose-ecdhe]
              Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
              Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
              cose-ecdhe-13 (work in general, not trust the pledge with the
   network keys until it has provided the pledge with a voucher.  The
   pledge will notice the absence of the provisioning keys.

   XXX progress), March 2019.

   [iec62591]
              IEC, ., "62591:2016 Industrial networks - there could be some disconnect here.  May need additional
   signals here.

B.2.  Provisional Enrollment process

   When the pledge determines that it can not verify the certificate of
   the JRC using built-in trust anchors, then it enters a provisional
   state.  In this state, it keeps the channel created by EDHOC open.

   A new EDHOC key derivation is done by the JRC Wireless
              communication network and pledge using a new
   label, "6tisch-provisional".

   The pledge runs as a passive CoMI server, leaving the JRC to drive
   the enrollment process.  The JRC can interrogate the pledge communication profiles -
              WirelessHART", 2016,
              <https://webstore.iec.ch/publication/24433>.

   [ieee802-1AR]
              IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
              2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.

   [ieee802154]
              IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low-
              Rate Wireless Personal Area Networks (WPANs)", 2015,
              <http://standards.ieee.org/findstds/
              standard/802.15.4-2015.html>.

   [ieee802159]
              IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft
              Recommended Practice for Transport of Key Management
              Protocol (KMP) Datagrams", 2016,
              <http://standards.ieee.org/findstds/
              standard/802.15.9-2016.html>.

   [RFC2119]  Bradner, S., "Key words for use in a
   variety RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): String Representation of fashions as shown below: the process terminates when the
   JRC provides the pledge with an ownership voucher Distinguished Names",
              RFC 4514, DOI 10.17487/RFC4514, June 2006,
              <https://www.rfc-editor.org/info/rfc4514>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <https://www.rfc-editor.org/info/rfc7250>.

   [RFC7252]  Shelby, Z., Hartke, K., and the pledge
   leaves the provisional state.

   A typical interaction involves the following requests:

       +-----------+ +----------+ +-----------+ +----------+
       |           | |          | | Circuit   | | New      |
       |  Vendor   | | Registrar| |  Proxy    | | Entity   |
       |  (MASA)   | |          | |           | |          |
       ++----------+ +--+-------+ +-----------+ +----------+
        |               |     GET  request voucher       |
        |               |-------------------------------->
        |               <----------voucher-token---------|
        |/requestvoucher|                                |
        <---------------+                                |
        +--------------->                                |
        |/requestlog    |                                |
        <---------------+                                |
        +--------------->                                |
        |               |        POST voucher            |
        |               |-------------------------------->
        |               <------------2.05 OK ------------+
        |               |                                |
        |               |        POST csr attributes     |
        |               |-------------------------------->
        |               <------------2.05 OK ------------+
        |               |                                |
        |               |        GET  cert request       |
        |               |-------------------------------->
        |     ????      <------------2.05 OK ------------+
        |<--------------|              CSR               |
        |-------------->|                                |
        |               |        POST certificate        |
        |               |-------------------------------->
        |               <------------2.05 OK ------------+
        |               |                                |

Appendix C.  IANA Considerations

   This document allocates one value from the subregistry "Address
   Registration Option Status Values": ND_NS_JOIN_DECLINED Join
   Assistant, JOIN DECLINED (TBD-AA)

Appendix D.  Protocol Definition

D.1.  Discovery

   Only IPv6 operations using Link-Local addresses are supported.  Use
   of a temporary address is NOT encouraged as the critial resource on
   the Proxy device is the number of Neighbour Cache Entries that can be
   used for untrusted pledge entries.

D.1.1.  Proxy Discovery Bormann, "The Constrained
              Application Protocol Details

   The Proxy is discovered using the enhanced beacon defined (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
   [I-D.richardson-6tisch-join-enhanced-beacon].

D.1.2.  Registrar Discovery Protocol Details

   The Registrar is not discovered by the Proxy.  Any device that is
   expected to be able to operate as a Registrar MAY be told the address
   of the Registrar when that device joins
              the network.  The address MAY
   be included Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <https://www.rfc-editor.org/info/rfc7959>.

   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "A Voucher Artifact for Bootstrapping Protocols",
              RFC 8366, DOI 10.17487/RFC8366, May 2018,
              <https://www.rfc-editor.org/info/rfc8366>.

11.2.  Informative References

   [I-D.ietf-anima-autonomic-control-plane]
              Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
              Control Plane (ACP)", draft-ietf-anima-autonomic-control-
              plane-19 (work in the [I-D.ietf-6tisch-minimal-security] Join Response.
   If the address is NOT included, then Proxy may assume that the
   Registrar can be found at the DODAG root, which is well known progress), March 2019.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <https://www.rfc-editor.org/info/rfc4191>.

   [RFC7641]  Hartke, K., "Observing Resources in the
   6tisch's use of the RPL protocol. Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <https://www.rfc-editor.org/info/rfc7641>.

   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
              Description Specification", RFC 8520,
              DOI 10.17487/RFC8520, March 2019,
              <https://www.rfc-editor.org/info/rfc8520>.

Author's Address

   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca