draft-ietf-anima-bootstrapping-keyinfra-40.txt   draft-ietf-anima-bootstrapping-keyinfra-41.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: 4 October 2020 Sandelman Expires: 10 October 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
2 April 2020 8 April 2020
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-40 draft-ietf-anima-bootstrapping-keyinfra-41
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 4 October 2020. This Internet-Draft will expire on 10 October 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 30, line 25 skipping to change at page 30, line 25
<mailto:pritikin@cisco.com> <mailto:pritikin@cisco.com>
Author: Michael Richardson Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>"; <mailto:mcr+ietf@sandelman.ca>";
description description
"This module defines the format for a voucher request. "This module defines the format for a voucher request.
It is a superset of the voucher itself. It is a superset of the voucher itself.
It provides content to the MASA for consideration It provides content to the MASA for consideration
during a voucher request. during a voucher request.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 RFC2119 RFC8174 when, and only when, they described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
appear in all capitals, as shown here. they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
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).
skipping to change at page 40, line 15 skipping to change at page 40, line 15
[RFC7030] wherein the client is authenticated with the IDevID [RFC7030] wherein the client is authenticated with the IDevID
certificate, and the EST server (the registrar) is provisionally certificate, and the EST server (the registrar) is provisionally
authenticated with an unverified server certificate. Configuration authenticated with an unverified server certificate. Configuration
or distribution of the trust anchor database used for validating the or distribution of the trust anchor database used for validating the
IDevID certificate is out-of-scope of this specification. Note that IDevID certificate is out-of-scope of this specification. Note that
the trust anchors in/excluded from the database will affect which the trust anchors in/excluded from the database will affect which
manufacturers' devices are acceptable to the registrar as pledges, manufacturers' devices are acceptable to the registrar as pledges,
and can also be used to limit the set of MASAs that are trusted for and can also be used to limit the set of MASAs that are trusted for
enrollment. enrollment.
The signatures in the certificate MUST be validated even if a signing The signature in the certificate MUST be validated even if a signing
key can not (yet) be validated. The certificate (or chain) MUST be key can not (yet) be validated. The certificate (or chain) MUST be
retained for later validation. retained for later validation.
A self-signed certificate for the Registrar is acceptable as the A self-signed certificate for the Registrar is acceptable as the
voucher can validate it upon successful enrollment. voucher can validate it upon successful enrollment.
The pledge performs input validation of all data received until a The pledge performs input validation of all data received until a
voucher is verified as specified in Section 5.6.1 and the TLS voucher is verified as specified in Section 5.6.1 and the TLS
connection leaves the provisional state. Until these operations are connection leaves the provisional state. Until these operations are
complete the pledge could be communicating with an attacker. complete the pledge could be communicating with an attacker.
skipping to change at page 41, line 44 skipping to change at page 41, line 44
strong random or pseudo-random number nonce (see [RFC4086] section strong random or pseudo-random number nonce (see [RFC4086] section
6.2). As the nonce is usually generated very early in the boot 6.2). As the nonce is usually generated very early in the boot
sequence there is a concern that the same nonce might generated sequence there is a concern that the same nonce might generated
across multiple boots, or after a factory reset. Different nonces across multiple boots, or after a factory reset. Different nonces
MUST be generated for each bootstrapping attempt, whether in MUST be generated for each bootstrapping attempt, whether in
series or concurrently. The freshness of this nonce mitigates series or concurrently. The freshness of this nonce mitigates
against the lack of real-time clock as explained in Section 2.6.1. against the lack of real-time clock as explained in Section 2.6.1.
assertion: The pledge indicates support for the mechanism described assertion: The pledge indicates support for the mechanism described
in this document, by putting the value "proximity" in the voucher- in this document, by putting the value "proximity" in the voucher-
request, and MUST include the "proximity-registrar-cert" field request, MUST include the "proximity-registrar-cert" field
(below). (below).
proximity-registrar-cert: In a pledge voucher-request this is the proximity-registrar-cert: In a pledge voucher-request this is the
first certificate in the TLS server 'certificate_list' sequence first certificate in the TLS server 'certificate_list' sequence
(see [RFC5246]) presented by the registrar to the pledge. That (see [RFC5246]) presented by the registrar to the pledge. That
is, it is the end-entity certificate. This MUST be populated in a is, it is the end-entity certificate. This MUST be populated in a
pledge voucher-request. pledge voucher-request.
serial-number The serial number of the pledge is included in the serial-number The serial number of the pledge is included in the
voucher-request from the Pledge. This value is included as a voucher-request from the Pledge. This value is included as a
skipping to change at page 43, line 24 skipping to change at page 43, line 24
override it is appropriate to provide alternate anchors. This will override it is appropriate to provide alternate anchors. This will
typically used by some vendors to establish explicit (or private) typically used by some vendors to establish explicit (or private)
trust anchors for validating their MASA that is part of a sales trust anchors for validating their MASA that is part of a sales
channel integration. channel integration.
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED. TLS 1.3 (or newer) SHOULD be available. REQUIRED. TLS 1.3 (or newer) SHOULD be available.
As described in [RFC7030], the MASA and the registrars SHOULD be As described in [RFC7030], the MASA and the registrars SHOULD be
prepared to support TLS client certificate authentication and/or HTTP prepared to support TLS client certificate authentication and/or HTTP
Basic or Digest authentication. This connection MAY also have no Basic, Digest, or SCRAM authentication. This connection MAY also
client authentication at all. have no client authentication at all.
Registrars SHOULD permit trust anchors to be pre-configured on a per- Registrars SHOULD permit trust anchors to be pre-configured on a per-
vendor(MASA) basis. Registrars SHOULD include the ability to vendor(MASA) basis. Registrars SHOULD include the ability to
configure a TLS ClientCertificate on a per-MASA basis, or to use no configure a TLS ClientCertificate on a per-MASA basis, or to use no
client certificate. Registrars SHOULD also permit HTTP Basic and client certificate. Registrars SHOULD also permit HTTP Basic and
Digest authentication to be configured. Digest authentication to be configured.
The authentication of the BRSKI-MASA connection does not change the The authentication of the BRSKI-MASA connection does not change the
voucher-request process, as voucher-requests are already signed by voucher-request process, as voucher-requests are already signed by
the registrar. Instead, this authentication provides access control the registrar. Instead, this authentication provides access control
skipping to change at page 44, line 47 skipping to change at page 44, line 47
interface ([RFC7231]). interface ([RFC7231]).
This is done with an HTTP POST using the operation path value of This is done with an HTTP POST using the operation path value of
"/.well-known/est/requestvoucher". "/.well-known/est/requestvoucher".
The voucher media type "application/voucher-cms+json" is defined in The voucher media type "application/voucher-cms+json" is defined in
[RFC8366] and is also used for the registrar voucher-request. It is [RFC8366] and is also used for the registrar voucher-request. It is
a JSON document that has been signed using a CMS structure. The a JSON document that has been signed using a CMS structure. The
registrar MUST sign the registrar voucher-request. registrar MUST sign the registrar voucher-request.
MASA implementations SHOULD anticipate future media ntypes but of
course will simply fail the request if those types are not yet known.
The voucher-request CMS object includes some number of certificates The voucher-request CMS object includes some number of certificates
that are input to the MASA as it populates the 'pinned-domain-cert'. that are input to the MASA as it populates the 'pinned-domain-cert'.
As the [RFC8366] is quite flexible in what may be put into the As the [RFC8366] is quite flexible in what may be put into the
'pinned-domain-cert', the MASA needs some signal as to what 'pinned-domain-cert', the MASA needs some signal as to what
certificate would be effective to populate the field with: it may certificate would be effective to populate the field with: it may
range from the End Entity (EE) Certificate that the Registrar uses, range from the End Entity (EE) Certificate that the Registrar uses,
to the entire private Enterprise CA certificate. More specific to the entire private Enterprise CA certificate. More specific
certificates result in a tighter binding of the voucher to the certificates result in a tighter binding of the voucher to the
domain, while less specific certificates result in more flexibility domain, while less specific certificates result in more flexibility
in how the domain is represented by certificates. in how the domain is represented by certificates.
skipping to change at page 45, line 30 skipping to change at page 45, line 33
The Registrar SHOULD request a voucher with the most specificity The Registrar SHOULD request a voucher with the most specificity
consistent with the mode that it is operating in. In order to do consistent with the mode that it is operating in. In order to do
this, when the Registrar prepares the CMS structure for the signed this, when the Registrar prepares the CMS structure for the signed
voucher-request, it SHOULD include only certificates which are part voucher-request, it SHOULD include only certificates which are part
of the chain that it wishes the MASA to pin. This MAY be as small as of the chain that it wishes the MASA to pin. This MAY be as small as
only the End-Entity certificate (with id-kp-cmcRA set) that it uses only the End-Entity certificate (with id-kp-cmcRA set) that it uses
as it's TLS Server Certificate, or it MAY be the entire chain, as it's TLS Server Certificate, or it MAY be the entire chain,
including the Domain CA. including the Domain CA.
MASA impementations SHOULD anticipate future media types but of
course will simply fail the request if those types are not yet known.
The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept" The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept"
header field indicating the response media types that are acceptable. header field indicating the response media types that are acceptable.
This list SHOULD be the entire list presented to the Registrar in the This list SHOULD be the entire list presented to the Registrar in the
Pledge's original request (see Section 5.2) but MAY be a subset. The Pledge's original request (see Section 5.2) but MAY be a subset. The
MASA is expected to be flexible in what it accepts. MASA is expected to be flexible in what it accepts.
The registrar populates the voucher-request fields as follows: The registrar populates the voucher-request fields as follows:
created-on: The Registrars SHOULD populate this field with the created-on: The Registrars SHOULD populate this field with the
current date and time when the Registrar formed this voucher current date and time when the Registrar formed this voucher
skipping to change at page 47, line 27 skipping to change at page 47, line 27
container. This chain may be as short as a single End-Entity container. This chain may be as short as a single End-Entity
Certificate, up to the entire registrar certificate chain, including Certificate, up to the entire registrar certificate chain, including
the Domain CA certificate, as specified in Section 5.5. the Domain CA certificate, as specified in Section 5.5.
If the domain's CA is unknown to the MASA, then it is to be If the domain's CA is unknown to the MASA, then it is to be
considered a temporary trust anchor for the rest of the steps in this considered a temporary trust anchor for the rest of the steps in this
section. The intention is not to authenticate the message as having section. The intention is not to authenticate the message as having
come from a fully validated origin, but to establish the consistency come from a fully validated origin, but to establish the consistency
of the domain PKI. of the domain PKI.
The MASA MAY use the highest certificate from the certificate chain The MASA MAY use the certificate farthest in the chain chain that it
that it received from the Registrar, as determined by MASA policy. A received from the Registrar from the end-entity, as determined by
MASA MAY have a local policy that it only pins the End-Entity MASA policy. A MASA MAY have a local policy that it only pins the
certificate. This is consistent with [RFC8366]. Details of the End-Entity certificate. This is consistent with [RFC8366]. Details
policy will typically depend upon the degree of Supply Chain of the policy will typically depend upon the degree of Supply Chain
Integration, and the mechanism used by the Registrar to authenticate. Integration, and the mechanism used by the Registrar to authenticate.
Such a policy would also determine how a the MASA will respond to a Such a policy would also determine how a the MASA will respond to a
request for a nonceless voucher. request for a nonceless voucher.
5.5.3. MASA checking of voucher request signature 5.5.3. MASA checking of voucher request signature
As described in Section 5.5.2, the MASA has extracted Registrar's As described in Section 5.5.2, the MASA has extracted Registrar's
domain CA. This is used to validate the CMS signature ([RFC5652]) on domain CA. This is used to validate the CMS signature ([RFC5652]) on
the voucher-request. the voucher-request.
skipping to change at page 50, line 40 skipping to change at page 50, line 40
pledge returns to discovery state. pledge returns to discovery state.
A pledge that retries a request after receiving a 202 message MUST A pledge that retries a request after receiving a 202 message MUST
resend the same voucher-request. It MUST NOT sign a new voucher- resend the same voucher-request. It MUST NOT sign a new voucher-
request each time, and in particular, it MUST NOT change the nonce request each time, and in particular, it MUST NOT change the nonce
value. value.
In order to avoid infinite redirect loops, which a malicious In order to avoid infinite redirect loops, which a malicious
registrar might do in order to keep the pledge from discovering the registrar might do in order to keep the pledge from discovering the
correct registrar, the pledge MUST NOT follow more than one correct registrar, the pledge MUST NOT follow more than one
redirection (3xx code) to another web origins. EST supports redirection (3xx code) to another web origin. EST supports
redirection but requires user input; this change allows the pledge to redirection but requires user input; this change allows the pledge to
follow a single redirection without a user interaction. follow a single redirection without a user interaction.
A 403 (Forbidden) response is appropriate if the voucher-request is A 403 (Forbidden) response is appropriate if the voucher-request is
not signed correctly, stale, or if the pledge has another outstanding not signed correctly, stale, or if the pledge has another outstanding
voucher that cannot be overridden. voucher that cannot be overridden.
A 404 (Not Found) response is appropriate when the request is for a A 404 (Not Found) response is appropriate when the request is for a
device that is not known to the MASA. device that is not known to the MASA.
skipping to change at page 52, line 42 skipping to change at page 52, line 42
(this is likely included in the pledge's firmware). Management of (this is likely included in the pledge's firmware). Management of
the manufacturer-installed trust anchor(s) is out-of-scope of this the manufacturer-installed trust anchor(s) is out-of-scope of this
document; this protocol does not update these trust anchor(s). document; this protocol does not update these trust anchor(s).
The pledge MUST verify the serial-number field of the signed voucher The pledge MUST verify the serial-number field of the signed voucher
matches the pledge's own serial-number. matches the pledge's own serial-number.
The pledge MUST verify the nonce information in the voucher. If The pledge MUST verify the nonce information in the voucher. If
present, the nonce in the voucher must match the nonce the pledge present, the nonce in the voucher must match the nonce the pledge
submitted to the registrar; vouchers with no nonce can also be submitted to the registrar; vouchers with no nonce can also be
accepted (according to local policy, see Section 7.2. accepted (according to local policy, see Section 7.2)
The pledge MUST be prepared to parse and fail gracefully from a The pledge MUST be prepared to parse and fail gracefully from a
voucher response that does not contain a 'pinned-domain-cert' field. voucher response that does not contain a 'pinned-domain-cert' field.
Such a thing indicates a failure to enroll in this domain, and the Such a thing indicates a failure to enroll in this domain, and the
pledge MUST attempt joining with other available Join Proxy. pledge MUST attempt joining with other available Join Proxy.
The pledge MUST be prepared to ignore additional fields that it does The pledge MUST be prepared to ignore additional fields that it does
not recognize. not recognize.
5.6.2. Pledge authentication of provisional TLS connection 5.6.2. Pledge authentication of provisional TLS connection
skipping to change at page 77, line 15 skipping to change at page 77, line 15
10.3. What BRSKI-MASA reveals to the manufacturer 10.3. What BRSKI-MASA reveals to the manufacturer
With consumer-oriented devices, the "call-home" mechanism in IoT With consumer-oriented devices, the "call-home" mechanism in IoT
devices raises significant privacy concerns. See [livingwithIoT] and devices raises significant privacy concerns. See [livingwithIoT] and
[IoTstrangeThings] for exemplars. The Autonomic Control Plane (ACP) [IoTstrangeThings] for exemplars. The Autonomic Control Plane (ACP)
usage of BRSKI is not targeted at individual usage of IoT devices, usage of BRSKI is not targeted at individual usage of IoT devices,
but rather at the Enterprise and ISP creation of networks in a zero- but rather at the Enterprise and ISP creation of networks in a zero-
touch fashion where the "call-home" represents a different class of touch fashion where the "call-home" represents a different class of
privacy and lifecycle management concerns. privacy and lifecycle management concerns.
As the Autonomic Control Plane (ACP) usage of BRSKI is not targeted
at individual usage of IoT devices, but rather at the Enterprise and
ISP creation of networks in a zero-touch fashion, the "call-home"
represents a different kind of concern.
It needs to be re-iterated that the BRSKI-MASA mechanism only occurs It needs to be re-iterated that the BRSKI-MASA mechanism only occurs
once during the commissioning of the device. It is well defined, and once during the commissioning of the device. It is well defined, and
although encrypted with TLS, it could in theory be made auditable as although encrypted with TLS, it could in theory be made auditable as
the contents are well defined. This connection does not occur when the contents are well defined. This connection does not occur when
the device powers on or is restarted for normal routines. (It is the device powers on or is restarted for normal routines. (It is
conceivable, but remarkably unusual, that a device could be forced to conceivable, but remarkably unusual, that a device could be forced to
go through a full factory reset during an exceptional firmware update go through a full factory reset during an exceptional firmware update
situation, after which enrollment would have be repeated, and a new situation, after which enrollment would have be repeated, and a new
connection would occur) connection would occur)
skipping to change at page 100, line 7 skipping to change at page 100, line 7
To prevent unaccceptable levels of network traffic, when using mDNS, To prevent unaccceptable levels of network traffic, when using mDNS,
the congestion avoidance mechanisms specified in [RFC6762] section 7 the congestion avoidance mechanisms specified in [RFC6762] section 7
MUST be followed. The pledge SHOULD listen for an unsolicited MUST be followed. The pledge SHOULD listen for an unsolicited
broadcast response as described in [RFC6762]. This allows devices to broadcast response as described in [RFC6762]. This allows devices to
avoid announcing their presence via mDNS broadcasts and instead avoid announcing their presence via mDNS broadcasts and instead
silently join a network by watching for periodic unsolicited silently join a network by watching for periodic unsolicited
broadcast responses. broadcast responses.
Discovery of registrar MAY also be performed with DNS-based service Discovery of registrar MAY also be performed with DNS-based service
discovery by searching for the service "_brski- discovery by searching for the service "_brski-
registrar._tcp.<domain>". In this case the domain "example.com" is registrar._tcp.example.com". In this case the domain "example.com"
discovered as described in [RFC6763] section 11 (Appendix A.2 is discovered as described in [RFC6763] section 11 (Appendix A.2
suggests the use of DHCP parameters). suggests the use of DHCP parameters).
If no local proxy or registrar service is located using the GRASP If no local proxy or registrar service is located using the GRASP
mechanisms or the above mentioned DNS-based Service Discovery mechanisms or the above mentioned DNS-based Service Discovery
methods, the pledge MAY contact a well known manufacturer provided methods, the pledge MAY contact a well known manufacturer provided
bootstrapping server by performing a DNS lookup using a well known bootstrapping server by performing a DNS lookup using a well known
URI such as "brski-registrar.manufacturer.example.com". The details URI such as "brski-registrar.manufacturer.example.com". The details
of the URI are manufacturer specific. Manufacturers that leverage of the URI are manufacturer specific. Manufacturers that leverage
this method on the pledge are responsible for providing the registrar this method on the pledge are responsible for providing the registrar
service. Also see Section 2.7. service. Also see Section 2.7.
 End of changes. 16 change blocks. 
29 lines changed or deleted 24 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/