[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            E. Lear
Internet-Draft                                                  O. Friel
Intended status: Standards Track                           Cisco Systems
Expires: April 23, 2019                                 October 20, 2018

             Proof of Possession to Devices for Onboarding


   This memo specifies a RESTful interface for local deployments to
   demonstrate proof of possession to a device or to a manufacturer
   authorized signing authority (MASA).  This covers the case where a
   MASA would not otherwise have knowledge of where a device is
   deployed, or when a MASA may not be required.  Such knowledge is
   important to onboard certain classes of devices, such as those on
   IEEE 802.11 networks.

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 23, 2019.

Copyright Notice

   Copyright (c) 2018 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

Lear & Friel             Expires April 23, 2019                 [Page 1]

Internet-Draft             Proof of Posession               October 2018

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Yang Model  . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Changes from Earlier Versions . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) specifies a means to
   provision credentials to be used as credentials to operationally
   access networks.  In the initial model, the manufacturer authorized
   signing authority is assumed to either have knowledge of whether a
   device is intended to be provisioned on a particular network, or to
   be able to simply sign all requests.  The necessary knowledge to
   handle the first case is not always easy to come by, and particularly
   useful to have when a device is trying to determine which network to
   join, when there is a choice.  Such is the case with IEEE 802.11
   networks, for example.

   Absent that knowledge, should a MASA automatically issue a voucher,
   the device may onboard to the first BRSKI-aware network, which may
   well be the wrong one.

   In addition, some manufacturers may prefer not to require the
   existence of a MASA.  In these circumstances proof of possession to
   the device is required.

   This memo specifies a RESTful request that devices and registrars
   employ as an alternative to [I-D.ietf-anima-bootstrapping-keyinfra],
   in which two additional optional objects may be specified.  Three new
   objects are defined:

   1.  A simple binary claim that registrar administrator knows this
       device to belong on the particular deployment network.  This
       object should be conveyed from the registrar to the MASA.

   2.  A cryptographic claim as such.  This would typically be some sort
       of scanned label or information received as part of a bill of
       materials that contains some signed evidence of delivery of the

Lear & Friel             Expires April 23, 2019                 [Page 2]

Internet-Draft             Proof of Posession               October 2018

       end device to the deployment.  This option may be conveyed from
       the register to the MASA, or when the MASA needn't be contacted,
       to the device.

   3.  A statement indicating that the MASA server needn't be contacted
       at all, and that the device will accept a certificate with the
       cryptographic claim specified in this memo.  This permits offline

   Note that this interface is optional.  There may well be cases where
   a MASA already has sufficient knowledge to onboard a device to the
   correct network.  Particularly where the manufacturer requires online
   registration, when such integration exists, the mechanisms defined in
   this memo SHOULD NOT be used, as they would be superfluous.

   When this model is used, in order to avoid any interoperability
   problems, a new RESTful endpoint is defined as follows:


   The new endpoint is handled precisely as described in Section 5.2 of
   [I-D.ietf-anima-bootstrapping-keyinfra], with the exception voucher
   is formed as described below in Section 2.

   If the device has indicated that the MASA server needn't be
   contacted, then the registrar may generate an unsigned voucher
   response.  However, in this case, the registrar must include a valid
   claim object that has been hashed with an 8-32 bit nonce, immediately
   succeeded by a non-NULL-terminated key that is provided in UTF8
   format.  The response MUST be a voucher-brski-pop-request-artifact
   rather than a voucher-artifact.

2.  The Yang Model

<CODE BEGINS>file "ietf-brski-possession@2018-10-11.yang"
module ietf-brski-possession {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-brski-possession";
  prefix mr;

