draft-ietf-anima-voucher-06.txt   draft-ietf-anima-voucher-07.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: April 28, 2018 Sandelman Software Expires: July 28, 2018 Sandelman Software
M. Pritikin M. Pritikin
Cisco Systems Cisco Systems
T. Eckert T. Eckert
Huawei Huawei
October 25, 2017 January 24, 2018
Voucher Profile for Bootstrapping Protocols Voucher Profile for Bootstrapping Protocols
draft-ietf-anima-voucher-06 draft-ietf-anima-voucher-07
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".
This document defines one artifact format to be a YANG-defined JSON This document defines an artifact format as a YANG-defined JSON
document that has been signed using a CMS structure. Other YANG- document that has been signed using a CMS structure. Other YANG-
derived formats are possible. The voucher artifact is normally derived formats are possible. The voucher artifact is normally
generated by the pledge's manufacturer or delegate (i.e. the generated by the pledge's manufacturer (i.e. the Manufacturer
Manufacturer Authorized Signing Authority). 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 https://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 April 28, 2018. This Internet-Draft will expire on July 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 5
5. Voucher artifact . . . . . . . . . . . . . . . . . . . . . . 6 5. Voucher artifact . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. CMS format voucher artifact . . . . . . . . . . . . . . . 13 5.4. CMS format voucher artifact . . . . . . . . . . . . . . . 14
6. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 6. Design Considerations . . . . . . . . . . . . . . . . . . . . 15
6.1. Renewals instead of Revocations . . . . . . . . . . . . . 14 6.1. Renewals instead of Revocations . . . . . . . . . . . . . 15
6.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 15 6.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 15 7.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 16
7.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16 7.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 17
7.3. Test Domain Certificate Validity when Signing . . . . . . 16 7.3. Test Domain Certificate Validity when Signing . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17
8.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 8.2. The YANG Module Names Registry . . . . . . . . . . . . . 18
8.3. The SMI Security for S/MIME CMS Content Type Registry . 17 8.3. The IETF MIME Registry . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.4. The SMI Security for S/MIME CMS Content Type Registry . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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, i.e. the Manufacturer
Manufacturer Authorized Signing Authority (MASA). This artifact is Authorized Signing Authority (MASA). This artifact is known as the
known as the voucher. 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 CMS structure defined in [RFC7159], and signed using (by default) a CMS structure
[RFC5652]. [RFC5652].
A voucher may be useful in several contexts, but the driving A voucher's primary purpose is to securely convey to a pledge a
motivation herein is to support secure bootstrapping mechanisms. certificate, the "pinned-domain-cert", that the pledge can then use
Assigning ownership is important to bootstrapping mechanisms so that to authenticate subsequent interactions. A voucher may be useful in
the pledge can authenticate the network that's trying to take control several contexts but the driving motivation herein is to support
of it. secure bootstrapping mechanisms. Assigning ownership is important to
bootstrapping mechanisms so that the pledge can authenticate the
network that is trying to take control 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 include a nonce restricting them to a single use, the vouchers may include a nonce restricting them to a single use,
whereas in others the vouchers may have an indicated lifetime. In whereas in others the vouchers may have an indicated lifetime. In
order to support long lifetimes this document recommends using short order to support long lifetimes this document recommends using short
lifetimes with programmatic renewal, see Section 6.1. lifetimes with programmatic renewal, see Section 6.1.
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
skipping to change at page 3, line 46 skipping to change at page 4, line 5
voucher as instantiated in the form of a signed structure. 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. Imprinting is a term
primary focus of this document [imprinting]. The analogy to from psychology and ethnology, as describe in [imprinting]. The
Lorenz's work was first noted in [Stajano99theresurrecting]. analogy to 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) is the
that signs vouchers. In some bootstrapping protocols, the MASA entity that, for the purpose of this document, signs the vouchers
may have Internet presence and be integral to the bootstrapping for a manufacturer's pledges. In some bootstrapping protocols,
process, whereas in other protocols the MASA may be an offline the MASA may have Internet presence and be integral to the
service that has no active role in the bootstrapping process. The bootstrapping process, whereas in other protocols the MASA may be
MAS concept is explained in more detail in an offline service that has no active role in the bootstrapping
[I-D.ietf-anima-bootstrapping-keyinfra] process.
Owner: The entity that controls the private key of the "pinned-
domain-cert" certificate conveyed by the voucher.
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
skipping to change at page 5, line 18 skipping to change at page 5, line 27
Assertion Basis: Indicates the method that protects the imprint Assertion Basis: Indicates the method that protects the imprint
(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 document defines a
of the private PKIX (Public Key Infrastructure using X.509) trust mechanism to pin the domain certificate. Pinning a symmetric key,
anchor used by the Registrar, or an indication of a public PKIX a raw key, or [RFC6125] style "CN-ID" or "DNS-
trust anchor and additional CN-ID or DNS-ID information to ID" information is 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 (MiTM) Registrar gaining control over threat of a Man-in-The-Middle (MiTM) Registrar gaining control over
the Pledge device. The following combinations are "types" of the Pledge device. The following combinations are "types" of
vouchers: vouchers:
skipping to change at page 7, line 11 skipping to change at page 7, line 30
This format is described here as a practical basis for some uses This format is described here as a practical basis for some uses
(such as in NETCONF), but more to make it clear what vouchers look (such as in NETCONF), but more to make it clear what vouchers look
like in practice. This description also serves to validate the YANG like in practice. This description also serves to validate the YANG
model. model.
Future work is expected to define new mappings of the voucher to CBOR Future work is expected to define new mappings of the voucher to CBOR
(from JSON), and to change the signature container from CMS to JOSE (from JSON), and to change the signature container from CMS to JOSE
or COSE. XML or ASN.1 formats are also conceivable. or COSE. XML or ASN.1 formats are also conceivable.
The method of signaling alternative signature methods is out-of-scope This document defines a MIME type and a filename extension for the
for this document. Documents that leverage vouchers can provide this CMS encoded JSON type. Future documents on additional formats would
signaling. The signaling could be in the form of a MIME Content- define additional MIME types. Signaling is in the form of a MIME
Type, an HTTP Accept: header, or more mundane methods like use of a Content-Type, an HTTP Accept: header, or more mundane methods like
filename extension when a voucher is transfered on a USB key. use of a filename extension when a voucher is transfered on a USB
key.
5.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
[I-D.ietf-netmod-yang-tree-diagrams]). Each node in the diagram is [I-D.ietf-netmod-yang-tree-diagrams]). Each node in the diagram is
fully described by the YANG module in Section 5.3. Please review the fully described by the YANG module in Section 5.3. Please review the
YANG module for a detailed description of the voucher format. YANG module for a detailed description of the voucher format.
module: ietf-voucher module: ietf-voucher
skipping to change at page 8, line 40 skipping to change at page 9, line 23
"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"
} }
} }
5.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-10-25.yang" <CODE BEGINS> file "ietf-voucher@2018-01-24.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 9, line 49 skipping to change at page 10, line 32
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-10-25" { revision "2018-01-24" {
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 11 skipping to change at page 11, line 42
leaf assertion { leaf assertion {
type enumeration { type enumeration {
enum verified { enum verified {
description description
"Indicates that the ownership has been positively "Indicates that the ownership has been positively
verified by the MASA (e.g., through sales channel verified by the MASA (e.g., through sales channel
integration)."; integration).";
} }
enum logged { enum logged {
description description
"Indicates that this ownership assignment has been "Indicates that the voucher has been issued after
logged into a database maintained by the MASA, after minimal verification of ownership or control. The
first verifying that there has not been a previous issuance has been logged for detection of
claim in the database for the same pledge (voucher potential security issues (e.g. recipients of
transparency)."; vouchers might verify for themselves that unexpected
vouchers are not in the log). This is similar to unsecured
trust-on-first-use principles but with the logging
providing a basis for detecting unexpected events.";
} }
enum proximity { enum proximity {
description description
"Indicates that this assertion is made based on "Indicates that the voucher has been issued after
the proximity of the signer as determined by the MASA verified a proximity proof provided by the
local network information. This is useful for device and target domain. The issuance has been logged
a pledge device to indicate it 'sees' a specific for detection of potential security issues. This is
registrar on a TLS connection, or for a registrar stronger than just logging, because it requires some
to indicate it 'sees' a pledge."; verification that the pledge and owner are
in communication, but is still dependent on analysis of
the logs to detect unexpected events.";
} }
} }
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, per
processing the voucher."; local policy, before 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 12, line 19 skipping to change at page 13, line 6
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 pinned-domain-cert { leaf pinned-domain-cert {
type binary; type binary;
mandatory true; 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 using distinguished encoding rules (DER) encoding, as defined
rules (DER), as specified in ITU-T X.690. 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
MAY be an end-entity certificate, including a self-signed MAY be an end-entity certificate, including a self-signed
entity."; entity.";
reference reference
"RFC 5280: "RFC 5280:
skipping to change at page 13, line 51 skipping to change at page 14, line 38
5.4. CMS format voucher artifact 5.4. CMS format voucher artifact
The IETF evolution of PKCS#7 is CMS [RFC5652]. A CMS signed voucher, The IETF evolution of PKCS#7 is CMS [RFC5652]. A CMS signed voucher,
the default type, contains a ContentInfo structure with the voucher the default type, contains a ContentInfo structure with the voucher
content. An eContentType of TBD1 indicates the content is a JSON- content. An eContentType of TBD1 indicates the content is a JSON-
encoded voucher. encoded voucher.
The signing structure is a CMS SignedData structure, as specified by The signing structure is a CMS SignedData structure, as specified by
Section 5.1 of [RFC5652], encoded using ASN.1 distinguished encoding Section 5.1 of [RFC5652], encoded using ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690. rules (DER), as specified in ITU-T X.690 [ITU.X690.1994].
To facilitate interoperability, Section 8.3 in this document
registers the MIME type "application/voucher-cms+json" and the
filename extension ".vcj".
The CMS structure MUST contain a 'signerInfo' structure, as described The CMS structure MUST contain a 'signerInfo' structure, as described
in Section 5.1 of [RFC5652], containing the signature generated over in Section 5.1 of [RFC5652], containing the signature generated over
the content using a private key trusted by the recipient. Normally the content using a private key trusted by the recipient. Normally
the recipient is the pledge and the signer is the MASA. A possible the recipient is the pledge and the signer is the MASA. A possible
other use could be as a "signed voucher request" format originating other use could be as a "signed voucher request" format originating
from pledge or registrar toward the MASA. Within this document the from pledge or registrar toward the MASA. Within this document the
signer is assumed to be the MASA. signer is assumed to be the MASA.
Note that Section 5.1 of [RFC5652] includes a discussion about how to Note that Section 5.1 of [RFC5652] includes a discussion about how to
skipping to change at page 15, line 48 skipping to change at page 16, line 39
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 7. Security Considerations
7.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 understanding of time. The device can not trust
NTP as a time reference, as an attacker could control the NTP stream.
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
skipping to change at page 17, line 20 skipping to change at page 18, line 16
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
8.3. The SMI Security for S/MIME CMS Content Type Registry 8.3. The IETF MIME Registry
This document registers a URIs in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registration is
requested:
Type name: application
Subtype name: voucher-cms+json
Required parameters: none
Optional parameters: none
Encoding considerations: CMS-signed JSON vouchers are ASN.1/DER
encoded.
Security considerations: See Security Considerations, Section 7
Interoperability considerations: The format is designed to be
broadly interoperable.
Published specification: THIS RFC.
Applications that use this media type: ANIMA, 6tisch and NETCONF
zero-touch imprinting systems
Additional information:
Magic number(s): None
File extension(s): .vcj
Macintosh file type code(s): none
Person & email address to contact for further information: IETF
ANIMA WG
Intended usage: LIMITED
Restrictions on usage: NONE
Author: ANIMA WG
Change controller: IETF
Provisional registration? (standards tree only): NO
8.4. The SMI Security for S/MIME CMS Content Type Registry
This document registers an OID in the "SMI Security for S/MIME CMS 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: Content Type" registry (1.2.840.113549.1.9.16.1), with the value:
Decimal Description References Decimal Description References
------- -------------------------------------- ---------- ------- -------------------------------------- ----------
TBD1 id-ct-animaJSONVoucher [ThisRFC] TBD1 id-ct-animaJSONVoucher [ThisRFC]
9. References 9. References
9.1. Normative References 9.1. Normative References
[ITU.X690.1994]
International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009. RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[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, <https://www.rfc- DOI 10.17487/RFC6020, October 2010,
editor.org/info/rfc6020>. <https://www.rfc-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,
<https://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
skipping to change at page 18, line 20 skipping to change at page 20, line 24
[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-08 (work in progress), October 2017. keyinfra-09 (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-19 (work in progress), draft-ietf-netconf-zerotouch-19 (work in progress),
October 2017. October 2017.
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-02 (work in progress), ietf-netmod-yang-tree-diagrams-04 (work in progress),
October 2017. December 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,
January 2004. DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[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/
duckling.pdf>. papers/1999-StajanoAnd-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 Russ Housley provided the upgrade from PKCS7 to CMS(RFC5652), along
with the detailed CMS structure diagram. with the detailed CMS structure diagram.
 End of changes. 37 change blocks. 
95 lines changed or deleted 176 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/