draft-ietf-anima-voucher-04.txt   draft-ietf-anima-voucher-05.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: January 4, 2018 Sandelman Software Expires: February 22, 2018 Sandelman Software
M. Pritikin M. Pritikin
Cisco Systems Cisco Systems
T. Eckert T. Eckert
Huawei Huawei
July 3, 2017 August 21, 2017
Voucher Profile for Bootstrapping Protocols Voucher Profile for Bootstrapping Protocols
draft-ietf-anima-voucher-04 draft-ietf-anima-voucher-05
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 The voucher artifact is a YANG-defined JSON document that has (by
default) been signed using a PKCS#7 structure. The voucher artifact default) been signed using a PKCS#7 structure. The voucher artifact
is normally generated by the pledge's manufacturer or delegate (i.e. is normally generated by the pledge's manufacturer or delegate (i.e.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 January 4, 2018. This Internet-Draft will expire on February 22, 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 34 skipping to change at page 2, line 34
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Tree Diagram Notation . . . . . . . . . . . . . . . . . . . . 4 4. Tree Diagram Notation . . . . . . . . . . . . . . . . . . . . 4
5. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 5 5. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 5
6. Voucher artifact . . . . . . . . . . . . . . . . . . . . . . 7 6. Voucher artifact . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 14
7.1. Renewals instead of Revocations . . . . . . . . . . . . . 14 7.1. Renewals instead of Revocations . . . . . . . . . . . . . 14
7.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 15 7.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 16 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 15
8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16
8.3. Test Domain Certificate Validity when Signing . . . . . . 16 8.3. Test Domain Certificate Validity when Signing . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17 9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16
9.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 9.2. The YANG Module Names Registry . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 17
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 pledge to an This document defines a strategy to securely assign a candidate
owner, using an artifact signed, directly or indirectly, by the device (pledge) to an owner, using an artifact signed, directly or
pledge's manufacturer or delegate, i.e. the Manufacturer Authorized indirectly, by the pledge's manufacturer or delegate, i.e. the
Signing Authority (MASA). This artifact is known as the voucher. Manufacturer Authorized 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 [RFC7159] document, conforming to a
described by YANG [RFC7950], that has (by default) been signed using data model described by YANG [RFC7950], encoded using the rules
a PKCS#7 structure. defined in [RFC7159], and signed using (by default) a PKCS#7
structure [RFC2315].
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 45 skipping to change at page 3, line 48
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].
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. i 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.
Pledge: The prospective device attempting to find and securely join Pledge: The prospective device attempting to find and securely join
skipping to change at page 5, line 38 skipping to change at page 5, line 41
(this is distinct from the voucher signature that protects the (this is distinct from the voucher signature that protects the
voucher itself). This might include manufacturer asserted voucher itself). This might include manufacturer asserted
ownership verification, assured logging operations or reliance on ownership verification, assured logging operations or reliance on
Pledge endpoint behavior such as secure root of trust of Pledge endpoint behavior such as secure root of trust of
measurement. The Join Registrar might use this information. Only measurement. The Join Registrar might use this information. Only
some methods are normatively defined in this document. Other some methods are normatively defined in this document. Other
methods are left for future work. methods are left for future work.
Authentication of Join Registrar: Indicates how the Pledge can Authentication of Join Registrar: Indicates how the Pledge can
authenticate the Join Registrar. This might include an indication authenticate the Join Registrar. This might include an indication
of the private PKIX trust anchor used by the Registrar, or an of the private PKIX (Public Key Infrastructure using X.509) trust
indication of a public PKIX trust anchor and additional CN-ID or anchor used by the Registrar, or an indication of a public PKIX
DNS-ID information to complete authentication. Symmetric key or trust anchor and additional CN-ID or DNS-ID information to
other methods are left for future work. complete authentication. Symmetric key or other methods are left
for future work.
Anti-Replay Protections: Time or nonce based information to Anti-Replay Protections: Time or nonce based information to
constrain the voucher to time periods or bootstrap attempts. constrain the voucher to time periods or bootstrap attempts.
A number of bootstrapping scenarios can be met using differing A number of bootstrapping scenarios can be met using differing
combinations of this information. All scenarios address the primary combinations of this information. All scenarios address the primary
threat of a Man-in-The-Middle Registrar gaining control over the threat of a Man-in-The-Middle (MiTM) Registrar gaining control over
Pledge device. The following combinations are "types" of vouchers: the Pledge device. The following combinations are "types" of
vouchers:
|Assertion |Registrar ID | Validity | |Assertion |Registrar ID | Validity |
Voucher |Log-|Veri- |Trust |CN-ID or| RTC | Nonce | Voucher |Log-|Veri- |Trust |CN-ID or| RTC | Nonce |
Name | ged| fied |Anchor |DNS-ID | | | Type | ged| fied |Anchor |DNS-ID | | |
---------------------------------------------------------| ---------------------------------------------------------|
Audit | X | | X | | | X | Audit | X | | X | | | X |
-------------|----|-------|-------|--------|-----|-------| -------------|----|-------|-------|--------|-----|-------|
Nonceless | X | | X | | X | | Nonceless | X | | X | | X | |
Audit | | | | | | | Audit | | | | | | |
-------------|----|-------|-------|--------|-----|-------| -------------|----|-------|-------|--------|-----|-------|
Owner Audit | X | X | X | | X | X | Owner Audit | X | X | X | | X | X |
-------------|----|-------|-------|--------|-----|-------| -------------|----|-------|-------|--------|-----|-------|
Owner ID | | X | X | X | X | | Owner ID | | X | X | X | X | |
-------------|----|-------|----------------|-----|-------| -------------|----|-------|----------------|-----|-------|
skipping to change at page 6, line 41 skipping to change at page 6, line 43
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
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 Vouchers
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 a 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. The inclusion of the Pledge's CN-ID or DNS-ID within the voucher. The
MASA service mitigates a MiTM Registrar by identifying the MASA service mitigates a MiTM Registrar by identifying the
specific Registrar (via WebPKI) authorized to own the Pledge. specific Registrar (via WebPKI) authorized to own the Pledge.
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
skipping to change at page 7, line 17 skipping to change at page 7, line 20
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 6. 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 is signing structure that MUST contain JSON-encoded The voucher signing structure that MUST contain JSON-encoded content
content conforming to the voucher-artifact YANG data schema of the conforming to the voucher-artifact YANG data schema of the YANG
YANG module specified in Section 6.3. module specified in Section 6.3.
Unless otherwise signaled (outside of the voucher artifact), the Unless otherwise signaled (outside of the voucher artifact), the
signing structure is by default a PKCS#7 SignedData structure, as signing structure is by default a PKCS#7 SignedData structure, as
specified by Section 9.1 of [RFC2315], encoded using ASN.1 specified by Section 9.1 of [RFC2315], encoded using ASN.1
distinguished encoding rules (DER), as specified in ITU-T X.690. 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 a private key trusted by the generated over the content using a private key trusted by the
recipient. Normally the recipient is the pledge and the signer is recipient. Normally the recipient is the pledge and the signer is
the MASA. A possible other use use could be as a "signed voucher the MASA. A possible other use use could be as a "signed voucher
request" format originating from pledge or registrar toward the MASA. request" format originating from pledge or registrar toward the MASA.
Within this document the signer is assumed to be 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 the certificates leading
leading up to and including the signer's trust anchor certificate up to and including the signer's trust anchor certificate known to
known to the recipient. 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 certificate authorities (CAs) between the voucher-issuer
known to the recipient. and the trust anchor known to the recipient.
Methods of signaling alternative signature methods are out-of-scope Methods of signaling alternative signature methods are out-of-scope
of this document, but documents that leverage vouchers can provide of this document, but documents that leverage vouchers can provide
this signaling. For example they might instruct that JWS signing is this signaling. For example they might instruct that JSON Web
the signature method in their work. Documents describing the use of Signature (JWS) signing is the signature method in their work.
alternative signature methods for voucher artifacts need to encode Documents describing the use of alternative signature methods for
the same information as described above for PKCS#7 or else describe voucher artifacts need to encode the same information as described
why the encoded information may differ. above for PKCS#7 or else describe why the encoded information may
differ.
6.1. Tree Diagram 6.1. Tree Diagram
The following tree diagram (Section 4) illustrates a high-level view The following tree diagram illustrates a high-level view of a voucher
of a voucher document. Each field in the voucher is fully described document. The notation used in this diagram is described in
by the YANG module provided in Section 6.3. Please review this YANG Section 4). Each node in the diagram is fully described by the YANG
module for a detailed description of the voucher format. module in Section 6.3. Please review the YANG module for a detailed
description of the voucher format.
module: ietf-voucher module: ietf-voucher
yang-data: yang-data:
voucher-artifact 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
+---- prior-signed-voucher? binary
6.2. Examples 6.2. Examples
This section provides a couple voucher examples for illustration This section provides voucher examples for illustration purposes.
purposes. That these examples conform to the encoding rules defined in
[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.
{ {
"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",
"idevid-issuer": "base64-encoded Authority Key Identifier", "idevid-issuer": "base64encodedvalue==",
"pinned-domain-cert": "base64-encoded X.509 DER", "pinned-domain-cert": "base64encodedvalue==",
"nonce": "base64-encoded octet string" "nonce": "base64encodedvalue=="
} }
} }
The following example illustrates a non-ephemeral voucher (no nonce). The following example illustrates a non-ephemeral voucher (no nonce).
While the voucher itself expires after two weeks, it presumably can While the voucher itself expires after two weeks, it presumably can
be renewed for up to a year later. The MASA generated this voucher be renewed for up to a year later. The MASA generated this voucher
using the 'verified' assertion type, which should satisfy all using the 'verified' assertion type, which should satisfy all
pledges. pledges.
{ {
"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",
"idevid-issuer": "base64-encoded Authority Key Identifier", "idevid-issuer": "base64encodedvalue==",
"pinned-domain-cert": "base64-encoded X.509 DER", "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 6.3. YANG Module
<CODE BEGINS> file "ietf-voucher@2017-07-03.yang" Following is a YANG [RFC7950] module formally describing the
voucher's JSON document structure.
<CODE BEGINS> file "ietf-voucher@2017-08-21.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 4 skipping to change at page 10, line 6
} }
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 Author: Toerless Eckert
<mailto:tte+ietf@cs.fau.de>"; <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 a
or more pledges to an 'owner', so that the pledges may establish a pledge to an 'owner', so that the pledge may establish a secure
secure connection to the owner's network infrastructure. 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-07-03" { Copyright (c) 2017 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices.";
revision "2017-08-21" {
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
rc:yang-data voucher-artifact { rc:yang-data voucher-artifact {
// YANG data template for a voucher.
uses voucher-artifact-grouping; uses voucher-artifact-grouping;
} }
// Grouping defined for future augmentations
grouping voucher-artifact-grouping { grouping voucher-artifact-grouping {
description description
"Grouping for the voucher-artifact to allow reuse/extensions "Grouping to allow reuse/extensions in future work.";
in future work.";
container voucher { container voucher {
description description
"A voucher that can be used to assign one or more "A voucher assigns a pledge to an owner (pinned-domain-cert).";
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
consumption. However, when present, pledges that have consumption. However, when present, pledges that have
reliable clocks SHOULD ensure that this created-on value reliable clocks SHOULD ensure that this created-on value
is not greater than the current time."; is not greater than the current time.";
skipping to change at page 14, line 11 skipping to change at page 14, line 23
"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>
7. Design Considerations 7. Design Considerations
7.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 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 delay, there is a need for the pledge to ensure that when there is a time delay, there is a need for the pledge to ensure
the assertions made when the voucher was created are still valid when that the assertions made when the voucher was created are still
it is consumed. valid.
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". With this approach, a potentially long-lived assertion is "voucher". With this approach, a potentially long-lived assertion is
paired with a reasonably fresh revocation status check to ensure that paired with a reasonably fresh revocation status check to ensure that
the assertion is still valid. However, this approach increases the assertion is still valid. However, this approach increases
solution complexity, as it introduces the need for additional solution complexity, as it introduces the need for additional
protocols and code paths to distribute and process the revocations. protocols and code paths to distribute and process the revocations.
Addressing the short-comings of revocations, this document recommends Addressing the short-comings of revocations, this document recommends
instead the use of lightweight renewals of short-lived non-revocable instead the use of lightweight renewals of short-lived non-revocable
vouchers. That is, rather than issue a long-lived voucher, the vouchers. That is, rather than issue a long-lived voucher, where the
expectation is for the MASA to instead issue a short-lived voucher 'expires-on' leaf is set to some distant date, the expectation is for
along with a promise (reflected in the 'last-renewal-date' field) to the MASA to instead issue a short-lived voucher, where the 'expires-
re-issue the voucher again when needed. Importantly, while issuing on' leaf is set to a relatively near date, along with a promise
the initial voucher may incur heavyweight verification checks (are (reflected in the 'last-renewal-date' field) to re-issue the voucher
you who you say you are? does the pledge actually belong to you?), again when needed. Importantly, while issuing the initial voucher
re-issuing the voucher should be a lightweight process, as it may incur heavyweight verification checks (are you who you say you
ostensibly only updates the voucher's validatity period. With this are? does the pledge actually belong to you?), re-issuing the
approach, there is only the one artifact, and only one code path is voucher should be a lightweight process, as it ostensibly only
needed to process it, without any possibility for a pledge to choose updates the voucher's validity period. With this approach, there is
to skip the revocation status check because, for instance, the OCSP only the one artifact, and only one code path is needed to process
Responder is not reachable. it, without any possibility for a pledge to choose to skip the
revocation status check because, for instance, the OCSP Responder is
not reachable.
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.
skipping to change at page 16, line 14 skipping to change at page 15, line 46
8. Security Considerations 8. Security Considerations
8.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 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.
skipping to change at page 16, line 36 skipping to change at page 16, line 20
8.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 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 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
skipping to change at page 17, line 41 skipping to change at page 17, line 27
10.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>. <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,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
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>. <http://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, <http://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.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-06 (work in progress), May 2017. keyinfra-07 (work in progress), July 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-14 (work in progress), June draft-ietf-netconf-zerotouch-15 (work in progress), August
2017. 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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3688>. 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, <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
 End of changes. 49 change blocks. 
114 lines changed or deleted 113 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/