draft-ietf-anima-voucher-02.txt   draft-ietf-anima-voucher-03.txt 
ANIMA Working Group K. Watsen ANIMA Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track M. Richardson Intended status: Standards Track M. Richardson
Expires: September 16, 2017 Sandelman Software Expires: December 9, 2017 Sandelman Software
M. Pritikin M. Pritikin
Cisco Systems Cisco Systems
T. Eckert T. Eckert
Huawei Huawei
March 15, 2017 June 7, 2017
Voucher Profile for Bootstrapping Protocols Voucher Profile for Bootstrapping Protocols
draft-ietf-anima-voucher-02 draft-ietf-anima-voucher-03
Abstract Abstract
This document defines a strategy to securely assign a pledge to an This document defines a strategy to securely assign a pledge to an
owner, using an artifact signed, directly or indirectly, by the owner, using an artifact signed, directly or indirectly, by the
pledge's manufacturer. This artifact is known as a "voucher". pledge's manufacturer. This artifact is known as a "voucher".
The voucher artifact is a YANG-defined JSON document that has been The voucher artifact is a YANG-defined JSON document that has been
signed using a PKCS#7 structure. The voucher artifact is generated signed using a PKCS#7 structure. The voucher artifact is generated
by the pledge's manufacture or delegate (i.e. the MASA). by the pledge's manufacture or delegate (i.e. the MASA).
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 16, 2017. This Internet-Draft will expire on December 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4
5. Voucher . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Voucher . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8
6. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 6. Design Considerations . . . . . . . . . . . . . . . . . . . . 13
6.1. Renewals instead of Revocations . . . . . . . . . . . . . 14 6.1. Renewals instead of Revocations . . . . . . . . . . . . . 13
6.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 16 6.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 16 7.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 14
7.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16 7.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 14
7.3. Test Domain Certificate Validity when Signing . . . . . . 16 7.3. Test Domain Certificate Validity when Signing . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 15
8.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 8.2. The YANG Module Names Registry . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document defines a strategy to securely assign a pledge to an This document defines a strategy to securely assign a pledge to an
owner, using an artifact signed, directly or indirectly, by the owner, using an artifact signed, directly or indirectly, by the
pledge's manufacturer or delegate (i.e. the MASA). This artifact is pledge's manufacturer or delegate (i.e. the MASA). This artifact is
known as the voucher. known as the voucher.
The voucher artifact is a JSON document, conforming to a data model The voucher artifact is a JSON document, conforming to a data model
described by YANG [RFC7950], that has been signed using a PKCS#7 described by YANG [RFC7950], that has been signed using a PKCS#7
skipping to change at page 3, line 31 skipping to change at page 3, line 31
This document only defines the voucher artifact, leaving it to other This document only defines the voucher artifact, leaving it to other
documents to describe specialized protocols for accessing it. Some documents to describe specialized protocols for accessing it. Some
bootstrapping protocols using the voucher artifact defined in this bootstrapping protocols using the voucher artifact defined in this
draft include: [I-D.ietf-netconf-zerotouch], draft include: [I-D.ietf-netconf-zerotouch],
[I-D.ietf-6tisch-dtsecurity-secure-join], and [I-D.ietf-6tisch-dtsecurity-secure-join], and
[I-D.ietf-anima-bootstrapping-keyinfra]). [I-D.ietf-anima-bootstrapping-keyinfra]).
2. Terminology 2. Terminology
The following terms are defined for clarity:
Imprint: The process where a device obtains the cryptographic key Imprint: The process where a device obtains the cryptographic key
material to identify and trust future interactions with a network. material to identify and trust future interactions with a network.
This term is taken from Konrad Lorenz's work in biology with new This term is taken from Konrad Lorenz's work in biology with new
ducklings: during a critical period, the duckling would assume ducklings: "during a critical period, the duckling would assume
that anything that looks like a mother duck is in fact their that anything that looks like a mother duck is in fact their
mother. An equivalent for a device is to obtain the fingerprint mother." An equivalent for a device is to obtain the fingerprint
of the network's root certification authority certificate. A of the network's root certification authority certificate. A
device that imprints on an attacker suffers a similar fate to a device that imprints on an attacker suffers a similar fate to a
duckling that imprints on a hungry wolf. Securely imprinting is a duckling that imprints on a hungry wolf. Securely imprinting is a
primary focus of this document.[imprinting]. The analogy to primary focus of this document.[imprinting]. The analogy to
Lorenz's work was first noted in [Stajano99theresurrecting]. Lorenz's work was first noted in [Stajano99theresurrecting].
Pledge: The prospective device attempting to find and join a secure Domain: The set of entities or infrastructure under common
remote key infrastructure. When shipped it only trusts authorized administrative control. The goal of the bootstrapping protocol is
representatives of the manufacturer. to enable a Pledge to discover and join a Domain.
Voucher: A signed statement from the MASA service that indicates to
a Pledge the cryptographic identity of the Registrar it should
trust. There are different types of vouchers depending on how
that trust asserted. This document describes vouchers in detail.
Domain: The set of entities that trust a common key infrastructure
trust anchor. This includes the Proxy, Registrar, Domain
Certificate Authority, Management components and any existing
entity that is already a member of the domain.
Domain CA: The domain Certification Authority (CA) provides
certification functionalities to the domain. At a minimum it
provides certification functionalities to a Registrar and stores
the trust anchor that defines the domain. Optionally, it
certifies all elements.
Join Registrar (and Coordinator): A representative of the domain Join Registrar (and Coordinator): A representative of the domain
that is configured, perhaps autonomically, to decide whether a new that is configured, perhaps autonomically, to decide whether a new
device is allowed to join the domain. The administrator of the device is allowed to join the domain. The administrator of the
domain interfaces with a Join Registrar (and Coordinator) to domain interfaces with a Join Registrar (and Coordinator) to
control this process. Typically a Join Registrar is "inside" its control this process. i Typically a Join Registrar is "inside" its
domain. For simplicity this document often refers to this as just domain. For simplicity this document often refers to this as just
"Registrar". The term JRC is used in common with other bootstrap "Registrar".
mechanisms.
MASA Service: A third-party Manufacturer Authorized Signing MASA: The Manufacturer Authorized Signing Authority (MASA) service
Authority (MASA) service on the global Internet. The MASA signs that signs vouchers. In some bootstrapping protocols, the MASA
vouchers. It also provides a repository for audit log information may have Internet presence and be integral to the bootstrapping
of privacy protected bootstrapping events. It does not track process, whereas in other protocols the MASA may be an offline
ownership. It is trusted by the Pledge. service that has no active role in the bootstrapping process.
TOFU: Trust on First Use. Used similarly to [RFC7435]. This is Pledge: The prospective device attempting to find and securely join
where a Pledge device makes no security decisions but rather a domain. When shipped it only trusts authorized representatives
simply trusts the first Registrar it is contacted by. This is of the manufacturer.
Registrar See Join Registrar
TOFU: Trust on First Use. This is where a Pledge device makes no
security decisions but rather simply trusts the first Domain
entity it is contacted by. Used similarly to [RFC7435]. This is
also known as the "resurrecting duckling" model. also known as the "resurrecting duckling" model.
Voucher: A signed statement from the MASA service that indicates to
a Pledge the cryptographic identity of the Domain it should trust.
3. Requirements Language 3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
sections below are to be interpreted as described in RFC 2119 sections below are to be interpreted as described in RFC 2119
[RFC2119]. [RFC2119].
4. Survey of Voucher Types 4. Survey of Voucher Types
A voucher is a cryptographically protected statement to the Pledge A voucher is a cryptographically protected statement to the Pledge
skipping to change at page 6, line 23 skipping to change at page 6, line 13
provide a permanent voucher for remote deployments. provide a permanent voucher for remote deployments.
Ownership Audit Voucher: An Audit Voucher where the MASA service has Ownership Audit Voucher: An Audit Voucher where the MASA service has
verified the Registrar as the authorized owner. The MASA service verified the Registrar as the authorized owner. The MASA service
mitigates a MiTM Registrar by refusing to generate Audit Voucher's mitigates a MiTM Registrar by refusing to generate Audit Voucher's
for unauthorized Registrars. The Registrar uses audit techniques for unauthorized Registrars. The Registrar uses audit techniques
to supplement the MASA. This provides an ideal sharing of policy to supplement the MASA. This provides an ideal sharing of policy
decisions and enforcement between the vendor and the owner. decisions and enforcement between the vendor and the owner.
Ownership ID Voucher: An Ownership ID Voucher is named after Ownership ID Voucher: An Ownership ID Voucher is named after
inclusion of the Pledge's CN-ID or DNS-ID within the voucher. An inclusion of the Pledge's CN-ID or DNS-ID within the voucher. The
example Ownership Voucher is defined in MASA service mitigates a MiTM Registrar by identifying the
[I-D.ietf-netconf-zerotouch]. The MASA service mitigates a MiTM specific Registrar (via WebPKI) authorized to own the Pledge.
Registrar by identifying the specific Registrar authorized to own
the Pledge. [DISCUSS: still needed?]
Bearer Voucher: A Bearer Voucher is named after the inclusion of a Bearer Voucher: A Bearer Voucher is named after the inclusion of a
Registrar ID wildcard. Because the Registrar identity is not Registrar ID wildcard. Because the Registrar identity is not
indicated this voucher type must be treated as a secret and indicated this voucher type must be treated as a secret and
protected from exposure as any 'bearer' of the voucher can claim protected from exposure as any 'bearer' of the voucher can claim
the Pledge device. Publishing a nonceless bearer voucher the Pledge device. Publishing a nonceless bearer voucher
effectively turns the specified Pledge into a "TOFU" device with effectively turns the specified Pledge into a "TOFU" device with
minimal mitigation against MiTM Registrars. Bearer vouchers are minimal mitigation against MiTM Registrars. Bearer vouchers are
out-of-scope. out-of-scope.
skipping to change at page 7, line 13 skipping to change at page 6, line 47
the YANG module specified in Section 5.3. the YANG module specified in Section 5.3.
The PKCS#7 structure MUST also contain a 'signerInfo' structure, as The PKCS#7 structure MUST also contain a 'signerInfo' structure, as
described in Section 9.1 of [RFC2315], containing the signature described in Section 9.1 of [RFC2315], containing the signature
generated over the content using the MASA's private key. generated over the content using the MASA's private key.
The PKCS#7 structure SHOULD also contain all of the certificates The PKCS#7 structure SHOULD also contain all of the certificates
leading up to and including the MASA's trust anchor certificate known leading up to and including the MASA's trust anchor certificate known
to the pledges. to the pledges.
The PKCS#7 structure MAY also contain revocation objects for any
intermediate CAs between the voucher-issuer and the trust anchor
known to the pledge.
5.1. Tree Diagram 5.1. Tree Diagram
The following tree diagram [I-D.bjorklund-netmod-yang-tree-diagrams] The following tree diagram [I-D.bjorklund-netmod-yang-tree-diagrams]
illustrates a high-level view of a voucher document. Each field in illustrates a high-level view of a voucher document. Each field in
the voucher is fully described by the YANG module provided in the voucher is fully described by the YANG module provided in
Section 5.3. Please review this YANG module for a detailed Section 5.3. Please review this YANG module for a detailed
description of the voucher format. description of the voucher format.
module: ietf-voucher module: ietf-voucher
+--ro voucher +--ro voucher
+--ro authority-key-identifier? binary +--ro created-on yang:date-and-time
+--ro created-on yang:date-and-time +--ro expires-on? yang:date-and-time
+--ro expires-on? yang:date-and-time +--ro assertion enumeration
+--ro assertion enumeration +--ro serial-number string
+--ro device-identifier string +--ro idevid-issuer? binary
+--ro trusted-ca-certificate binary +--ro pinned-domain-cert* binary
+--ro domain-certificate-identifier +--ro domain-cert-revocation-checks? boolean
| +--ro subject? binary +--ro nonce? binary
| +--ro cn-id? string +--ro last-renewal-date? yang:date-and-time
| +--ro dns-id? string
+--ro assert-certificate-revocations? boolean
+--ro nonce? binary
+--ro last-renewal-date? yang:date-and-time
5.2. Examples 5.2. Examples
This section provides a couple Voucher examples for illustration This section provides a couple Voucher examples for illustration
purposes. purposes.
The following example illustrates an ephemeral voucher (uses a nonce) The following example illustrates an ephemeral voucher (uses a nonce)
encoded in JSON. As is expected with a dynamically-generated encoded in JSON. As is expected with a dynamically-generated
voucher, only a single pledge (device-identifier) is specified. The voucher, only a single pledge (device-identifier) is specified. The
MASA generated this voucher using the 'logged' assertion type, MASA generated this voucher using the 'logged' assertion type,
knowing that it would be suitable for the pledge making the request. knowing that it would be suitable for the pledge making the request.
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"assertion": "logged",
"trusted-ca-certificate": "base64-encoded X.509 DER",
"device-identifier": "JADA123456789",
"created-on": "2016-10-07T19:31:42Z", "created-on": "2016-10-07T19:31:42Z",
"assertion": "logged",
"serial-number": "JADA123456789",
"serial-number-issuer": "some binary identifier",
"domain-cert-trusted-ca": "base64-encoded X.509 DER",
"domain-cert-identifier": {
"subject": "base64-encoded Subject DER"
},
"nonce": "base64-encoded octet string" "nonce": "base64-encoded octet string"
} }
} }
The following illustrates a long-lived voucher (no nonce), encoded in The following illustrates a long-lived voucher (no nonce), encoded in
XML. This particular voucher applies to more than one pledge XML. This particular voucher applies to more than one pledge
(unique-id), which might relate to, for instance, they were all (unique-id), which might relate to, for instance, they were all
issued as part of the same purchase order. This voucher includes issued as part of the same purchase order. This voucher includes
both a trust anchor certificate (trusted-ca-certificate) as well as both a trust anchor certificate (trusted-ca-certificate) as well as
some additional information (cn-id and dns-id) that can be used to some additional information (cn-id and dns-id) that can be used to
identify a specific domain certificate issued, perhaps indirectly, by identify a specific domain certificate issued, perhaps indirectly, by
the trust anchor CA. the trust anchor CA.
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"created-on": "2016-10-07T19:31:42Z",
"expires-on": "2016-10-21T19:31:42Z",
"assertion": "verified", "assertion": "verified",
"trusted-ca-certificate": "base64-encoded X.509 DER", "serial-number": "JADA123456789",
"domain-certificate-identifier": { "serial-number-issuer": "some binary identifier",
"domain-cert-trusted-ca": "base64-encoded X.509 DER",
"domain-cert-identifier": {
"subject": "base64-encoded Subject DER" "subject": "base64-encoded Subject DER"
}, },
"device-identifier": "JADA123456789", "assert-revocations-on-PKIX-certs": "false",
"created-on": "2016-10-07T19:31:42Z" "last-renewal-date": "2017-10-07T19:31:42Z"
} }
} }
5.3. YANG Module 5.3. YANG Module
<CODE BEGINS> file "ietf-voucher@2017-03-15.yang" <CODE BEGINS> file "ietf-voucher@2017-06-07.yang"
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. The yang-data extension doesn't
itself have anything to do with RESTCONF, but was placed in the
that RFC for convenience. This extension is being tracked to
be moved to the next version of the YANG modeling language.
Regardless where or how this extension statement is defined,
there should not be any impact to a voucher's encoding.";
reference "RFC 8040: RESTCONF Protocol";
}
organization
"IETF ANIMA Working Group";
contact module ietf-voucher {
"WG Web: <http://tools.ietf.org/wg/anima/> yang-version 1.1;
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>";
description namespace
"This module defines the format for a voucher, which is produced by "urn:ietf:params:xml:ns:yang:ietf-voucher";
a pledge's manufacturer or delegate (MASA) to securely assign one prefix "vch";
or more pledges to an 'owner', so that the pledges may establish a
secure connection to the owner's network infrastructure.";
revision "2017-03-15" { import ietf-yang-types {
description prefix yang;
"Initial version"; reference "RFC 6991: Common YANG Data Types";
reference }
"RFC XXXX: Voucher Profile for Bootstrapping Protocols";
}
rc:yang-data voucher-artifact { import ietf-restconf {
uses voucher-grouping; prefix rc;
} description
"This import statement is only present to access
the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol";
}
grouping voucher-grouping { organization
description "IETF ANIMA Working Group";
"Grouping only exists for pyang tree output...";
container voucher { contact
config false; "WG Web: <http://tools.ietf.org/wg/anima/>
description WG List: <mailto:anima@ietf.org>
"A voucher that can be used to assign one or more Author: Kent Watsen
pledges to an owner."; <mailto:kwatsen@juniper.net>
Author: Max Pritikin
<mailto:pritikin@cisco.com>
Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>";
leaf authority-key-identifier { description
type binary; "This module defines the format for a voucher, which is produced by
description a pledge's manufacturer or delegate (MASA) to securely assign one
"The Subject Key Identifier of the MASA's leaf certificate. or more pledges to an 'owner', so that the pledges may establish a
Enables the pledge a definitively identify the voucher's secure connection to the owner's network infrastructure.
issuer's certificate. This field is optional as not all
vouchers will be signed by a private key associated with
an X.509 certificate.";
}
leaf created-on { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
type yang:date-and-time; 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in
mandatory true; the module text are to be interpreted as described in RFC 2119.";
description
"A value indicating the date this voucher was created. This
node is optional because its primary purpose is for human
consumption. However, when present, pledges that have
reliable clocks SHOULD ensure that this created-on value
is not greater than the current time.";
}
leaf expires-on { revision "2017-06-07" {
type yang:date-and-time; description
must "not(../nonce)"; "Initial version";
description reference
"A value indicating when this voucher expires. The node is "RFC XXXX: Voucher Profile for Bootstrapping Protocols";
optional as not all pledges support expirations, such as }
pledges lacking a reliable clock.
If the pledge supports expirations and the expires-on value rc:yang-data voucher-artifact {
is less then the current time, then the pledge MUST not uses voucher-grouping;
process this voucher."; }
}
leaf assertion { grouping voucher-grouping {
type enumeration { description
enum verified { "Grouping only exists for pyang tree output...";
description
"Indicates that the ownership has been positively
verified by the MASA (e.g., through sales channel
integration).";
}
enum logged {
description
"Indicates that this ownership assignment has been
logged into a database maintained by the MASA, after
first verifying that there has not been a previous
claim in the database for the same pledge (voucher
transparency).";
}
}
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 before
processing the voucher.";
}
leaf device-identifier { container voucher {
type string; config false;
mandatory true; description
description "A voucher that can be used to assign one or more
"A unique identifier (e.g., serial number) within the scope pledges to an owner.";
of the MASA.
When processing a vouchers, pledges MUST ensure that their leaf created-on {
unique identifier matches at least one regular expression in type yang:date-and-time;
the list. If no matching regular expression is found, the mandatory true;
pledge MUST NOT process this voucher."; description
} "A value indicating the date this voucher was created. This
node is optional because its primary purpose is for human
consumption. However, when present, pledges that have
reliable clocks SHOULD ensure that this created-on value
is not greater than the current time.";
}
leaf trusted-ca-certificate { leaf expires-on {
type binary; type yang:date-and-time;
mandatory true; must "not(../nonce)";
description description
"An X.509 v3 certificate structure as specified by RFC 5280, "A value indicating when this voucher expires. The node is
Section 4 encoded using the ASN.1 distinguished encoding optional as not all pledges support expirations, such as
rules (DER), as specified in ITU-T X.690. pledges lacking a reliable clock.
This certificate is used by a pledge to trust a public key If this field exists, then the the pledges MUST ensure that
infrastructure, in order to verify a domain certificate the expires-on time has not yet passed. A pledge without
supplied to the pledge separately by the bootstrapping an accurate clock cannot meet this requirement.
protocol. The domain certificate MUST have this certificate
somewhere in its chain of certificates.
This field is optional because it may not be needed by all The expires-on value MUST NOT exceed the expiration date
bootstrapping protocols. of any of the listed 'pinned-domain-cert' certificates.";
Note: the expiration date of this certificate effectively }
imposes an upper limit on the voucher's expiration.";
reference leaf assertion {
"RFC 5280: type enumeration {
Internet X.509 Public Key Infrastructure Certificate enum verified {
and Certificate Revocation List (CRL) Profile. description
ITU-T X.690: "Indicates that the ownership has been positively
Information technology - ASN.1 encoding rules: verified by the MASA (e.g., through sales channel
Specification of Basic Encoding Rules (BER), integration).";
Canonical Encoding Rules (CER) and Distinguished }
Encoding Rules (DER)."; enum logged {
} description
"Indicates that this ownership assignment has been
logged into a database maintained by the MASA, after
first verifying that there has not been a previous
claim in the database for the same pledge (voucher
transparency).";
}
}
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 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.";
}
// DISCUSS: do we need this anymore, if short-lived vouchers leaf idevid-issuer {
// are expected, shouldn't the leaf certificate be pinned, or type binary;
// perhaps just the immediate issuer CA? description
container domain-certificate-identifier { "The RFC5280 4.2.1.1 Authority Key Identifier OCTET STRING
must "../trusted-ca-certificate" { from the pledge's IDevID certificate. Optional since some
description serial-numbers are already unique within the scope of a
"A trusted-ca-certificate must be present whenever MASA. Inclusion of the statistically unique key identifier
this node is present"; ensures statistically unique identification of the hardware.
} When processing a voucher, a pledge MUST ensure that its
description IDevID Authority Key Identifier matches this value. If no
"This container identifies specific values that a domain match occurs, then the pledge MUST NOT process this voucher.
certificate, provided to the pledge separately by the
bootstrapping protocol, MUST contain. This is useful
when, for instance, the trust anchor is a long-lived
public CA certificate, while the domain certificate is
reissued periodically.
When provided, the pledge MUST perform RFC 6125 style When issuing a voucher, the MASA MUST ensure that this field
validation of the domain certificate against all of is populated for serial numbers that are not otherwise unique
the provided values. within the scope of the MASA.";
}
This container is optional because it is unneeded when, leaf-list pinned-domain-cert {
for instance, the trusted CA certificate is owned by the type binary;
domain (i.e. a private PKI), and hence the trust model min-elements 1;
can be more relaxed."; description
"An X.509 v3 certificate structure as specified by RFC 5280,
Section 4 encoded using the ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690.
leaf subject { This certificate is used by a pledge to trust a public key
type binary; infrastructure, in order to verify a domain certificate
description supplied to the pledge separately by the bootstrapping
"The certificate's entire subject field MUST match protocol. The domain certificate MUST have this certificate
this value. This value is the Subject structure, as somewhere in its chain of certificates. This certificate
specified by RFC ???? Section ???, encoded using the MAY be an end-entity certificate, including a self-signed
ASN.1 distinguished encoding rules (DER), as specified entity.";
in ITU-T X.690."; reference
} "RFC 5280:
leaf cn-id { Internet X.509 Public Key Infrastructure Certificate
type string; and Certificate Revocation List (CRL) Profile.
description ITU-T X.690:
"The certificate's subject field's 'common name' value Information technology - ASN.1 encoding rules:
MUST match this value.";
}
leaf dns-id {
type string;
description
"A subjectAltName entry of type dNSName in the
certificate MUST match this value.";
}
}
// DISCUSS: does the transition to 'pinning' model mean we can Specification of Basic Encoding Rules (BER),
// drop this leaf for now? future proofing allows it to be added Canonical Encoding Rules (CER) and Distinguished
// if needed but its a edge condition? Encoding Rules (DER).";
// }
// DISCUSS: there must be such future proofing. not clear where
// to add it in the voucher document. This is probably the most
// important point of these discusses
leaf assert-certificate-revocations {
type boolean;
must "../expires-on";
default true;
description
"A processing instruction to the device that it should
verify revocation information for the PKIX certificates
involved in bootstrapping. This is available only if
the pledge has a real-time-clock. This is in addition
to any revocation checks performed by the MASA.";
// DISCUSS: should this be a boolean or an enum indicating leaf domain-cert-revocation-checks {
// "fail open" vs "fail closed" to make the meaning clearer. type boolean;
} must "../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 behaviour applies
to validation of the domain certificate.";
}
leaf nonce { leaf nonce {
type binary { type binary {
length "8..32"; length "8..32";
} }
must "not(../expires-on)"; must "not(../expires-on)";
description description
"A value that can be used by a pledge in some bootstrapping "A value that can be used by a pledge in some bootstrapping
protocols to enable anti-replay protection. This node is protocols to enable anti-replay protection. This node is
optional because it is not used by all bootstrapping optional because it is not used by all bootstrapping
protocols. protocols.
When present, the pledge MUST compare the provided nonce When present, the pledge MUST compare the provided nonce
value with another value that the pledge randomly generated value with another value that the pledge randomly generated
and sent to a bootstrap server in an earlier bootstrapping and sent to a bootstrap server in an earlier bootstrapping
message. If the values do not match, then the pledge MUST message. If the values do not match, then the pledge MUST
NOT process this voucher."; NOT process this voucher.";
} }
leaf last-renewal-date { leaf last-renewal-date {
type yang:date-and-time; type yang:date-and-time;
must "../expires-on"; must "../expires-on";
description description
"The last date that the MASA projects to be the last date it "The date that the MASA projects to be the last date it
will renew a voucher on (assuming the same validity duration will renew a voucher on. This field is merely informative, it
used in this voucher. This field is merely infomrative, it is not processed by pledges.
is not processed by pledges.
Circustances may occur after when a voucher was generated Circumstances may occur after a voucher is generated that
that can alter a voucher's validity period. For instance, may alter a voucher's validity period. For instance, a
a vendor may associate validity periods with support vendor may associate validity periods with support contracts,
contracts, which may be terminated or extended over time."; which may be terminated or extended over time.";
} }
} // end voucher } // end voucher
} // end voucher-grouping } // end voucher-grouping
} }
<CODE ENDS> <CODE ENDS>
6. Design Considerations 6. Design Considerations
6.1. Renewals instead of Revocations 6.1. Renewals instead of Revocations
The lifetimes of vouchers may vary. In some bootstrapping protocols,
the vouchers may be created and consumed immediately whereas, in
other bootstrapping solutions, there may be a significant delay
between when a voucher is created and when it is consumed. In cases
when there is a delay, there is a need for the pledge to ensure that
the assertions made when the voucher was created are still valid when
it is consumed.
A revocation artifact is generally used to verify the continued A revocation artifact is generally used to verify the continued
validity of an assertion such as a PKIX certificate, web token, or a validity of an assertion such as a PKIX certificate, web token, or a
"voucher". Conceptually revocation allows for issuance of assertions "voucher". With this approach, a potentially long-lived assertion is
using long lifetimes and thereby avoiding ongoing protocol operations paired with a reasonably fresh revocation status check to ensure that
to renew the assertion. In practice the use of revocation artifacts the assertion is still valid. However, this approach increases
increases the solution complexity. Rather than a single protocol, or solution complexity, as it introduces the need for additional
operation, to obtain or renew the assertion the resulting solution protocols and code paths to distribute and process the revocations.
instead has two or more protocols: one for assertion maintanence and
the other(s) for revocation verification.
The PKIX use of CRLs and OCSP responses provides an illustrative
example. Relying parties that verify revocation information must
obtain and parse the CRL or OCSP information. Each revocation method
has its own validity period that effectively shortens the certificate
validity period (since without valid revocation checks the
certificate would be rejected). In addition to having multiple
revocation protocol options the resulting space is further
complicated by inline distribution of the revocation information.
The TLS extension "Certificate Status Request" [RFC6066] for when
"constrained clients may wish to use a certificate-status protocol"
is an example of this. Including revocation information into
Cryptographic Message Syntax [RFC5652] is another example.
If vouchers included revocation similar complexities would propagate
to all related voucher distribution and assertion protocols. Instead
vouchers do not support revocation. Instead of the asserting party,
or relying party, obtaining and distributing revocation information
the asserting party MUST obtain an up-to-date valid voucher. The
protocol and operations infrastructures for this are expected to be
the same as the initial methods used to obtain a voucher in the first
place, with one important clarification: the MASA services MUST issue
updated validity period vouchers to the same Registrar ID with
minimal friction. This is similar to how an OCSP revocation system
is always willing to confirm that a certificate is not revoked.
There is no requirement implied that vouchers be contiguously
renewed. For example if a two-week lifetime voucher is not used
before it expires there is no requirement that it be still valid when
renewed. The domain MAY renew an expired voucher at any time. The
MASA always has authoritative control and MAY reject such renewals
(such as when requested by domain owner's to "block" renewals or if
the device has been successfully claimed by an alternate domain).
Allowing non-contiguous lifetimes significantly reduces the
operational load on the domain as it is not required to maintain
valid vouchers; only to ensure a valid voucher is available during
the time window in which it needs to be used.
[[EDNOTE: It might be worth including an indication of maximum Addressing the short-comings of revocations, this document recommends
lifetime for which such automated renewal is available. If so the instead the use of lightweight renewals of short-lived non-revocable
language we'd use would be similar to the RFC5280 statement that vouchers. That is, rather than issue a long-lived voucher, the
certificate validity period is "the time interval during which the CA expectation is for the MASA to instead issue a short-lived voucher
warrants that it will maintain information about the status of the along with a promise (reflected in the 'last-renewal-date' field) to
certificate" only here used to inform the Registrar of "the time re-issue the voucher again when needed. Importantly, while issuing
interval during which the MASA warrants that it will maintain the initial voucher may incur heavyweight verification checks (are
information about the status of the ownership claim". Such a field you who you say you are? does the pledge actually belong to you?),
would be independent of the actual validity period of the voucher and re-issuing the voucher should be a lightweight process, as it
is not intended for consumption by the Pledge. A suggested name for ostensibly only updates the voucher's validatity period. With this
this field would be "last-renewal-date".]] approach, there is only the one artifact, and only one code path is
needed to process it, without any possibility for a pledge to choose
to skip the revocation status check because, for instance, the OCSP
Responder is not reachable.
The communications to the MASA service regarding claiming and While this document recommends issuing short-lived vouchers, the
blocking of devices is out of scope of this specification. Similarly voucher artifact does not restrict the ability to create a long-lived
if revocation methods had been described, the method of reporting a vouchers, if required, however no revocation method is described.
revocation would have been out-of-scope.
The lifetimes of vouchers may vary. In some bootstrapping protocols Note that a voucher may be signed by a chain of intermediate CAs
the vouchers may be ephemeral, whereas in others the vouchers may be leading up to the trust anchor certificate known by the pledge. Even
potentially long-lived. For bootstrapping protocols that support though the voucher itself is not revocable, it may still be revoked,
ephemeral vouchers, there is no need to support renewal. For per se, if one of the intermediate CA certificates is revoked.
bootstrapping protocols that support long-lived vouchers, final
protocol complexity is reduced when short lifetime vouchers are
easily renewed rather than layering on additional revocation methods.
Manufacturers MAY issue long-lived vouchers to customers if required
but no revocation method is described.
6.2. Voucher Per Pledge 6.2. Voucher Per Pledge
The solution originally enabled a single voucher to apply to many The solution described herein originally enabled a single voucher to
pledges, using lists of regular expressions to represent ranges of apply to many pledges, using lists of regular expressions to
serial numbers. However, it was determined that blocking the renewal represent ranges of serial numbers. However, it was determined that
of a voucher that applied to many devices, would be excessive when blocking the renewal of a voucher that applied to many devices would
only the ownership for a single pledge needed to be blocked. be excessive when only the ownership for a single pledge needed to be
blocked. Thus, the voucher format now only supports a single serial-
number to be listed.
7. Security Considerations 7. Security Considerations
7.1. Clock Sensitivity 7.1. Clock Sensitivity
An attacker could use an expired voucher to gain control over a
device that has no understand of time.
To defend against this there are three things: devices are required
to verify that the expires-on field has not yet passed. Devices
without access to time can use nonces to get ephermal vouchers.
Thirdly, vouchers without expiration times may be used, which will
appear in the audit log, informing the security decision.
This document defines artifacts containing time values for voucher This document defines artifacts containing time values for voucher
expirations, which require an accurate clock in order to be processed expirations, which require an accurate clock in order to be processed
correctly. Vendors planning on issuing vouchers with expiration correctly. Vendors planning on issuing vouchers with expiration
values MUST ensure devices have an accurate clock when shipped from values must ensure devices have an accurate clock when shipped from
manufacturing facilities, and take steps to prevent clock tampering. manufacturing facilities, and take steps to prevent clock tampering.
If it is not possible to ensure clock accuracy then vouchers with If it is not possible to ensure clock accuracy then vouchers with
expirations SHOULD NOT be issued. expirations should not be issued.
7.2. Protect Voucher PKI in HSM 7.2. Protect Voucher PKI in HSM
This document favors using voucher-renewals over needing to support A voucher is signed by a CA, that may itself be signed by a chain of
voucher-revocations (Section 6.1). However, a voucher may be signed CAs leading to a trust anchor known to a pledge. Revocation checking
by a chain of intermediate CAs leading to the trust anchor known to a of the intermediate certificates may be difficult in some scenarios.
pledge. Revocation checking of these certificates is similarly The voucher format supports the existing PKIX revocation information
difficult. The current voucher format supports the existing PKIX distribution within the limits of the current PKI technology (a PKCS7
revocation information distribution within the limits of the current structure can contain revocation objects as well), but pledges MAY
PKI technology; but pledges MAY accept vouchers without checking accept vouchers without checking X.509 certificate revocation (when
X.509 certificate revocation. Without revocation checking, a 'domain-cert-revocation-checks' is false). Without revocation
compromized MASA keychain could be used to issue vouchers ad checking, a compromized MASA keychain could be used to issue vouchers
infinitum without recourse. For this reason, MASA implementations ad infinitum without recourse. For this reason, MASA implementations
SHOULD ensure that all the CA private keys are protected by hardware wanting to support such deployments SHOULD ensure that all the CA
private keys used for signing the vouchers are protected by hardware
security modules (HSMs). security modules (HSMs).
7.3. Test Domain Certificate Validity when Signing 7.3. Test Domain Certificate Validity when Signing
If a domain certificate is compromised, then any outstanding vouchers If a domain certificate is compromised, then any outstanding vouchers
for that domain could be used by the attacker. The domain for that domain could be used by the attacker. The domain
administrator is clearly expected to initiate revocation of any administrator is clearly expected to initiate revocation of any
domain identity certificates (as in normal in PKI solutions). domain identity certificates (as is normal in PKI solutions).
Similarly they are expected to contact the MASA to indicate that an Similarly they are expected to contact the MASA to indicate that an
outstanding (presumably short lifetime) voucher be blocked from outstanding (presumably short lifetime) voucher should be blocked
automated renewal. Protocols for voucher distribution are from automated renewal. Protocols for voucher distribution are
RECOMMENDED to check for revocation of any domain identity RECOMMENDED to check for revocation of any domain identity
certificates before automated renewal of vouchers. certificates before automated renewal of vouchers.
8. IANA Considerations 8. IANA Considerations
8.1. The IETF XML Registry 8.1. The IETF XML Registry
This document registers a URIs in the IETF XML registry [RFC3688]. This document registers a URIs in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registration is Following the format in [RFC3688], the following registration is
requested: requested:
skipping to change at page 18, line 23 skipping to change at page 16, line 32
[I-D.ietf-6tisch-dtsecurity-secure-join] [I-D.ietf-6tisch-dtsecurity-secure-join]
Richardson, M., "6tisch Secure Join protocol", draft-ietf- Richardson, M., "6tisch Secure Join protocol", draft-ietf-
6tisch-dtsecurity-secure-join-01 (work in progress), 6tisch-dtsecurity-secure-join-01 (work in progress),
February 2017. February 2017.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-04 (work in progress), October 2016. keyinfra-06 (work in progress), May 2017.
[I-D.ietf-netconf-zerotouch] [I-D.ietf-netconf-zerotouch]
Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning
for NETCONF or RESTCONF based Management", draft-ietf- for NETCONF or RESTCONF based Management", draft-ietf-
netconf-zerotouch-12 (work in progress), January 2017. netconf-zerotouch-13 (work in progress), March 2017.
[imprinting] [imprinting]
Wikipedia, , "Wikipedia article: Imprinting", July 2015, Wikipedia, "Wikipedia article: Imprinting", July 2015,
<https://en.wikipedia.org/wiki/Imprinting_(psychology)>. <https://en.wikipedia.org/wiki/Imprinting_(psychology)>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <http://www.rfc-editor.org/info/rfc7435>.
 End of changes. 68 change blocks. 
419 lines changed or deleted 336 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/