NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks
Intended status: Standards Track M. Richardson
Expires: April 30, 2017 SSW
M. Pritikin
T. Eckert
Cisco Systems
October 27, 2016
Voucher and Voucher Revocation Profiles for Bootstrapping Protocols
draft-kwatsen-netconf-voucher-profiles
Abstract
This memo defines the two artifacts "ietf-voucher" and "ietf-voucher-
revocation".
The voucher is generated by the device's manufacture or a delegate of
the manufacturer. The voucher's purpose is to assign one or more
devices to an owner. The voucher informs each device which entity it
should consider to be its owner. The voucher also contains an
optional location to where its revocation artifact can be obtained.
The voucher revocation artifact is used by a voucher issuer to revoke
vouchers, if ever necessary. The voucher format defined herein
supports both issuer-wide or voucher-specific constructs, enabling
usage flexibility. This memo only defines the artifact, leaving it
to future work to describe specialized protocols for accessing it.
Editorial Note (To be removed by RFC Editor)
This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note
summarizes all of the substitutions that are needed. Please note
that no other RFC Editor instructions are specified anywhere else in
this document.
This document contains references to other drafts in progress, both
in the Normative References section, as well as in body text
throughout. Please update the following references to reflect their
final RFC assignments:
o ...
Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements:
Watsen, et al. Expires April 30, 2017 [Page 1]
Internet-Draft Voucher and Revocation Profiles October 2016
o "XXXX" --> the assigned RFC value for this draft
Artwork in this document contains placeholder values for the date of
publication of this document. Please apply the following
replacement:
o "2016-10-27" --> the publication date of this draft
The following one Appendix section is to be removed prior to
publication:
o Appendix A. Change Log
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Watsen, et al. Expires April 30, 2017 [Page 2]
Internet-Draft Voucher and Revocation Profiles October 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Tree Diagram Notation . . . . . . . . . . . . . . . . . . . . 4
4. Voucher . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5
5. Voucher Revocation . . . . . . . . . . . . . . . . . . . . . 8
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 14
7.2. The YANG Module Names Registry . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
This document defines a strategy to assign devices to an owner, using
an artifact signed, directly or indirectly, by the device's
manufacturer. This artifact is known as the voucher.
A voucher may be useful in several contexts, but the driving
motivation herein is to support secure bootstrapping mechanisms, such
as are defined in [draft-ietf-netconf-zerotouch] and
[draft-ietf-anima-bootstrapping-keyinfra]. With these mechanisms,
assigning ownership is important so that the booting device can
authenticate the network that's trying to take control of it.
When processing a voucher, devices first authenticate the voucher, by
verifying that the signature over it was generated by an entity the
device trusts by default (e.g., the device's manufacturer or
delegate), and also verify that the voucher has not been revoked, if
needed. How this is done is described in future sections.
A voucher can contain a number of fields, but it must at least
contain the identifier of the owner the device is being assigned to.
Having the owner assignment enables the device to establish a secure
connection to its owner's network infrastructure.
Watsen, et al. Expires April 30, 2017 [Page 3]
Internet-Draft Voucher and Revocation Profiles October 2016
A voucher revocation ... KENT, move to section
This document uses YANG [RFC7950] to define the voucher and voucher
revocation formats. YANG is a data modeling language with
established mappings to XML and JSON, with mappings to other
encodings in progress. Which encodings a particular solution uses is
outside the scope of this document.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
sections below are to be interpreted as described in RFC 2119
[RFC2119].
3. Tree Diagram Notation
The meaning of the symbols in the above diagram 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.
4. Voucher
4.1. Overview
The following tree diagram provides an overview of the voucher.
Please see Section 3 for information on tree diagram notation.
Watsen, et al. Expires April 30, 2017 [Page 4]
Internet-Draft Voucher and Revocation Profiles October 2016
module: ietf-voucher
+--rw voucher
+--rw assertion enumeration
+--rw owner-id string
+--rw unique-id* string
+--rw created-on yang:date-and-time
+--rw expires-on? yang:date-and-time
+--rw nonce? string
+--rw additional-data?
4.2. Examples
The following illustrates a NETCONF voucher:
verified
owner-23452345
AAA123456789
BBB123456789
CCC123456789
2016-10-07T19:31:42Z
The following illustrates an ANIMA voucher:
{
"ietf-ownership-voucher:voucher": {
"assertion": "logged",
"owner-id": "Registrar3245",
"unique-id": "JADA123456789",
"created-on": "2016-10-07T19:31:42Z"
"nonce": "987987623489567",
}
}
4.3. YANG Module
module ietf-voucher {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-voucher";
prefix "vch";
import ietf-yang-types { prefix yang; }
organization
Watsen, et al. Expires April 30, 2017 [Page 5]
Internet-Draft Voucher and Revocation Profiles October 2016
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web:
WG List:
Author: Kent Watsen
Author: Max Pritikin
Author: Michael Richardson
";
description
"This module defines the format for an voucher,
which is produced by manufacturers to assign a device to an
'owner', so that it may establish secure connections to the
owner's network infrastructure (e.g., controller).";
revision "2016-10-27" {
description
"Initial version";
reference
"RFC XXXX: Voucher and Voucher Revocation Profiles
for Bootstrapping Protocols";
}
// top-level container
container voucher {
description
"A voucher, containing an owner's identifier, a list of
device's unique identifiers, and potentially some other
fields described herein. The voucher must be signed,
but each solution using this voucher needs to specify
how the signature is generated and communicated.";
leaf assertion {
mandatory true;
type enumeration {
enum verified {
description "fixme";
}
enum logged {
description "fixme";
}
}
description
"The assertion is a statement from the manufacturer that it
knows the device by looking into a database or by simply
Watsen, et al. Expires April 30, 2017 [Page 6]
Internet-Draft Voucher and Revocation Profiles October 2016
adding a log entry (open bootstrapping). This allows the
device to know what assurance the manufacturer provides,
which supports more detailed policy checks such as 'I only
want to allow verified devices, not just logged devices'.";
}
leaf owner-id {
type string;
mandatory true;
description
"A manufacturer-assigned value for the owner of the
devices enumerated by this voucher.";
}
leaf-list unique-id {
type string;
min-elements 1;
description
"A regular expression identifying one more more device
unique identifiers. For instance, the expression could
match just a single serial number, or it might match a
range of serial numbers. Devices use this value to
determine if the voucher applies to it.";
}
leaf created-on {
type yang:date-and-time;
mandatory true;
description
"The date this voucher was created";
}
leaf expires-on {
type yang:date-and-time;
description
"An optional date value for when this voucher expires.
In order for the expiration to be honored, devices must
have access to a trusted real time clock.";
}
leaf nonce {
type string; // unit64?
description
"what can be said about this that's ANIMA-neutral?";
}
anydata additional-data {
description
Watsen, et al. Expires April 30, 2017 [Page 7]
Internet-Draft Voucher and Revocation Profiles October 2016
"Additional data signed by the manufacturer. The manufacturer
might put additional data into its vouchers, for human
consumption or for device-consumption, for their devices
only. [Ed. or is this per RFC standards, should we use YANG
'augment' instead?].";
}
}
}
5. Voucher Revocation
5.1. Overview
The following tree diagram provides an overview of the voucher
revocation. Please see Section 3 for information on tree diagram
notation.
module: ietf-voucher-revocation
+--rw voucher-revocation
+--rw revocation-type enumeration
+--rw created-on yang:date-and-time
+--rw expires-on? yang:date-and-time
+--rw (voucher-revocation-type)?
| +--:(issuer-wide)
| | +--rw issuer-wide
| | +--rw (list-type)?
| | +--:(whitelist)
| | | +--rw whitelist
| | | +--rw voucher-identifier* string
| | +--:(blacklist)
| | +--rw blacklist
| | +--rw voucher-identifier* string
| +--:(voucher-specific)
| +--rw voucher-specific
| +--rw voucher-identifier string
| +--rw voucher-status enumeration
| +--rw revocation-information
| +--rw revoked-on yang:date-and-time
| +--rw revocation-reason enumeration
+--rw additional-data?
5.2. Examples
The following illustrates an issuer-wide voucher revocation in XML:
Watsen, et al. Expires April 30, 2017 [Page 8]
Internet-Draft Voucher and Revocation Profiles October 2016
issuer-wide
2016-10-31T23:59:59Z
2016-12-31T23:59:59Z
some fingerprint
some fingerprint
some fingerprint
The following illustrates a voucher-specific revocation in JSON:
{
"ietf-voucher-revocation:voucher-revocation": {
"revocation-type": "voucher-specific",
"created-on": "2016-10-31T23:59:59Z"
"expires-on": "2016-12-31T23:59:59Z"
"voucher-specific": [
"voucher-identifier": "some fingerprint",
"voucher-status": "revoked",
"revocation-information": [
"revoked-on": "2016-11-31T23:59:59Z",
"revocation-reason": "key-compromise"
]
]
}
}
5.3. YANG Module
module ietf-voucher-revocation {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-voucher-revocation";
prefix "vr";
import ietf-yang-types { prefix yang; }
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web:
Watsen, et al. Expires April 30, 2017 [Page 9]
Internet-Draft Voucher and Revocation Profiles October 2016
WG List:
Author: Kent Watsen
Author: Max Pritikin
Author: Michael Richardson
";
description
"This module defines the format for a voucher revocation
which is produced by a manufacturer or a delegate to the
manufacturer to assign a device to an 'owner', so that
it may establish a secure connection to the owner's
network infrastructure.";
revision "2016-10-27" {
description
"Initial version";
reference
"RFC XXXX: Voucher and Voucher Revocation Profiles
for Bootstrapping Protocols";
}
// top-level container
container voucher-revocation {
description
"A voucher revocation, containing...FIXME ";
leaf revocation-type {
mandatory true;
type enumeration {
enum issuer-wide {
description
"Indicates that this revocation spans all
the vouchers the issuer has issued to date";
}
enum voucher-specific {
description
"Indicated that this revocation only regards
a single voucher.";
}
}
description
"The revocation-type indicates if the revocation
is issuer-wide or voucher-specific. Both variations
exist to enable implementions to choose between the
number of revocation artifacts generated versus
individual artifact size.";
Watsen, et al. Expires April 30, 2017 [Page 10]
Internet-Draft Voucher and Revocation Profiles October 2016
}
leaf created-on {
type yang:date-and-time;
mandatory true;
description
"The date this voucher was created";
}
leaf expires-on {
type yang:date-and-time;
description
"An optional date value for when this voucher expires.
In order for the expiration to be honored, devices must
have access to a trusted real time clock.";
}
choice voucher-revocation-type {
container issuer-wide {
choice list-type {
container whitelist {
leaf-list voucher-identifier {
type string;
description
"A fingerprint over the voucher artifact.
Missing if list is empty.";
}
description
"Indicates that the listed of vouchers
are known to be good. If a voucher is
not listed, then it is considered
revoked.";
}
container blacklist {
leaf-list voucher-identifier {
type string;
description
"A fingerprint over the voucher artifact.
Missing if list is empty.";
}
description
"Indicates that the list of vouchers
Watsen, et al. Expires April 30, 2017 [Page 11]
Internet-Draft Voucher and Revocation Profiles October 2016
have been revoked. If a voucher is
not listed, then it is considered
good.";
}
} // end list-type
} // end issuer-wide
container voucher-specific {
leaf voucher-identifier {
type string;
mandatory true;
description
"A fingerprint over the voucher artifact?";
}
leaf voucher-status {
type enumeration {
enum good {
description
"Indicates that this voucher is valid";
}
enum revoked {
description
"Indicates that this voucher is invalid";
}
enum unknown {
description
"Indicates that the voucher's status is unknown";
}
}
mandatory true;
}
container revocation-information {
must "../voucher-status = 'revoked'";
leaf revoked-on {
type yang:date-and-time;
mandatory true;
description
"The date this voucher was revoked";
}
leaf revocation-reason {
Watsen, et al. Expires April 30, 2017 [Page 12]
Internet-Draft Voucher and Revocation Profiles October 2016
type enumeration {
enum unspecified {
description
"Indicates that the reason the voucher
was revoked is unspecified.";
}
enum key-compromise {
description
"Indicates that the reason the voucher
was revoked is because its key was
compromised.";
}
enum issuer-compromise {
description
"Indicates that the reason the voucher
was revoked is because its issuer was
compromised.";
}
enum affiliation-changed {
description
"Indicates that the reason the voucher
was revoked is because its affliation
changed (e.g., device assigned to a
new owner.";
}
enum superseded {
description
"Indicates that the reason the voucher
was revoked is because it has been
superseded (e.g., the previous voucher
expired.";
}
enum cessation-of-operation {
description
"Indicates that the reason the voucher
was revoked is because its issuer has
ceased operations.";
}
} // end enumeration
mandatory true;
description
"modeled after 'CRLReason' in RFC 5280.";
} // end revocation reason
description
"Only present if the voucher has been revoked.";
} // end revocation-information
Watsen, et al. Expires April 30, 2017 [Page 13]
Internet-Draft Voucher and Revocation Profiles October 2016
description
"Modeled after 'ResponseData' in RFC6960.";
} // end voucher-specific
}
anydata additional-data {
description
"Additional data signed by the manufacturer. The manufacturer
might put additional data into its voucher revocations, for
human or device consumption, for their devices only.
[FIXME - or is this per RFC standards, should we use YANG
'augment' instead?].";
}
}
}
6. Security Considerations
FIXME
7. IANA Considerations
7.1. The IETF XML Registry
This document registers one URI in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registration is
requested:
URI: urn:ietf:params:xml:ns:yang:ietf-voucher
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
7.2. The YANG Module Names Registry
This document registers one YANG module in the YANG Module Names
registry [RFC6020]. Following the format defined in [RFC6020], the
the following registration is requested:
name: ietf-voucher
namespace: urn:ietf:params:xml:ns:yang:ietf-voucher
prefix: ztbs
reference: RFC XXXX
Watsen, et al. Expires April 30, 2017 [Page 14]
Internet-Draft Voucher and Revocation Profiles October 2016
8. Acknowledgements
The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name):
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
.
9.2. Informative References
[draft-ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., and S.
Bjarnason, "Bootstrapping Key Infrastructures", draft-
ietf-anima-bootstrapping-keyinfra (work in progress),
2016, .
[draft-ietf-netconf-zerotouch]
Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning
for NETCONF or RESTCONF based Management", draft-ietf-
netconf-zerotouch (work in progress), 2016,
.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
.
Watsen, et al. Expires April 30, 2017 [Page 15]
Internet-Draft Voucher and Revocation Profiles October 2016
Appendix A. Change Log
Authors' Addresses
Kent Watsen
Juniper Networks
EMail: kwatsen@juniper.net
Michael C. Richardson
Sandelman Software Works
EMail: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/
Max Pritikin
Cisco Systems
EMail: pritikin@cisco.com
Toerless Eckert
Cisco Systems
EMail: tte+anima@cs.fau.de
Watsen, et al. Expires April 30, 2017 [Page 16]