draft-ietf-anima-voucher-05.txt   draft-ietf-anima-voucher-06.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: February 22, 2018 Sandelman Software Expires: April 28, 2018 Sandelman Software
M. Pritikin M. Pritikin
Cisco Systems Cisco Systems
T. Eckert T. Eckert
Huawei Huawei
August 21, 2017 October 25, 2017
Voucher Profile for Bootstrapping Protocols Voucher Profile for Bootstrapping Protocols
draft-ietf-anima-voucher-05 draft-ietf-anima-voucher-06
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 (by This document defines one artifact format to be a YANG-defined JSON
default) been signed using a PKCS#7 structure. The voucher artifact document that has been signed using a CMS structure. Other YANG-
is normally generated by the pledge's manufacturer or delegate (i.e. derived formats are possible. The voucher artifact is normally
the Manufacturer Authorized Signing Authority). 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 February 22, 2018. This Internet-Draft will expire on April 28, 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. Tree Diagram Notation . . . . . . . . . . . . . . . . . . . . 4 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4
5. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 5 5. Voucher artifact . . . . . . . . . . . . . . . . . . . . . . 6
6. Voucher artifact . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. CMS format voucher artifact . . . . . . . . . . . . . . . 13
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 6. Design Considerations . . . . . . . . . . . . . . . . . . . . 14
7.1. Renewals instead of Revocations . . . . . . . . . . . . . 14 6.1. Renewals instead of Revocations . . . . . . . . . . . . . 14
7.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 15 6.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 15 7.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 15
8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16 7.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16
8.3. Test Domain Certificate Validity when Signing . . . . . . 16 7.3. Test Domain Certificate Validity when Signing . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16
9.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 8.2. The YANG Module Names Registry . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.3. The SMI Security for S/MIME CMS Content Type Registry . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document defines a strategy to securely assign a candidate This document defines a strategy to securely assign a candidate
device (pledge) to an owner, using an artifact signed, directly or device (pledge) to an owner, using an artifact signed, directly or
indirectly, by the pledge's manufacturer or delegate, i.e. the indirectly, by the pledge's manufacturer or delegate, i.e. the
Manufacturer Authorized Signing Authority (MASA). This artifact is Manufacturer Authorized Signing Authority (MASA). This artifact is
known as the voucher. known as the voucher.
The voucher artifact is a JSON [RFC7159] document, conforming to a The voucher artifact is a JSON [RFC7159] document, conforming to a
data model described by YANG [RFC7950], encoded using the rules data model described by YANG [RFC7950], encoded using the rules
defined in [RFC7159], and signed using (by default) a PKCS#7 defined in [RFC7159], and signed using (by default) a CMS structure
structure [RFC2315]. [RFC5652].
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 include a nonce restricting them to a single use,
potentially long-lived. In order to support the second category of whereas in others the vouchers may have an indicated lifetime. In
vouchers, this document recommends using short-life vouchers with order to support long lifetimes this document recommends using short
programatic renewal, enabling the MASA to communicate the ongoing lifetimes with programmatic renewal, see Section 6.1.
validity of vouchers.
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
skipping to change at page 4, line 7 skipping to change at page 4, line 7
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].
Domain: The set of entities or infrastructure under common Domain: The set of entities or infrastructure under common
administrative control. The goal of the bootstrapping protocol is administrative control. The goal of the bootstrapping protocol is
to enable a Pledge to discover and join a Domain. to enable a Pledge to discover and join a domain.
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. 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". "Registrar".
MASA: The Manufacturer Authorized Signing Authority (MASA) service MASA: The Manufacturer Authorized Signing Authority (MASA) service
that signs vouchers. In some bootstrapping protocols, the MASA that signs vouchers. In some bootstrapping protocols, the MASA
may have Internet presence and be integral to the bootstrapping may have Internet presence and be integral to the bootstrapping
process, whereas in other protocols the MASA may be an offline process, whereas in other protocols the MASA may be an offline
service that has no active role in the bootstrapping process. service that has no active role in the bootstrapping process. The
MAS concept is explained in more detail in
[I-D.ietf-anima-bootstrapping-keyinfra]
Pledge: The prospective device attempting to find and securely join Pledge: The prospective device attempting to find and securely join
a domain. When shipped it only trusts authorized representatives a domain. When shipped it only trusts authorized representatives
of the manufacturer. of the manufacturer.
Registrar See Join Registrar Registrar See Join Registrar
TOFU: Trust on First Use. This is where a Pledge device makes no TOFU: Trust on First Use. This is where a Pledge device makes no
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. Tree Diagram Notation 4. Survey of Voucher Types
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 31 skipping to change at page 6, line 9
out-of-scope | | | | | out-of-scope | | | | |
-------------|----|-------|----------------|-------------| -------------|----|-------|----------------|-------------|
NOTE: All voucher types include a 'Pledge ID serial number' NOTE: All voucher types include a 'Pledge ID serial number'
(Not shown for space reasons) (Not shown for space reasons)
Audit Voucher: An Audit Voucher is named after the logging assertion Audit Voucher: An Audit Voucher is named after the logging assertion
mechanisms that the Registrar then "audits" to enforce local mechanisms that the Registrar then "audits" to enforce local
policy. The Registrar mitigates a MiTM Registrar by auditing that policy. The Registrar mitigates a MiTM Registrar by auditing that
an unknown MiTM registrar does not appear in the log entries. an unknown MiTM registrar does not appear in the log entries.
This does not direct prevent the MiTM but provides a response This does not directly prevent the MiTM but provides a response
mechanism that ensures the MiTM is unsuccessful. This advantage mechanism that ensures the MiTM is unsuccessful. This advantage
is that actual ownership knowledge is not required on the MASA is that actual ownership knowledge is not required on the MASA
service. service.
Nonceless Audit Voucher: An Audit Voucher without a validity period Nonceless Audit Voucher: An Audit Voucher without a validity period
statement. Fundamentally the same as an Audit Voucher except that statement. Fundamentally the same as an Audit Voucher except that
it can be issued in advance to support network partitions or to it can be issued in advance to support network partitions or to
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
skipping to change at page 7, line 14 skipping to change at page 6, line 40
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.
6. Voucher artifact 5. Voucher artifact
The voucher's primary purpose is to securely assign a pledge to an The voucher's primary purpose is to securely assign a pledge to an
owner. The voucher informs the pledge which entity it should owner. The voucher informs the pledge which entity it should
consider to be its owner. consider to be its owner.
The voucher signing structure that MUST contain JSON-encoded content This document defines a voucher that is a JSON encoded instance of
conforming to the voucher-artifact YANG data schema of the YANG the YANG module defined in Section 5.3 that has been, by default,
module specified in Section 6.3. CMS-signed.
Unless otherwise signaled (outside of the voucher artifact), the
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
described in Section 9.1 of [RFC2315], containing the signature
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 the certificates leading This format is described here as a practical basis for some uses
up to and including the signer's trust anchor certificate known to (such as in NETCONF), but more to make it clear what vouchers look
the recipient. like in practice. This description also serves to validate the YANG
model.
The PKCS#7 structure MAY also contain revocation objects for any Future work is expected to define new mappings of the voucher to CBOR
intermediate certificate authorities (CAs) between the voucher-issuer (from JSON), and to change the signature container from CMS to JOSE
and the trust anchor known to the recipient. or COSE. XML or ASN.1 formats are also conceivable.
Methods of signaling alternative signature methods are out-of-scope The method of signaling alternative signature methods is out-of-scope
of this document, but documents that leverage vouchers can provide for this document. Documents that leverage vouchers can provide this
this signaling. For example they might instruct that JSON Web signaling. The signaling could be in the form of a MIME Content-
Signature (JWS) signing is the signature method in their work. Type, an HTTP Accept: header, or more mundane methods like use of a
Documents describing the use of alternative signature methods for filename extension when a voucher is transfered on a USB key.
voucher artifacts need to encode the same information as described
above for PKCS#7 or else describe why the encoded information may
differ.
6.1. Tree Diagram 5.1. Tree Diagram
The following tree diagram illustrates a high-level view of a voucher The following tree diagram illustrates a high-level view of a voucher
document. The notation used in this diagram is described in document. The notation used in this diagram is described in
Section 4). Each node in the diagram is fully described by the YANG [I-D.ietf-netmod-yang-tree-diagrams]). Each node in the diagram is
module in Section 6.3. Please review the YANG module for a detailed fully described by the YANG module in Section 5.3. Please review the
description of the voucher format. YANG module for a detailed description of the voucher format.
module: ietf-voucher module: ietf-voucher
yang-data:
voucher-artifact yang-data voucher-artifact:
+---- voucher +---- voucher
+---- created-on yang:date-and-time +---- created-on yang:date-and-time
+---- expires-on? yang:date-and-time +---- expires-on? yang:date-and-time
+---- assertion enumeration +---- assertion enumeration
+---- serial-number string +---- serial-number string
+---- idevid-issuer? binary +---- idevid-issuer? binary
+---- pinned-domain-cert binary +---- pinned-domain-cert binary
+---- domain-cert-revocation-checks? boolean +---- domain-cert-revocation-checks? boolean
+---- nonce? binary +---- nonce? binary
+---- last-renewal-date? yang:date-and-time +---- last-renewal-date? yang:date-and-time
6.2. Examples 5.2. Examples
This section provides voucher examples for illustration purposes. This section provides voucher examples for illustration purposes.
That these examples conform to the encoding rules defined in That these examples conform to the encoding rules defined in
[RFC7159]. [RFC7159].
The following example illustrates an ephemeral voucher (uses a The following example illustrates an ephemeral voucher (uses a
nonce). The MASA generated this voucher using the 'logged' assertion nonce). The MASA generated this voucher using the 'logged' assertion
type, knowing that it would be suitable for the pledge making the type, knowing that it would be suitable for the pledge making the
request. request.
skipping to change at page 9, line 20 skipping to change at page 8, line 35
"expires-on": "2016-10-21T19:31:42Z", "expires-on": "2016-10-21T19:31:42Z",
"assertion": "verified", "assertion": "verified",
"serial-number": "JADA123456789", "serial-number": "JADA123456789",
"idevid-issuer": "base64encodedvalue==", "idevid-issuer": "base64encodedvalue==",
"pinned-domain-cert": "base64encodedvalue==", "pinned-domain-cert": "base64encodedvalue==",
"domain-cert-revocation-checks": "true", "domain-cert-revocation-checks": "true",
"last-renewal-date": "2017-10-07T19:31:42Z" "last-renewal-date": "2017-10-07T19:31:42Z"
} }
} }
6.3. YANG Module 5.3. YANG Module
Following is a YANG [RFC7950] module formally describing the Following is a YANG [RFC7950] module formally describing the
voucher's JSON document structure. voucher's JSON document structure.
<CODE BEGINS> file "ietf-voucher@2017-08-21.yang" <CODE BEGINS> file "ietf-voucher@2017-10-25.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;
reference "RFC 6991: Common YANG Data Types"; reference "RFC 6991: Common YANG Data Types";
skipping to change at page 10, line 35 skipping to change at page 9, line 49
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices."; itself for full legal notices.";
revision "2017-08-21" { revision "2017-10-25" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Voucher Profile for Bootstrapping Protocols"; "RFC XXXX: Voucher Profile for Bootstrapping Protocols";
} }
// Top-level statement // Top-level statement
rc:yang-data voucher-artifact { rc:yang-data voucher-artifact {
uses voucher-artifact-grouping; uses voucher-artifact-grouping;
} }
// Grouping defined for future augmentations // Grouping defined for future augmentations
skipping to change at page 11, line 14 skipping to change at page 10, line 28
container voucher { container voucher {
description description
"A voucher assigns a pledge to an owner (pinned-domain-cert)."; "A voucher assigns a pledge to an owner (pinned-domain-cert).";
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 primarily for human consumption and auditing. Future
consumption. However, when present, pledges that have work MAY create verification requirements based on this
reliable clocks SHOULD ensure that this created-on value node.";
is not greater than the current time.";
} }
leaf expires-on { leaf expires-on {
type yang:date-and-time; type yang:date-and-time;
must "not(../nonce)"; must "not(../nonce)";
description description
"A value indicating when this voucher expires. The node is "A value indicating when this voucher expires. The node is
optional as not all pledges support expirations, such as optional as not all pledges support expirations, such as
pledges lacking a reliable clock. pledges lacking a reliable clock.
skipping to change at page 14, line 29 skipping to change at page 13, line 42
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.";
} }
} // end voucher } // end voucher
} // end voucher-grouping } // end voucher-grouping
} }
<CODE ENDS> <CODE ENDS>
7. Design Considerations 5.4. CMS format voucher artifact
7.1. Renewals instead of Revocations The IETF evolution of PKCS#7 is CMS [RFC5652]. A CMS signed voucher,
the default type, contains a ContentInfo structure with the voucher
content. An eContentType of TBD1 indicates the content is a JSON-
encoded voucher.
The signing structure is a CMS SignedData structure, as specified by
Section 5.1 of [RFC5652], encoded using ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690.
The CMS structure MUST contain a 'signerInfo' structure, as described
in Section 5.1 of [RFC5652], containing the signature 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 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.
Note that Section 5.1 of [RFC5652] includes a discussion about how to
validate a CMS object which is really a PKCS7 object (cmsVersion=1).
Intermediate systems (such the BRSKI Registrar) which might need to
evaluate the voucher in flight MUST be prepared for such an older
format. No signaling is necessary, as the Manufacturer knows the
capabilities of the pledge, and will use an appropriate format
voucher for each pledge.
The CMS structure SHOULD also contain all the certificates leading up
to and including the signer's trust anchor certificate known to the
recipient. The inclusion of the trust anchor is unusual in many
applications, but without it third parties can not accurately audit
the transaction.
The CMS structure MAY also contain revocation objects for any
intermediate certificate authorities (CAs) between the voucher-issuer
and the trust anchor known to the recipient. However, the use of
CRLs and other validity mechanisms is discouraged, as the pledge is
unlikely to be able to perform online checks, and is unlikely to have
a trusted clock source. As described below, the use of short-lived
vouchers and/or pledge provided nonce provides a freshness guarantee.
6. Design Considerations
6.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 time delay other bootstrapping solutions, there may be a significant time 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 time delay, there is a need for the pledge to ensure when there is a time delay, there is a need for the pledge to ensure
that the assertions made when the voucher was created are still that the assertions made when the voucher was created are still
valid. valid.
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 15, line 27 skipping to change at page 15, line 33
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.
7.2. Voucher Per Pledge 6.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.
8. Security Considerations 7. Security Considerations
8.1. Clock Sensitivity 7.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 ephemeral vouchers. without access to time can use nonces to get ephemeral 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 a voucher format that contains time values for 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.
8.2. Protect Voucher PKI in HSM 7.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 compromised MASA keychain could be used to issue vouchers checking, a compromised 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).
8.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 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.
9. IANA Considerations 8. IANA Considerations
9.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:
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.
9.2. The YANG Module Names Registry 8.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
10. References 8.3. The SMI Security for S/MIME CMS Content Type Registry
10.1. Normative References This document registers an OID in the "SMI Security for S/MIME CMS
Content Type" registry (1.2.840.113549.1.9.16.1), with the value:
Decimal Description References
------- -------------------------------------- ----------
TBD1 id-ct-animaJSONVoucher [ThisRFC]
9. References
9.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, March 1997.
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, RFC 5652, September 2009.
<https://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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6020>. editor.org/info/rfc6020>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[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>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 9.2. Informative References
[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-07 (work in progress), July 2017. keyinfra-08 (work in progress), October 2017.
[I-D.ietf-netconf-zerotouch] [I-D.ietf-netconf-zerotouch]
Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch
Provisioning for NETCONF or RESTCONF based Management", Provisioning for NETCONF or RESTCONF based Management",
draft-ietf-netconf-zerotouch-15 (work in progress), August draft-ietf-netconf-zerotouch-19 (work in progress),
2017. October 2017.
[I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-02 (work in progress),
October 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, <https://www.rfc- January 2004.
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, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[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): William Atwood, on list and in the halls (ordered by last name): William Atwood,
Toerless Eckert, Sheng Jiang. Toerless Eckert, Sheng Jiang.
Russ Housley provided the upgrade from PKCS7 to CMS(RFC5652), along
with the detailed CMS structure diagram.
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. 50 change blocks. 
136 lines changed or deleted 155 lines changed or added

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