netconfcentral logo

ietf-voucher

HTML

ietf-voucher@2018-05-09



  module ietf-voucher {

    yang-version 1.1;

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

    prefix vch;

    import ietf-yang-types {
      prefix yang;
      reference
        "RFC 6991: Common YANG Data Types";


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


    }

    organization "IETF ANIMA Working Group";

    contact
      "WG Web:   <https://datatracker.ietf.org/wg/anima/>
     WG List:  <mailto:anima@ietf.org>
     Author:   Kent Watsen
               <mailto:kwatsen@juniper.net>
     Author:   Max Pritikin
               <mailto:pritikin@cisco.com>
     Author:   Michael Richardson
               <mailto:mcr+ietf@sandelman.ca>
     Author:   Toerless Eckert
               <mailto:tte+ietf@cs.fau.de>";

    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
     connection to the owner's network infrastructure.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they
     appear in all capitals, as shown here.

     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
     (https://trustee.ietf.org/license-info).

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

    revision "2018-05-09" {
      description "Initial version";
      reference
        "RFC 8366: Voucher Profile for Bootstrapping Protocols";

    }

    rc:yang-data "voucher-artifact";

    uses voucher-artifact-grouping;

    grouping voucher-artifact-grouping {
      description
        "Grouping to allow reuse/extensions in future work.";
      container voucher {
        description
          "A voucher assigns a pledge to an owner (pinned-domain-cert).";
        leaf created-on {
          type yang:date-and-time;
          mandatory true;
          description
            "A value indicating the date this voucher was created.  This
           node is primarily for human consumption and auditing.  Future
           work MAY create verification requirements based on this
           node.";
        }

        leaf expires-on {
          type yang:date-and-time;
          must 'not(../nonce)';
          description
            "A value indicating when this voucher expires.  The node is
           optional as not all pledges support expirations, such as
           pledges lacking a reliable clock.

           If this field exists, then the pledges MUST ensure that
           the expires-on time has not yet passed.  A pledge without
           an accurate clock cannot meet this requirement.

           The expires-on value MUST NOT exceed the expiration date
           of any of the listed 'pinned-domain-cert' certificates.";
        }

        leaf assertion {
          type enumeration {
            enum "verified" {
              value 0;
              description
                "Indicates that the ownership has been positively
               verified by the MASA (e.g., through sales channel
               integration).";
            }
            enum "logged" {
              value 1;
              description
                "Indicates that the voucher has been issued after
               minimal verification of ownership or control.  The
               issuance has been logged for detection of
               potential security issues (e.g., recipients of
               vouchers might verify for themselves that unexpected
               vouchers are not in the log).  This is similar to
               unsecured trust-on-first-use principles but with the
               logging providing a basis for detecting unexpected
               events.";
            }
            enum "proximity" {
              value 2;
              description
                "Indicates that the voucher has been issued after
               the MASA verified a proximity proof provided by the
               device and target domain.  The issuance has been logged
               for detection of potential security issues.  This is
               stronger than just logging, because it requires some
               verification that the pledge and owner are
               in communication but is still dependent on analysis of
               the logs to detect unexpected events.";
            }
          }
          mandatory true;
          description
            "The assertion is a statement from the MASA regarding how
           the owner was verified.  This statement enables pledges
           to support more detailed policy checks.  Pledges MUST
           ensure that the assertion provided is acceptable, per
           local policy, before processing the voucher.";
        }

        leaf serial-number {
          type string;
          mandatory true;
          description
            "The serial-number of the hardware.  When processing a
           voucher, a pledge MUST ensure that its serial-number
           matches this value.  If no match occurs, then the
           pledge MUST NOT process this voucher.";
        }

        leaf idevid-issuer {
          type binary;
          description
            "The Authority Key Identifier OCTET STRING (as defined in
           Section 4.2.1.1 of RFC 5280) from the pledge's IDevID
           certificate.  Optional since some serial-numbers are
           already unique within the scope of a MASA.
           Inclusion of the statistically unique key identifier
           ensures statistically unique identification of the hardware.
           When processing a voucher, a pledge MUST ensure that its
           IDevID Authority Key Identifier matches this value.  If no
           match occurs, then the pledge MUST NOT process this voucher.

           When issuing a voucher, the MASA MUST ensure that this field
           is populated for serial-numbers that are not otherwise unique
           within the scope of the MASA.";
        }

        leaf pinned-domain-cert {
          type binary;
          mandatory true;
          description
            "An X.509 v3 certificate structure, as specified by RFC 5280,
           using Distinguished Encoding Rules (DER) encoding, as defined
           in ITU-T X.690.

           This certificate is used by a pledge to trust a Public Key
           Infrastructure in order to verify a domain certificate
           supplied to the pledge separately by the bootstrapping
           protocol.  The domain certificate MUST have this certificate
           somewhere in its chain of certificates.  This certificate
           MAY be an end-entity certificate, including a self-signed
           entity.";
          reference
            "RFC 5280:
              Internet X.509 Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile.
            ITU-T X.690:
               Information technology - ASN.1 encoding rules:
               Specification of Basic Encoding Rules (BER),
               Canonical Encoding Rules (CER) and Distinguished
               Encoding Rules (DER).";

        }

        leaf domain-cert-revocation-checks {
          type boolean;
          description
            "A processing instruction to the pledge that it MUST (true)
           or MUST NOT (false) verify the revocation status for the
           pinned domain certificate.  If this field is not set, then
           normal PKIX behavior applies to validation of the domain
           certificate.";
        }

        leaf nonce {
          type binary {
            length "8..32";
          }
          must 'not(../expires-on)';
          description
            "A value that can be used by a pledge in some bootstrapping
           protocols to enable anti-replay protection.  This node is
           optional because it is not used by all bootstrapping
           protocols.

           When present, the pledge MUST compare the provided nonce
           value with another value that the pledge randomly generated
           and sent to a bootstrap server in an earlier bootstrapping
           message.  If the values do not match, then the pledge MUST
           NOT process this voucher.";
        }

        leaf last-renewal-date {
          type yang:date-and-time;
          must '../expires-on';
          description
            "The date that the MASA projects to be the last date it
           will renew a voucher on.  This field is merely informative;
           it is not processed by pledges.

           Circumstances may occur after a voucher is generated that
           may alter a voucher's validity period.  For instance, a
           vendor may associate validity periods with support contracts,
           which may be terminated or extended over time.";
        }
      }  // container voucher
    }  // grouping voucher-artifact-grouping
  }  // module ietf-voucher

