draft-ietf-anima-brski-cloud-00.txt   draft-ietf-anima-brski-cloud-01.txt 
Network Working Group O. Friel Network Working Group O. Friel
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track R. Shekh-Yusef Intended status: Standards Track R. Shekh-Yusef
Expires: 30 October 2021 Auth0 Expires: 12 January 2022 Auth0
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
28 April 2021 11 July 2021
BRSKI Cloud Registrar BRSKI Cloud Registrar
draft-ietf-anima-brski-cloud-00 draft-ietf-anima-brski-cloud-01
Abstract Abstract
This document specifies the behaviour of a BRSKI Cloud Registrar, and This document specifies the behaviour of a BRSKI Cloud Registrar, and
how a pledge can interact with a BRSKI Cloud Registrar when how a pledge can interact with a BRSKI Cloud Registrar when
bootstrapping. bootstrapping.
RFCED REMOVE: It is being actively worked on at https://github.com/ RFCED REMOVE: It is being actively worked on at https://github.com/
anima-wg/brski-cloud anima-wg/brski-cloud
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 30 October 2021. This Internet-Draft will expire on 12 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Target Use Cases . . . . . . . . . . . . . . . . . . . . 3 1.2. Target Use Cases . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Owner Registrar Discovery . . . . . . . . . . . . . . 4 1.2.1. Owner Registrar Discovery . . . . . . . . . . . . . . 4
1.2.2. Bootstrapping with no Owner Registrar . . . . . . . . 4 1.2.2. Bootstrapping with no Owner Registrar . . . . . . . . 4
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Interested Parties . . . . . . . . . . . . . . . . . . . 5 2.1. Interested Parties . . . . . . . . . . . . . . . . . . . 6
2.2. Network Connectivity . . . . . . . . . . . . . . . . . . 6 2.2. Network Connectivity . . . . . . . . . . . . . . . . . . 6
2.3. Pledge Certificate Identity Considerations . . . . . . . 6 2.3. Pledge Certificate Identity Considerations . . . . . . . 6
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6
3.1. Pledge Requests Voucher from Cloud Registrar . . . . . . 6 3.1. Pledge Requests Voucher from Cloud Registrar . . . . . . 6
3.1.1. Cloud Registrar Discovery . . . . . . . . . . . . . . 6 3.1.1. Cloud Registrar Discovery . . . . . . . . . . . . . . 7
3.1.2. Pledge - Cloud Registrar TLS Establishment Details . 7 3.1.2. Pledge - Cloud Registrar TLS Establishment Details . 7
3.1.3. Pledge Issues Voucher Request . . . . . . . . . . . . 7 3.1.3. Pledge Issues Voucher Request . . . . . . . . . . . . 8
3.2. Cloud Registrar Handles Voucher Request . . . . . . . . . 7 3.2. Cloud Registrar Handles Voucher Request . . . . . . . . . 8
3.2.1. Pledge Ownership Lookup . . . . . . . . . . . . . . . 8 3.2.1. Pledge Ownership Lookup . . . . . . . . . . . . . . . 8
3.2.2. Cloud Registrar Redirects to Owner Registrar . . . . 8 3.2.2. Cloud Registrar Redirects to Owner Registrar . . . . 8
3.2.3. Cloud Registrar Issues Voucher . . . . . . . . . . . 8 3.2.3. Cloud Registrar Issues Voucher . . . . . . . . . . . 9
3.3. Pledge Handles Cloud Registrar Response . . . . . . . . . 9 3.3. Pledge Handles Cloud Registrar Response . . . . . . . . . 9
3.3.1. Redirect Response . . . . . . . . . . . . . . . . . . 9 3.3.1. Redirect Response . . . . . . . . . . . . . . . . . . 9
3.3.2. Voucher Response . . . . . . . . . . . . . . . . . . 9 3.3.2. Voucher Response . . . . . . . . . . . . . . . . . . 9
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Voucher Request Redirected to Local Domain Registrar . . 9 4.1. Voucher Request Redirected to Local Domain Registrar . . 10
4.2. Voucher Request Handled by Cloud Registrar . . . . . . . 11 4.2. Voucher Request Handled by Cloud Registrar . . . . . . . 12
5. YANG extension for Voucher based redirect . . . . . . . . . . 13 5. YANG extension for Voucher based redirect . . . . . . . . . . 14
5.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. YANG Voucher . . . . . . . . . . . . . . . . . . . . . . 14 5.2. YANG Voucher . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies
[I-D.ietf-anima-bootstrapping-keyinfra] specifies automated automated bootstrapping of an Autonomic Control Plane. BRSKI
bootstrapping of an Autonomic Control Plane. BRSKI Section 2.7 Section 2.7 describes how a pledge "MAY contact a well known URI of a
describes how a pledge "MAY contact a well known URI of a cloud cloud registrar if a local registrar cannot be discovered or if the
registrar if a local registrar cannot be discovered or if the
pledge's target use cases do not include a local registrar". pledge's target use cases do not include a local registrar".
This document further specifies use of a BRSKI cloud registrar and This document further specifies use of a BRSKI cloud registrar and
clarifies operations that are not sufficiently specified in BRSKI. clarifies operations that are not sufficiently specified in BRSKI.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the terms Pledge, Registrar, MASA, and Voucher This document uses the terms Pledge, Registrar, MASA, and Voucher
from [I-D.ietf-anima-bootstrapping-keyinfra] and [RFC8366]. from [BRSKI] and [RFC8366].
* Local Domain: The domain where the pledge is physically located * Local Domain: The domain where the pledge is physically located
and bootstrapping from. This may be different to the pledge and bootstrapping from. This may be different to the pledge
owner's domain. owner's domain.
* Owner Domain: The domain that the pledge needs to discover and * Owner Domain: The domain that the pledge needs to discover and
bootstrap with. bootstrap with.
* Cloud Registrar: The default Registrar that is deployed at a URI * Cloud Registrar: The default Registrar that is deployed at a URI
that is well known to the pledge. that is well known to the pledge.
skipping to change at page 13, line 5 skipping to change at page 14, line 5
voucher request to the Cloud RA/MASA, and in response the Pledge voucher request to the Cloud RA/MASA, and in response the Pledge
receives an [RFC8366] format voucher from the Cloud RA/MASA that receives an [RFC8366] format voucher from the Cloud RA/MASA that
includes its assigned EST domain in the est-domain attribute. includes its assigned EST domain in the est-domain attribute.
At this stage, the Pledge should be able to establish a TLS channel At this stage, the Pledge should be able to establish a TLS channel
with the EST Registrar. The connection may involve crossing the with the EST Registrar. The connection may involve crossing the
Internet requiring a DNS lookup on the provided name. It may also be Internet requiring a DNS lookup on the provided name. It may also be
a local address that includes an IP address literal including both a local address that includes an IP address literal including both
[RFC1918] and IPv6 Unique Local Address. The EST Registrar is [RFC1918] and IPv6 Unique Local Address. The EST Registrar is
validated using the pinned-domain-cert value provided in the voucher validated using the pinned-domain-cert value provided in the voucher
as described in section 5.6.2 of as described in Section 5.6.2 of [BRSKI]. This involves treating the
[I-D.ietf-anima-bootstrapping-keyinfra]. This involves treating the
artifact provided in the pinned-domain-cert as a trust anchor, and artifact provided in the pinned-domain-cert as a trust anchor, and
attempting to validate the EST Registrar from this anchor only. attempting to validate the EST Registrar from this anchor only.
There is a case where the pinned-domain-cert is the identical End- There is a case where the pinned-domain-cert is the identical End-
Entity (EE) Certificate as the EST Registrar. It also explicitly Entity (EE) Certificate as the EST Registrar. It also explicitly
includes the case where the EST Registrar has a self-signed EE includes the case where the EST Registrar has a self-signed EE
Certificate, but it may also be an EE certificate that is part of a Certificate, but it may also be an EE certificate that is part of a
larger PKI. If the certificate is not a self-signed or EE larger PKI. If the certificate is not a self-signed or EE
certificate, then the Pledge SHOULD apply [RFC6125] DNS-ID validation certificate, then the Pledge SHOULD apply [RFC6125] DNS-ID validation
on the certificate against the URL provided in the est-domain on the certificate against the URL provided in the est-domain
skipping to change at page 14, line 4 skipping to change at page 15, line 4
with the CSR and obtains the requested certificate. The Pledge must with the CSR and obtains the requested certificate. The Pledge must
validate that the issued certificate has the expected identifier validate that the issued certificate has the expected identifier
obtained from the Cloud RA/MASA in step 3. obtained from the Cloud RA/MASA in step 3.
5. YANG extension for Voucher based redirect 5. YANG extension for Voucher based redirect
An extension to the [RFC8366] voucher is needed for the case where An extension to the [RFC8366] voucher is needed for the case where
the client will be redirected to a local EST Registrar. the client will be redirected to a local EST Registrar.
5.1. YANG Tree 5.1. YANG Tree
module: ietf-redirected-voucher module: ietf-voucher-redirected
grouping voucher-redirected-grouping grouping voucher-redirected-grouping
+-- 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
+-- est-domain? ietf:uri +-- est-domain? ietf:uri
+-- additional-configuration? ietf:uri +-- additional-configuration? ietf:uri
5.2. YANG Voucher 5.2. YANG Voucher
<CODE BEGINS> file "ietf-redirected-voucher@2020-09-23.yang" <CODE BEGINS> file "ietf-voucher-redirected@2020-09-23.yang"
module ietf-redirected-voucher { module ietf-voucher-redirected {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-redirected-voucher"; "urn:ietf:params:xml:ns:yang:ietf-voucher-redirected";
prefix "redirected"; prefix "redirected";
import ietf-restconf { import ietf-restconf {
prefix rc; prefix rc;
description description
"This import statement is only present to access "This import statement is only present to access
the yang-data extension defined in RFC 8040."; the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol"; reference "RFC 8040: RESTCONF Protocol";
} }
skipping to change at page 16, line 15 skipping to change at page 17, line 15
a VoIP phone to point to the correct hosted PBX, for example."; a VoIP phone to point to the correct hosted PBX, for example.";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6. IANA Considerations 6. IANA Considerations
TODO:MCR - Will need to add IETF YANG registration from templates. [[ 6.1. The IETF XML Registry
TODO ]]
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-redirected
Registrant Contact:
The ANIMA WG of the IETF.
XML:
N/A, the requested URI is an XML namespace.
6.2. The YANG Module Names Registry
This document registers two YANG modules in the YANG Module Names
registry [RFC6020]. Following the format defined in [RFC6020], the
the following registration is requested:
name:
ietf-voucher-redirected
namespace:
urn:ietf:params:xml:ns:yang:ietf-voucher-redirected
prefix:
vch
reference:
THIS DOCUMENT
7. Security Considerations 7. Security Considerations
[[ TODO ]] [[ TODO ]]
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-anima-bootstrapping-keyinfra] [BRSKI] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. and K. Watsen, "Bootstrapping Remote Secure Key
H., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
Infrastructures (BRSKI)", Work in Progress, Internet- May 2021, <https://www.rfc-editor.org/info/rfc8995>.
Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11
November 2020, <https://www.ietf.org/archive/id/draft-
ietf-anima-bootstrapping-keyinfra-45.txt>.
[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>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
skipping to change at page 17, line 17 skipping to change at page 18, line 45
[IEEE802.1AR] [IEEE802.1AR]
IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
2018, <http://standards.ieee.org/findstds/ 2018, <http://standards.ieee.org/findstds/
standard/802.1AR-2018.html>. standard/802.1AR-2018.html>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>. February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
 End of changes. 19 change blocks. 
44 lines changed or deleted 80 lines changed or added

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