draft-ietf-anima-bootstrapping-keyinfra-32.txt   draft-ietf-anima-bootstrapping-keyinfra-33.txt 
ANIMA WG M. Pritikin ANIMA WG M. Pritikin
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Richardson Intended status: Standards Track M. Richardson
Expires: 3 July 2020 Sandelman Expires: 6 July 2020 Sandelman
T.T.E. Eckert T.T.E. Eckert
Futurewei USA Futurewei USA
M.H. Behringer M.H. Behringer
K.W. Watsen K.W. Watsen
Watsen Networks Watsen Networks
31 December 2019 3 January 2020
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-32 draft-ietf-anima-bootstrapping-keyinfra-33
Abstract Abstract
This document specifies automated bootstrapping of an Autonomic This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Secure Key Infrastructure is Control Plane. To do this a Secure Key Infrastructure is
bootstrapped. This is done using manufacturer-installed X.509 bootstrapped. This is done using manufacturer-installed X.509
certificates, in combination with a manufacturer's authorizing certificates, in combination with a manufacturer's authorizing
service, both online and offline. We call this process the service, both online and offline. We call this process the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
Bootstrapping a new device can occur using a routable address and a Bootstrapping a new device can occur using a routable address and a
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 https://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 3 July 2020. This Internet-Draft will expire on 6 July 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 64 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 64
7.2. Pledge security reductions . . . . . . . . . . . . . . . 64 7.2. Pledge security reductions . . . . . . . . . . . . . . . 64
7.3. Registrar security reductions . . . . . . . . . . . . . . 65 7.3. Registrar security reductions . . . . . . . . . . . . . . 65
7.4. MASA security reductions . . . . . . . . . . . . . . . . 66 7.4. MASA security reductions . . . . . . . . . . . . . . . . 66
7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 67 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 67
7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 67 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 67
7.4.3. Updating or extending voucher trust anchors . . . . . 68 7.4.3. Updating or extending voucher trust anchors . . . . . 68
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69
8.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69 8.2. YANG Module Names Registry . . . . . . . . . . . . . . . 69
8.3. Well-known EST registration . . . . . . . . . . . . . . . 69 8.3. Well-known EST registration . . . . . . . . . . . . . . . 69
8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 70 8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 70
8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 70 8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 70
8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70 8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 71 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 71
9.1. Operational Requirements . . . . . . . . . . . . . . . . 72 9.1. Operational Requirements . . . . . . . . . . . . . . . . 72
9.1.1. MASA Operational Requirements . . . . . . . . . . . . 72 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 72
9.1.2. Domain Owner Operational Requirements . . . . . . . . 73 9.1.2. Domain Owner Operational Requirements . . . . . . . . 73
9.1.3. Device Operational Requirements . . . . . . . . . . . 74 9.1.3. Device Operational Requirements . . . . . . . . . . . 74
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 74 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 74
skipping to change at page 4, line 40 skipping to change at page 4, line 40
11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 84 11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 84
11.6. Manufacturer Maintenance of trust anchors . . . . . . . 85 11.6. Manufacturer Maintenance of trust anchors . . . . . . . 85
11.6.1. Compromise of Manufacturer IDevID signing keys . . . 87 11.6.1. Compromise of Manufacturer IDevID signing keys . . . 87
11.6.2. Compromise of MASA signing keys . . . . . . . . . . 87 11.6.2. Compromise of MASA signing keys . . . . . . . . . . 87
11.6.3. Compromise of MASA web service . . . . . . . . . . . 89 11.6.3. Compromise of MASA web service . . . . . . . . . . . 89
11.7. YANG Module Security Considerations . . . . . . . . . . 90 11.7. YANG Module Security Considerations . . . . . . . . . . 90
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90
13.1. Normative References . . . . . . . . . . . . . . . . . . 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 90
13.2. Informative References . . . . . . . . . . . . . . . . . 94 13.2. Informative References . . . . . . . . . . . . . . . . . 94
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 97 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 98
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 97 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 98
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 98 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 98
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 98 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 98
Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 99 Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 99
C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 99 C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 99
C.1.1. MASA key pair for voucher signatures . . . . . . . . 99 C.1.1. MASA key pair for voucher signatures . . . . . . . . 99
C.1.2. Manufacturer key pair for IDevID signatures . . . . . 100 C.1.2. Manufacturer key pair for IDevID signatures . . . . . 100
C.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 100 C.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 100
C.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 102 C.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 102
C.2. Example process . . . . . . . . . . . . . . . . . . . . . 104 C.2. Example process . . . . . . . . . . . . . . . . . . . . . 104
C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 105 C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 105
C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 108 C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 108
C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 113 C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 113
Appendix D. Additional References . . . . . . . . . . . . . . . 117
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117
1. Introduction 1. Introduction
The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
provides a solution for secure zero-touch (automated) bootstrap of provides a solution for secure zero-touch (automated) bootstrap of
new (unconfigured) devices that are called pledges in this document. new (unconfigured) devices that are called pledges in this document.
Pledges have an IDevID installed in them at the factory. Pledges have an IDevID installed in them at the factory.
"BRSKI" is pronounced like "brewski", a colloquial term for beer in "BRSKI" is pronounced like "brewski", a colloquial term for beer in
skipping to change at page 29, line 47 skipping to change at page 29, line 47
} }
import ietf-voucher { import ietf-voucher {
prefix vch; prefix vch;
description "This module defines the format for a voucher, description "This module defines the format for a voucher,
which is produced by a pledge's manufacturer or which is produced by a pledge's manufacturer or
delegate (MASA) to securely assign a pledge to delegate (MASA) to securely assign a pledge to
an 'owner', so that the pledge may establish a secure an 'owner', so that the pledge may establish a secure
connection to the owner's network infrastructure"; connection to the owner's network infrastructure";
reference "RFC 8366: Voucher Profile for Bootstrapping Protocols"; reference "RFC 8366: Voucher Artifact for Bootstrapping Protocols";
} }
organization organization
"IETF ANIMA Working Group"; "IETF ANIMA Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/anima/> "WG Web: <https://datatracker.ietf.org/wg/anima/>
WG List: <mailto:anima@ietf.org> WG List: <mailto:anima@ietf.org>
Author: Kent Watsen Author: Kent Watsen
<mailto:kent+ietf@watsen.net> <mailto:kent+ietf@watsen.net>
skipping to change at page 30, line 47 skipping to change at page 30, line 47
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 "2018-02-14" { revision "2018-02-14" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Voucher Profile for Bootstrapping Protocols"; "RFC XXXX: Bootstrapping Remote Secure Key Infrastructure";
} }
// Top-level statement // Top-level statement
rc:yang-data voucher-request-artifact { rc:yang-data voucher-request-artifact {
uses voucher-request-grouping; uses voucher-request-grouping;
} }
// Grouping defined for future usage // Grouping defined for future usage
grouping voucher-request-grouping { grouping voucher-request-grouping {
skipping to change at page 32, line 18 skipping to change at page 32, line 18
remove all prior-signed-voucher-request information when remove all prior-signed-voucher-request information when
signing a voucher for imprinting so as to minimize the signing a voucher for imprinting so as to minimize the
final voucher size."; final voucher size.";
} }
leaf proximity-registrar-cert { leaf proximity-registrar-cert {
type binary; type binary;
description description
"An X.509 v3 certificate structure as specified by RFC 5280, "An X.509 v3 certificate structure as specified by RFC 5280,
Section 4 encoded using the ASN.1 distinguished encoding Section 4 encoded using the ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690. rules (DER), as specified in [ITU.X690.1994].
The first certificate in the Registrar TLS server The first certificate in the Registrar TLS server
certificate_list sequence (the end-entity TLS certificate, certificate_list sequence (the end-entity TLS certificate,
see [RFC8446]) presented by the Registrar to the Pledge. see [RFC8446]) presented by the Registrar to the Pledge.
This MUST be populated in a Pledge's voucher request when a This MUST be populated in a Pledge's voucher request when a
proximity assertion is requested."; proximity assertion is requested.";
} }
} }
} }
} }
skipping to change at page 69, line 34 skipping to change at page 69, line 34
8.1. The IETF XML Registry 8.1. The IETF XML Registry
This document registers a URI in the "IETF XML Registry" [RFC3688]. This document registers a URI in the "IETF XML Registry" [RFC3688].
IANA is asked to register the following: IANA is asked to register the following:
URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request
Registrant Contact: The ANIMA WG of the IETF. Registrant Contact: The ANIMA WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
8.2. The IETF XML Registry 8.2. YANG Module Names Registry
This document registers a YANG module in the "YANG Module Names" This document registers a YANG module in the "YANG Module Names"
registry [RFC6020]. IANA is asked to register the following: registry [RFC6020]. IANA is asked to register the following:
name: ietf-voucher-request name: ietf-voucher-request
namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request
prefix: vch prefix: vch
reference: THIS DOCUMENT reference: THIS DOCUMENT
8.3. Well-known EST registration 8.3. Well-known EST registration
skipping to change at page 91, line 16 skipping to change at page 91, line 16
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", Work in Progress, Autonomic Signaling Protocol (GRASP)", Work in Progress,
Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017,
<http://www.ietf.org/internet-drafts/draft-ietf-anima- <http://www.ietf.org/internet-drafts/draft-ietf-anima-
grasp-15.txt>. grasp-15.txt>.
[IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009,
<http://standards.ieee.org/findstds/standard/802.1AR- <http://standards.ieee.org/findstds/standard/802.1AR-
2009.html>. 2009.html>.
[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.
[REST] Fielding, R.F., "Architectural Styles and the Design of [REST] Fielding, R.F., "Architectural Styles and the Design of
Network-based Software Architectures", 2000, Network-based Software Architectures", 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/ <http://www.ics.uci.edu/~fielding/pubs/dissertation/
top.htm>. top.htm>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 117, line 7 skipping to change at page 117, line 7
1534:d=7 hl=2 l= 15 cons: SET 1534:d=7 hl=2 l= 15 cons: SET
1536:d=8 hl=2 l= 13 prim: UTCTIME :190516025142Z 1536:d=8 hl=2 l= 13 prim: UTCTIME :190516025142Z
1551:d=6 hl=2 l= 47 cons: SEQUENCE 1551:d=6 hl=2 l= 47 cons: SEQUENCE
1553:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 1553:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
1564:d=7 hl=2 l= 34 cons: SET 1564:d=7 hl=2 l= 34 cons: SET
1566:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:98461E22DB5423 1566:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:98461E22DB5423
1600:d=5 hl=2 l= 10 cons: SEQUENCE 1600:d=5 hl=2 l= 10 cons: SEQUENCE
1602:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1602:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1612:d=5 hl=2 l= 104 prim: OCTET STRING [HEX DUMP]:30660231009860 1612:d=5 hl=2 l= 104 prim: OCTET STRING [HEX DUMP]:30660231009860
Appendix D. Additional References
RFC EDITOR Please remove this section before publication. It exists
just to include references to the things in the YANG descriptions
which are not otherwise referenced in the text so that xml2rfc will
not complain.
[ITU.X690.1994]
Authors' Addresses Authors' Addresses
Max Pritikin Max Pritikin
Cisco Cisco
Email: pritikin@cisco.com Email: pritikin@cisco.com
Michael C. Richardson Michael C. Richardson
Sandelman Software Works Sandelman Software Works
 End of changes. 14 change blocks. 
12 lines changed or deleted 29 lines changed or added

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