module ietf-voucher {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-voucher";
prefix "vch"; 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: <http://tools.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-03-29" 2018-03-29 {
description
"Initial version";
reference "RFC 8366: Voucher Profile for Bootstrapping Protocols";
}
// Top-level statement
rc:yang-data voucher-artifact "voucher-artifact" {
uses voucher-artifact-grouping;
}
// Grouping defined for future augmentations
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)"; '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 {
description
"Indicates that the ownership has been positively
verified by the MASA (e.g., through sales channel
integration).";
}
enum logged {
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 {
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;
must "../expires-on"; '../expires-on';
description
"A processing instruction to the Pledge that it MUST verify
the revocation status for the domain certificate. This
instruction is only available for vouchers that expire. 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)"; '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"; '../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.";
}
}
// end voucher
}
// end voucher-grouping
}