  import ietf-restconf {
    prefix rc;
      "This import statement is only present to access
       the yang-data extension defined in RFC 8040.";
    reference "RFC 8040: RESTCONF Protocol";
  import ietf-voucher {

Lear & Friel             Expires April 23, 2019                 [Page 3]

Internet-Draft             Proof of Posession               October 2018

    prefix v;
    description "This module defines the format for a voucher,
        which is produced by a pledge's manufacturer or
        delegate (MASA) to securely assign a pledge to
        an 'owner', so that the pledge may establish a secure
        conn ection to the owner's network infrastructure";

    reference "RFC 8366: Voucher Profile for Bootstrapping Protocols";

  import ietf-voucher-request {
    prefix rv;
      "Voucher request is what we will augment";
    reference "draft-ietf-anima-bootstrapping-keyinfra";

    "Author: Eliot Lear
    "This module to provide additional information about
     how a device may be claimed by a particular deployment.
     The owner is asserting that this information has not merely
     been gleaned  directly in-band from the device,
     but rather he or she can confirm ownership independently.

     Copyright (c) 2018 IETF Trust and the persons identified as
     authors of the code. All rights reserved.

     Redistribution and use in source and binary forms, with or without
     modification, is permitted pursuant to, and subject to the license
     terms contained in, the Simplified BSD License set forth in Section
     4.c of the IETF Trust's Legal Provisions Relating to IETF Documents

     This version of this YANG module is part of RFC XXXX; see the RFC
     itself for full legal notices.";

  revision 2018-10-11 {
      "Initial version";
    reference "RFC XXXX: Proof of possession for BRSKI";
  rc:yang-data voucher-brski-pop-request-artifact {
    uses rv:voucher-request-grouping {

Lear & Friel             Expires April 23, 2019                 [Page 4]

Internet-Draft             Proof of Posession               October 2018

      augment "voucher" {
          "trying to add one more thing into this voucher.";
        leaf out-of-band-claim {
          when 'not(../no-masa-required) and not(../possession-claim)';
          type binary;
            "If this value is true, then the adminsitrator of the
             registrar is claiming that the device being claimed
             has been purchased or otherwise acquired for this
             deployment, and that the information has not merely
             been automatically gleaned directly from the device.";
        leaf possession-claim {
          when 'not(../no-masa-required) and not(../out-of-band-claim)';
          type string;
            "In the context of a voucher-request, this node contains
             a naked key that the MASA will validate.  If valid, the
             MASA will sign a voucher.  The form of this key is left
             to the manufacturer, and is opaque to the registrar";
        leaf no-masa-required {
          when 'not(../possession-claim)and not(../out-of-band-claim)';
          type binary;
            "If true, then the device will not bother to validate
             the provisional TLS connection, but instead assume it
             to be valid.  Only the pledge may set this value.
             The registrar MUST have included the possession-claim
  rc:yang-data voucher-with-pop-artifact {
    uses v:voucher-artifact-grouping {
      refine "voucher/pinned-domain-cert" {
        mandatory false;
      refine "voucher/assertion" {
        mandatory false;
      augment "voucher" {
          "Add leaf node for returning a hashed proof of

Lear & Friel             Expires April 23, 2019                 [Page 5]

Internet-Draft             Proof of Posession               October 2018

          leaf hashed-proof-of-possession {
            type binary;
            mandatory true;
              "A hash of the provided nonce and a key obtained
               by the registrar.  The format is the nonce followed
               immediately by the key.";

          leaf hash-type {
             type enumeration {
               enum SHA256 {
                   "The type of hash is SHA256.";
               "If not present, assume SHA256.  Otherwise, whatever
                augmented value is present.  This is for algorithmic


3.  Examples


4.  IANA Considerations

   The following YANG name space should be registered:

   o  "urn:ietf:params:xml:ns:yang:ietf-brski-possession"

5.  Security Considerations

   There will be many.

6.  Acknowledgments

   None yet.

Lear & Friel             Expires April 23, 2019                 [Page 6]

Internet-Draft             Proof of Posession               October 2018

7.  Changes from Earlier Versions

   Draft -00:

   o  Initial revision

8.  Normative References

              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.

Authors' Addresses

   Eliot Lear
   Cisco Systems
   Richtistrasse 7
   Wallisellen  CH-8304

   Phone: +41 44 878 9200
   Email: lear@cisco.com

   Owen Friel
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA  95134
   United States

   Email: ofriel@cisco.com

Lear & Friel             Expires April 23, 2019                 [Page 7]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/