Constrained Voucher Profile for Bootstrapping Protocols

Enrollment of new nodes into constrained networks with constrained nodes present unique challenges. There are bandwidth and code space issues to contend. A solution such as may be too large in terms of code space or bandwidth required. This document defines a constrained version of . Rather than serializing the YANG definition in JSON, it is serialized into CBOR (). This document follows a similar, but not identical structure as . Some sections are left out entirely. The CBOR definitions for this constrained voucher format are defined using the mechanism describe in using the SID mechanism explained in . As the tooling to convert YANG documents into an list of SID keys is still in its infancy, the table of SID values presented here should be considered normative rather than the output of the pyang tool. Two methods of signing the resulting CBOR object are described in this document. One is CMS . The other is COSE signatures.

The following terms are defined in , and are used identically as in that document: artifact, imprint, domain, Join Registrar/Coordinator (JRC), Manufacturer Authorized Signing Authority (MASA), pledge, Trust of First Use (TOFU), and Voucher.

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 and indicate requirement levels for compliant STuPiD implementations.

provides for vouchers that assert proximity, that authenticate the registrar and that include different amounts of anti-replay protection. This document does not make any extensions to the types of vouchers. Time based vouchers are included in this definition, but given that constrained devices are extremely unlikely to know the correct time, their use is very unlikely. Most users of these constrained vouchers will be online and will use live nonces to provide anti-replay protection. defined only the voucher artifact, and not the Voucher Request artifact, which was defined in . This document defines both a constrained voucher and a constrained voucher-request. They are presented in the order voucher-request, followed by voucher response as this is the time order that they occur.

This section describes the abstract (tree) definition as explained in first. This provides a high-level view of the contents of each artifact. Then the assigned SID values are presented. These have been assigned using the rules in , with an allocation that was made via the http://comi.space service. ((EDNOTE: it is unclear if there is further IANA work))

file "ietf-cwt-voucher-request@2017-12-11.yang" /* -*- c -*- */ module ietf-cwt-voucher-request { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-cwt-voucher-request"; prefix "vcwt"; import ietf-voucher { prefix "v"; } organization "IETF 6tisch Working Group"; contact "WG Web: WG List: Author: Michael Richardson "; description "This module defines the format for a voucher, which is produced by a pledge's manufacturer or delegate (MASA) to securely assign one or more pledges to an 'owner', so that the pledges may establish a secure connection to the owner's network infrastructure. This version provides a very restricted subset appropriate for very constrained devices. In particular, it assumes that nonce-ful operation is always required, that expiration dates are rather weak, as no clocks can be assumed, and that the Registrar is identified by a pinned Raw Public Key. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119."; revision "2017-12-11" { description "Initial version"; reference "RFC XXXX: Voucher Profile for Constrained Devices"; } // Grouping defined for future usage grouping voucher-request-cwt-grouping { description "Grouping to allow reuse/extensions in future work."; uses v:voucher-artifact-grouping { augment "voucher" { description "Base the CWT voucher-request upon the regular one"; leaf proximity-registrar-subject-public-key-info { type binary; description "The proximity-registrar-subject-public-key-info replaces the proximit-registrar-cert in constrained uses of the voucher-request. The proximity-registrar-subject-public-key-info is the Raw Public Key of the Registrar. This field is encoded as specified in RFC7250, section 3. The ECDSA algorithm MUST be supported. The EdDSA algorithm as specified in draft-ietf-tls-rfc4492bis-17 SHOULD be supported. Support for the DSA algorithm is not recommended. Support for the RSA algorithm is a MAY."; } } } } }

]]>

TBD




The voucher's primary purpose is to securely assign a pledge to an
owner.  The voucher informs the pledge which entity it should
consider to be its owner.

This document defines a voucher that is a CBOR encoded instance of
the YANG module defined in Section 5.3 that has been signed with CMS
or with COSE.



















 file "ietf-cwt-voucher@2017-12-11.yang"
/* -*- c -*- */
module ietf-cwt-voucher {
  yang-version 1.1;

  namespace
    "urn:ietf:params:xml:ns:yang:ietf-cwt-voucher";
  prefix "vcwt";

  import ietf-voucher {
    prefix "v";
  }

  organization
   "IETF 6tisch Working Group";

  contact
   "WG Web:   
    WG List:  
    Author:   Michael Richardson
              ";

  description
   "This module defines the format for a voucher, which is produced by
    a pledge's manufacturer or delegate (MASA) to securely assign one
    or more pledges to an 'owner', so that the pledges may establish a
    secure connection to the owner's network infrastructure.

    This version provides a very restricted subset appropriate
    for very constrained devices.
    In particular, it assumes that nonce-ful operation is
    always required, that expiration dates are rather weak, as no
    clocks can be assumed, and that the Registrar is identified
    by a pinned Raw Public Key.

    The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
    'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in
    the module text are to be interpreted as described in RFC 2119.";

  revision "2017-12-11" {
    description
     "Initial version";
    reference
     "RFC XXXX: Voucher Profile for Constrained Devices";
  }

  // Grouping defined for future usage
  grouping voucher-cwt-grouping {
    description
      "Grouping to allow reuse/extensions in future work.";

    uses v:voucher-artifact-grouping {
      augment "voucher" {
        description "Base the CWT voucher upon the regular one";
        leaf pinned-domain-subject-public-key-info {
          type binary;
          description
            "The pinned-domain-subject replaces the
         pinned-domain-certificate in constrained uses of
         the voucher.  The pinned-domain-public-key-info is the
         Raw Public Key of the Registrar. This field is encoded
         as specified in RFC7250, section 3.
         The ECDSA algorithm MUST be supported.
         The EdDSA algorithm as specified in
         draft-ietf-tls-rfc4492bis-17 SHOULD be supported.
         Support for the DSA algorithm is not recommended.
         Support for the RSA algorithm is a MAY.";
        }
      }
    }
  }
}

]]>




TBD














## Protect Voucher PKI in HSM
## Test Domain Certificate Validity when Signing







This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registration is
requested:






This document registers two YANG modules in the YANG Module Names
registry [RFC6020].  Following the format defined in [RFC6020], the
the following registration is requested:






This document registers an OID in the "SMI Security for S/MIME CMS
Content Type" registry (1.2.840.113549.1.9.16.1), with the value:



XXX: should a seperate value be used for Voucher Requests?




The SID range 1001100 was allocated by comi.space to the IETF-CWT-VOUCHER
yang module.

The SID range 1001150 was allocated by comi.space to the IETF-CWT-VOUCHER-REQUEST
yang module.

EDNOTE: it is unclear if there is further IANA work required.





TBD