Summary

  
  
Organization IETF ANIMA Working Group
  
Module ietf-voucher
Version 2018-05-09
File ietf-voucher@2018-05-09.yang
  
Prefix vch
Namespace urn:ietf:params:xml:ns:yang:ietf-voucher
  
Cooked /cookedmodules/ietf-voucher/2018-05-09
YANG /src/ietf-voucher@2018-05-09.yang
XSD /xsd/ietf-voucher@2018-05-09.xsd
  
Abstract This module defines the format for a voucher, which is produced by a pledge's manufacturer or delegate (MASA) to securely assign...
  
Contact
WG Web:   <https://datatracker.ietf.org/wg/anima/>
WG List:  <mailto:anima@ietf.org>
Author:   Kent Watsen
	  <mailto:kwatsen@juniper.net>
Author:   Max Pritikin
	  <mailto:pritikin@cisco.com>
Author:   Michael Richardson
	  <mailto:mcr+ietf@sandelman.ca>
Author:   Toerless Eckert
	  <mailto:tte+ietf@cs.fau.de>

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
connection to the owner's network infrastructure.

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they
appear in all capitals, as shown here.

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
(https://trustee.ietf.org/license-info).

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

Groupings

Grouping Objects Abstract
voucher-artifact-grouping voucher Grouping to allow reuse/extensions in future work.