draft-ietf-anima-voucher-03.txt   draft-ietf-anima-voucher-04.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: December 9, 2017 Sandelman Software Expires: January 4, 2018 Sandelman Software
M. Pritikin M. Pritikin
Cisco Systems Cisco Systems
T. Eckert T. Eckert
Huawei Huawei
June 7, 2017 July 3, 2017
Voucher Profile for Bootstrapping Protocols Voucher Profile for Bootstrapping Protocols
draft-ietf-anima-voucher-03 draft-ietf-anima-voucher-04
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 (by
signed using a PKCS#7 structure. The voucher artifact is generated default) been signed using a PKCS#7 structure. The voucher artifact
by the pledge's manufacture or delegate (i.e. the MASA). is normally generated by the pledge's manufacturer or delegate (i.e.
the Manufacturer Authorized Signing Authority).
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. documents to describe specialized protocols for accessing it.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 9, 2017. This Internet-Draft will expire on January 4, 2018.
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 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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. Tree Diagram Notation . . . . . . . . . . . . . . . . . . . . 4
5. Voucher . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 5
5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 6. Voucher artifact . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8
5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Design Considerations . . . . . . . . . . . . . . . . . . . . 13 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Renewals instead of Revocations . . . . . . . . . . . . . 13 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 14
6.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 14 7.1. Renewals instead of Revocations . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 15
7.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 14 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 16
7.3. Test Domain Certificate Validity when Signing . . . . . . 15 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.3. Test Domain Certificate Validity when Signing . . . . . . 16
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.2. The YANG Module Names Registry . . . . . . . . . . . . . 15 9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. The YANG Module Names Registry . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 Manufacturer Authorized
known as the voucher. Signing Authority (MASA). This artifact is 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 (by default) been signed using
structure. a PKCS#7 structure.
A voucher may be useful in several contexts, but the driving A voucher may be useful in several contexts, but the driving
motivation herein is to support secure bootstrapping mechanisms. motivation herein is to support secure bootstrapping mechanisms.
Assigning ownership is important to bootstrapping mechanisms so that Assigning ownership is important to bootstrapping mechanisms so that
the pledge can authenticate the network that's trying to take control the pledge can authenticate the network that's trying to take control
of it. of it.
The lifetimes of vouchers may vary. In some bootstrapping protocols The lifetimes of vouchers may vary. In some bootstrapping protocols
the vouchers may be ephemeral, whereas in others the vouchers may be the vouchers may be ephemeral, whereas in others the vouchers may be
potentially long-lived. In order to support the second category of potentially long-lived. In order to support the second category of
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
This document uses the following terms (sorted by name):
Artifact: The term "artifact" is used throughout to represent the
voucher as instantiated in the form of a signed structure.
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
skipping to change at page 4, line 30 skipping to change at page 4, line 36
security decisions but rather simply trusts the first Domain security decisions but rather simply trusts the first Domain
entity it is contacted by. Used similarly to [RFC7435]. This is 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 Voucher: A signed statement from the MASA service that indicates to
a Pledge the cryptographic identity of the Domain it should trust. 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", "NOT RECOMMENDED", "MAY", and
sections below are to be interpreted as described in RFC 2119 "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
4. Survey of Voucher Types 4. Tree Diagram Notation
A simplified graphical representation of the data models is used in
this document. The meaning of the symbols in these diagrams is as
follows:
o Brackets "[" and "]" enclose list keys.
o Braces "{" and "}" enclose feature names, and indicate that the
named feature must be present for the subtree to be present.
o Abbreviations before data node names: "rw" (read-write) represents
configuration data and "ro" (read-only) represents state data.
o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
5. Survey of Voucher Types
A voucher is a cryptographically protected statement to the Pledge A voucher is a cryptographically protected statement to the Pledge
device authorizing a zero-touch "imprint" on the Join Registrar of device authorizing a zero-touch "imprint" on the Join Registrar of
the domain. The specific information a voucher provides is the domain. The specific information a voucher provides is
influenced by the bootstrapping use case. influenced by the bootstrapping use case.
The voucher can impart the following information to the Join The voucher can impart the following information to the Join
Registrar and Pledge: Registrar and Pledge:
Assertion Basis: Indicates the method that protects the imprint Assertion Basis: Indicates the method that protects the imprint
skipping to change at page 6, line 26 skipping to change at page 7, line 11
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.
5. Voucher 6. Voucher artifact
The voucher's purpose is to securely assign a pledge to an owner. The voucher's primary purpose is to securely assign a pledge to an
The voucher informs the pledge which entity it should consider to be owner. The voucher informs the pledge which entity it should
its owner. consider to be its owner.
The voucher is signed a PKCS#7 SignedData structure, as specified by The voucher is signing structure that MUST contain JSON-encoded
Section 9.1 of [RFC2315], encoded using ASN.1 distinguished encoding content conforming to the voucher-artifact YANG data schema of the
rules (DER), as specified in ITU-T X.690. YANG module specified in Section 6.3.
The PKCS#7 structure MUST contain JSON-encoded content conforming to Unless otherwise signaled (outside of the voucher artifact), the
the YANG module specified in Section 5.3. signing structure is by default a PKCS#7 SignedData structure, as
specified by Section 9.1 of [RFC2315], encoded using ASN.1
distinguished encoding rules (DER), as specified in ITU-T X.690.
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 a private key trusted by the
recipient. Normally the recipient is the pledge and the signer is
the MASA. A possible other use use could be as a "signed voucher
request" format originating from pledge or registrar toward the MASA.
Within this document the signer is assumed to be the MASA.
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 signer's trust anchor certificate
to the pledges. known to the recipient.
The PKCS#7 structure MAY also contain revocation objects for any The PKCS#7 structure MAY also contain revocation objects for any
intermediate CAs between the voucher-issuer and the trust anchor intermediate CAs between the voucher-issuer and the trust anchor
known to the pledge. known to the recipient.
5.1. Tree Diagram Methods of signaling alternative signature methods are out-of-scope
of this document, but documents that leverage vouchers can provide
this signaling. For example they might instruct that JWS signing is
the signature method in their work. Documents describing the use of
alternative signature methods for voucher artifacts need to encode
the same information as described above for PKCS#7 or else describe
why the encoded information may differ.
The following tree diagram [I-D.bjorklund-netmod-yang-tree-diagrams] 6.1. Tree Diagram
illustrates a high-level view of a voucher document. Each field in
the voucher is fully described by the YANG module provided in The following tree diagram (Section 4) illustrates a high-level view
Section 5.3. Please review this YANG module for a detailed of a voucher document. Each field in the voucher is fully described
description of the voucher format. by the YANG module provided in Section 6.3. Please review this YANG
module for a detailed description of the voucher format.
module: ietf-voucher module: ietf-voucher
+--ro voucher yang-data:
+--ro created-on yang:date-and-time voucher-artifact
+--ro expires-on? yang:date-and-time +---- voucher
+--ro assertion enumeration +---- created-on yang:date-and-time
+--ro serial-number string +---- expires-on? yang:date-and-time
+--ro idevid-issuer? binary +---- assertion enumeration
+--ro pinned-domain-cert* binary +---- serial-number string
+--ro domain-cert-revocation-checks? boolean +---- idevid-issuer? binary
+--ro nonce? binary +---- pinned-domain-cert binary
+--ro last-renewal-date? yang:date-and-time +---- domain-cert-revocation-checks? boolean
+---- nonce? binary
+---- last-renewal-date? yang:date-and-time
+---- prior-signed-voucher? binary
5.2. Examples 6.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
encoded in JSON. As is expected with a dynamically-generated nonce). The MASA generated this voucher using the 'logged' assertion
voucher, only a single pledge (device-identifier) is specified. The type, knowing that it would be suitable for the pledge making the
MASA generated this voucher using the 'logged' assertion type, request.
knowing that it would be suitable for the pledge making the request.
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"created-on": "2016-10-07T19:31:42Z", "created-on": "2016-10-07T19:31:42Z",
"assertion": "logged", "assertion": "logged",
"serial-number": "JADA123456789", "serial-number": "JADA123456789",
"serial-number-issuer": "some binary identifier", "idevid-issuer": "base64-encoded Authority Key Identifier",
"domain-cert-trusted-ca": "base64-encoded X.509 DER", "pinned-domain-cert": "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 example illustrates a non-ephemeral voucher (no nonce).
XML. This particular voucher applies to more than one pledge While the voucher itself expires after two weeks, it presumably can
(unique-id), which might relate to, for instance, they were all be renewed for up to a year later. The MASA generated this voucher
issued as part of the same purchase order. This voucher includes using the 'verified' assertion type, which should satisfy all
both a trust anchor certificate (trusted-ca-certificate) as well as pledges.
some additional information (cn-id and dns-id) that can be used to
identify a specific domain certificate issued, perhaps indirectly, by
the trust anchor CA.
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"created-on": "2016-10-07T19:31:42Z", "created-on": "2016-10-07T19:31:42Z",
"expires-on": "2016-10-21T19:31:42Z", "expires-on": "2016-10-21T19:31:42Z",
"assertion": "verified", "assertion": "verified",
"serial-number": "JADA123456789", "serial-number": "JADA123456789",
"serial-number-issuer": "some binary identifier", "idevid-issuer": "base64-encoded Authority Key Identifier",
"domain-cert-trusted-ca": "base64-encoded X.509 DER", "pinned-domain-cert": "base64-encoded X.509 DER",
"domain-cert-identifier": { "domain-cert-revocation-checks": "true",
"subject": "base64-encoded Subject DER"
},
"assert-revocations-on-PKIX-certs": "false",
"last-renewal-date": "2017-10-07T19:31:42Z" "last-renewal-date": "2017-10-07T19:31:42Z"
} }
} }
5.3. YANG Module 6.3. YANG Module
<CODE BEGINS> file "ietf-voucher@2017-06-07.yang" <CODE BEGINS> file "ietf-voucher@2017-07-03.yang"
module ietf-voucher { module ietf-voucher {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-voucher"; "urn:ietf:params:xml:ns:yang:ietf-voucher";
prefix "vch"; prefix "vch";
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
skipping to change at page 9, line 11 skipping to change at page 10, line 4
} }
organization organization
"IETF ANIMA Working Group"; "IETF ANIMA Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/anima/> "WG Web: <http://tools.ietf.org/wg/anima/>
WG List: <mailto:anima@ietf.org> WG List: <mailto:anima@ietf.org>
Author: Kent Watsen Author: Kent Watsen
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Author: Max Pritikin Author: Max Pritikin
<mailto:pritikin@cisco.com> <mailto:pritikin@cisco.com>
Author: Michael Richardson Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>"; <mailto:mcr+ietf@sandelman.ca>
Author: Toerless Eckert
<mailto:tte+ietf@cs.fau.de>";
description description
"This module defines the format for a voucher, which is produced by "This module defines the format for a voucher, which is produced by
a pledge's manufacturer or delegate (MASA) to securely assign one a pledge's manufacturer or delegate (MASA) to securely assign one
or more pledges to an 'owner', so that the pledges may establish a or more pledges to an 'owner', so that the pledges may establish a
secure connection to the owner's network infrastructure. secure connection to the owner's network infrastructure.
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 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in
the module text are to be interpreted as described in RFC 2119."; the module text are to be interpreted as described in RFC 2119.";
revision "2017-06-07" { revision "2017-07-03" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Voucher Profile for Bootstrapping Protocols"; "RFC XXXX: Voucher Profile for Bootstrapping Protocols";
} }
rc:yang-data voucher-artifact { rc:yang-data voucher-artifact {
uses voucher-grouping; // YANG data template for a voucher.
uses voucher-artifact-grouping;
} }
grouping voucher-grouping { grouping voucher-artifact-grouping {
description description
"Grouping only exists for pyang tree output..."; "Grouping for the voucher-artifact to allow reuse/extensions
in future work.";
container voucher { container voucher {
config false;
description description
"A voucher that can be used to assign one or more "A voucher that can be used to assign one or more
pledges to an owner."; pledges to an owner.";
leaf created-on { leaf created-on {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"A value indicating the date this voucher was created. This "A value indicating the date this voucher was created. This
node is optional because its primary purpose is for human node is optional because its primary purpose is for human
skipping to change at page 10, line 43 skipping to change at page 11, line 40
integration)."; integration).";
} }
enum logged { enum logged {
description description
"Indicates that this ownership assignment has been "Indicates that this ownership assignment has been
logged into a database maintained by the MASA, after logged into a database maintained by the MASA, after
first verifying that there has not been a previous first verifying that there has not been a previous
claim in the database for the same pledge (voucher claim in the database for the same pledge (voucher
transparency)."; transparency).";
} }
enum proximity {
description
"Indicates that this assertion is made based on
the proximity of the signer as determined by
local network information. This is useful for
a pledge device to indicate it 'sees' a specific
registrar on a TLS connection, or for a registrar
to indicate it 'sees' a pledge.";
}
} }
mandatory true; mandatory true;
description description
"The assertion is a statement from the MASA regarding how "The assertion is a statement from the MASA regarding how
the owner was verified. This statement enables pledges the owner was verified. This statement enables pledges
to support more detailed policy checks. Pledges MUST to support more detailed policy checks. Pledges MUST
ensure that the assertion provided is acceptable before ensure that the assertion provided is acceptable before
processing the voucher."; processing the voucher.";
} }
leaf serial-number { leaf serial-number {
type string; type string;
mandatory true; mandatory true;
description description
"The serial number of the hardware. When processing a "The serial number of the hardware. When processing a
voucher, a pledge MUST ensure that its serial number voucher, a pledge MUST ensure that its serial number
matches this value. If no match occurs, then the matches this value. If no match occurs, then the
pledge MUST NOT process this voucher."; pledge MUST NOT process this voucher.";
} }
skipping to change at page 11, line 31 skipping to change at page 12, line 37
ensures statistically unique identification of the hardware. ensures statistically unique identification of the hardware.
When processing a voucher, a pledge MUST ensure that its When processing a voucher, a pledge MUST ensure that its
IDevID Authority Key Identifier matches this value. If no IDevID Authority Key Identifier matches this value. If no
match occurs, then the pledge MUST NOT process this voucher. match occurs, then the pledge MUST NOT process this voucher.
When issuing a voucher, the MASA MUST ensure that this field When issuing a voucher, the MASA MUST ensure that this field
is populated for serial numbers that are not otherwise unique is populated for serial numbers that are not otherwise unique
within the scope of the MASA."; within the scope of the MASA.";
} }
leaf-list pinned-domain-cert { leaf pinned-domain-cert {
type binary; type binary;
min-elements 1; mandatory true;
description description
"An X.509 v3 certificate structure as specified by RFC 5280, "An X.509 v3 certificate structure as specified by RFC 5280,
Section 4 encoded using the ASN.1 distinguished encoding Section 4 encoded using the ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690. rules (DER), as specified in ITU-T X.690.
This certificate is used by a pledge to trust a public key This certificate is used by a pledge to trust a public key
infrastructure, in order to verify a domain certificate infrastructure, in order to verify a domain certificate
supplied to the pledge separately by the bootstrapping supplied to the pledge separately by the bootstrapping
protocol. The domain certificate MUST have this certificate protocol. The domain certificate MUST have this certificate
somewhere in its chain of certificates. This certificate somewhere in its chain of certificates. This certificate
skipping to change at page 13, line 5 skipping to change at page 14, line 11
"The 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. This field is merely informative, it will renew a voucher on. This field is merely informative, it
is not processed by pledges. is not processed by pledges.
Circumstances may occur after a voucher is generated that Circumstances may occur after a voucher is generated that
may alter a voucher's validity period. For instance, a may alter a voucher's validity period. For instance, a
vendor may associate validity periods with support contracts, vendor may associate validity periods with support contracts,
which may be terminated or extended over time."; which may be terminated or extended over time.";
} }
leaf prior-signed-voucher {
type binary;
description
"If it is necessary to change a voucher, or re-sign and
forward a voucher that was previously provided along a
protocol path, then the previously signed voucher SHOULD be
included in this field.
For example, a pledge might sign a proximity voucher, which
an intermediate registrar then re-signs to make its own
'proximity' assertion. This is a simple mechanism for a
chain of trusted parties to change a voucher, while
maintaining the prior signature information.
The pledge MUST ignore all prior voucher information when
accepting a voucher for imprinting. Other parties MAY
examine the prior signed voucher information for the
purposes of policy decisions. For example this information
could be useful to a MASA to determine that both pledge and
registrar agree on proximity assertions. The MASA SHOULD
remove all 'prior-signed-voucher' information when signing
a voucher for imprinting so as to minimize the final voucher
size.";
}
} // end voucher } // end voucher
} // end voucher-grouping } // end voucher-grouping
} }
<CODE ENDS> <CODE ENDS>
6. Design Considerations 7. Design Considerations
6.1. Renewals instead of Revocations 7.1. Renewals instead of Revocations
The lifetimes of vouchers may vary. In some bootstrapping protocols, The lifetimes of vouchers may vary. In some bootstrapping protocols,
the vouchers may be created and consumed immediately whereas, in the vouchers may be created and consumed immediately whereas, in
other bootstrapping solutions, there may be a significant delay other bootstrapping solutions, there may be a significant delay
between when a voucher is created and when it is consumed. In cases 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 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 the assertions made when the voucher was created are still valid when
it is consumed. it is consumed.
A revocation artifact is generally used to verify the continued A revocation artifact is generally used to verify the continued
skipping to change at page 14, line 7 skipping to change at page 15, line 39
While this document recommends issuing short-lived vouchers, the While this document recommends issuing short-lived vouchers, the
voucher artifact does not restrict the ability to create a long-lived voucher artifact does not restrict the ability to create a long-lived
vouchers, if required, however no revocation method is described. vouchers, if required, however no revocation method is described.
Note that a voucher may be signed by a chain of intermediate CAs Note that a voucher may be signed by a chain of intermediate CAs
leading up to the trust anchor certificate known by the pledge. Even leading up to the trust anchor certificate known by the pledge. Even
though the voucher itself is not revocable, it may still be revoked, though the voucher itself is not revocable, it may still be revoked,
per se, if one of the intermediate CA certificates is revoked. per se, if one of the intermediate CA certificates is revoked.
6.2. Voucher Per Pledge 7.2. Voucher Per Pledge
The solution described herein originally enabled a single voucher to The solution described herein originally enabled a single voucher to
apply to many pledges, using lists of regular expressions to apply to many pledges, using lists of regular expressions to
represent ranges of serial numbers. However, it was determined that represent ranges of serial numbers. However, it was determined that
blocking the renewal of a voucher that applied to many devices would blocking the renewal of a voucher that applied to many devices would
be excessive when only the ownership for a single pledge needed to be be excessive when only the ownership for a single pledge needed to be
blocked. Thus, the voucher format now only supports a single serial- blocked. Thus, the voucher format now only supports a single serial-
number to be listed. number to be listed.
7. Security Considerations 8. Security Considerations
7.1. Clock Sensitivity 8.1. Clock Sensitivity
An attacker could use an expired voucher to gain control over a An attacker could use an expired voucher to gain control over a
device that has no understand of time. device that has no understand of time.
To defend against this there are three things: devices are required To defend against this there are three things: devices are required
to verify that the expires-on field has not yet passed. Devices to verify that the expires-on field has not yet passed. Devices
without access to time can use nonces to get ephermal vouchers. without access to time can use nonces to get ephermal vouchers.
Thirdly, vouchers without expiration times may be used, which will Thirdly, vouchers without expiration times may be used, which will
appear in the audit log, informing the security decision. appear in the audit log, informing the security decision.
This document defines artifacts containing time values for voucher This document defines a voucher format that contains time values for
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 8.2. Protect Voucher PKI in HSM
A voucher is signed by a CA, that may itself be signed by a chain of A voucher is signed by a CA, that may itself be signed by a chain of
CAs leading to a trust anchor known to a pledge. Revocation checking CAs leading to a trust anchor known to a pledge. Revocation checking
of the intermediate certificates may be difficult in some scenarios. of the intermediate certificates may be difficult in some scenarios.
The voucher format supports the existing PKIX revocation information The voucher format supports the existing PKIX revocation information
distribution within the limits of the current PKI technology (a PKCS7 distribution within the limits of the current PKI technology (a PKCS7
structure can contain revocation objects as well), but pledges MAY structure can contain revocation objects as well), but pledges MAY
accept vouchers without checking X.509 certificate revocation (when accept vouchers without checking X.509 certificate revocation (when
'domain-cert-revocation-checks' is false). Without revocation 'domain-cert-revocation-checks' is false). Without revocation
checking, a compromized MASA keychain could be used to issue vouchers checking, a compromized MASA keychain could be used to issue vouchers
ad infinitum without recourse. For this reason, MASA implementations ad infinitum without recourse. For this reason, MASA implementations
wanting to support such deployments SHOULD ensure that all the CA wanting to support such deployments SHOULD ensure that all the CA
private keys used for signing the vouchers are protected by hardware 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 8.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 is 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 should be blocked outstanding (presumably short lifetime) voucher should be blocked
from 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 9. IANA Considerations
8.1. The IETF XML Registry 9.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:
URI: urn:ietf:params:xml:ns:yang:ietf-voucher URI: urn:ietf:params:xml:ns:yang:ietf-voucher
Registrant Contact: The ANIMA WG of the IETF. Registrant Contact: The ANIMA WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
8.2. The YANG Module Names Registry 9.2. The YANG Module Names Registry
This document registers a YANG module in the YANG Module Names This document registers a YANG module in the YANG Module Names
registry [RFC6020]. Following the format defined in [RFC6020], the registry [RFC6020]. Following the format defined in [RFC6020], the
the following registration is requested: the following registration is requested:
name: ietf-voucher name: ietf-voucher
namespace: urn:ietf:params:xml:ns:yang:ietf-voucher namespace: urn:ietf:params:xml:ns:yang:ietf-voucher
prefix: vch prefix: vch
reference: RFC XXXX reference: RFC XXXX
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<http://www.rfc-editor.org/info/rfc2315>. <http://www.rfc-editor.org/info/rfc2315>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>. <http://www.rfc-editor.org/info/rfc7950>.
9.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[I-D.bjorklund-netmod-yang-tree-diagrams] 10.2. Informative References
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", 2017.
[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-06 (work in progress), May 2017. 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., Abrahamsson, M., and I. Farrer, "Zero Touch
for NETCONF or RESTCONF based Management", draft-ietf- Provisioning for NETCONF or RESTCONF based Management",
netconf-zerotouch-13 (work in progress), March 2017. draft-ietf-netconf-zerotouch-14 (work in progress), June
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
skipping to change at page 18, line 8 skipping to change at page 19, line 8
[Stajano99theresurrecting] [Stajano99theresurrecting]
Stajano, F. and R. Anderson, "The resurrecting duckling: Stajano, F. and R. Anderson, "The resurrecting duckling:
security issues for ad-hoc wireless networks", 1999, security issues for ad-hoc wireless networks", 1999,
<https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd- <https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-
duckling.pdf>. duckling.pdf>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank for following for lively discussions The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name): on list and in the halls (ordered by last name): William Atwood,
Toerless Eckert, Sheng Jiang.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
EMail: kwatsen@juniper.net EMail: kwatsen@juniper.net
Michael C. Richardson Michael C. Richardson
Sandelman Software Sandelman Software
 End of changes. 58 change blocks. 
120 lines changed or deleted 199 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/