draft-ietf-anima-bootstrapping-keyinfra-39.txt   draft-ietf-anima-bootstrapping-keyinfra-40.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: 28 September 2020 Sandelman Expires: 4 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
27 March 2020 2 April 2020
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-39 draft-ietf-anima-bootstrapping-keyinfra-40
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 28 September 2020. This Internet-Draft will expire on 4 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 3, line 21 skipping to change at page 3, line 21
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 36 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 36
4.3. Proxy discovery and communication of Registrar . . . . . 36 4.3. Proxy discovery and communication of Registrar . . . . . 36
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 38 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 38
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 39 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 39
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 40 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 40
5.3. Registrar Authorization of Pledge . . . . . . . . . . . . 42 5.3. Registrar Authorization of Pledge . . . . . . . . . . . . 42
5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 43 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 43
5.4.1. MASA authentication of customer Registrar . . . . . . 43 5.4.1. MASA authentication of customer Registrar . . . . . . 43
5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 44 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 44
5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 46 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 46
5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 46 5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 47
5.5.3. MASA checking of voucher request signature . . . . . 46 5.5.3. MASA checking of voucher request signature . . . . . 47
5.5.4. MASA verification of domain registrar . . . . . . . . 47 5.5.4. MASA verification of domain registrar . . . . . . . . 48
5.5.5. MASA verification of pledge 5.5.5. MASA verification of pledge
prior-signed-voucher-request . . . . . . . . . . . . 48 prior-signed-voucher-request . . . . . . . . . . . . 49
5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 48 5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 49
5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 48 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 49
5.6.1. Pledge voucher verification . . . . . . . . . . . . . 51 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 52
5.6.2. Pledge authentication of provisional TLS 5.6.2. Pledge authentication of provisional TLS
connection . . . . . . . . . . . . . . . . . . . . . 52 connection . . . . . . . . . . . . . . . . . . . . . 53
5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 53 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 54
5.8. Registrar audit-log request . . . . . . . . . . . . . . . 54 5.8. Registrar audit-log request . . . . . . . . . . . . . . . 55
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 55 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 56
5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 58 5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 59
5.8.3. Registrar audit log verification . . . . . . . . . . 58 5.8.3. Registrar audit log verification . . . . . . . . . . 59
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 60 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 61
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 60 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 61
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 60 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 61
5.9.3. EST Client Certificate Request . . . . . . . . . . . 61 5.9.3. EST Client Certificate Request . . . . . . . . . . . 62
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 61 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 62
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 63 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 64
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 63 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 64
6. Clarification of transfer-encoding . . . . . . . . . . . . . 63 6. Clarification of transfer-encoding . . . . . . . . . . . . . 64
7. Reduced security operational modes . . . . . . . . . . . . . 63 7. Reduced security operational modes . . . . . . . . . . . . . 64
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 64 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 65
7.2. Pledge security reductions . . . . . . . . . . . . . . . 64 7.2. Pledge security reductions . . . . . . . . . . . . . . . 65
7.3. Registrar security reductions . . . . . . . . . . . . . . 65 7.3. Registrar security reductions . . . . . . . . . . . . . . 66
7.4. MASA security reductions . . . . . . . . . . . . . . . . 66 7.4. MASA security reductions . . . . . . . . . . . . . . . . 67
7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 67 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 68
7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 67 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 68
7.4.3. Updating or extending voucher trust anchors . . . . . 68 7.4.3. Updating or extending voucher trust anchors . . . . . 69
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 70
8.2. YANG Module Names Registry . . . . . . . . . . . . . . . 69 8.2. YANG Module Names Registry . . . . . . . . . . . . . . . 70
8.3. Well-known EST registration . . . . . . . . . . . . . . . 69 8.3. Well-known EST registration . . . . . . . . . . . . . . . 70
8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 70 8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 71
8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 70 8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 71
8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70 8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 71
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 71 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 72
9.1. Operational Requirements . . . . . . . . . . . . . . . . 72 9.1. Operational Requirements . . . . . . . . . . . . . . . . 73
9.1.1. MASA Operational Requirements . . . . . . . . . . . . 72 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 73
9.1.2. Domain Owner Operational Requirements . . . . . . . . 73 9.1.2. Domain Owner Operational Requirements . . . . . . . . 74
9.1.3. Device Operational Requirements . . . . . . . . . . . 74 9.1.3. Device Operational Requirements . . . . . . . . . . . 75
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 74 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 75
10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 74 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 75
10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 75 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 76
10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 76 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 77
10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 78 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 79
10.5. Manufacturers and Grey market equipment . . . . . . . . 79 10.5. Manufacturers and Grey market equipment . . . . . . . . 80
10.6. Some mitigations for meddling by manufacturers . . . . . 80 10.6. Some mitigations for meddling by manufacturers . . . . . 81
10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 81 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 82
11. Security Considerations . . . . . . . . . . . . . . . . . . . 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 82
11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 82 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 83
11.2. DomainID must be resistant to second-preimage attacks . 83 11.2. DomainID must be resistant to second-preimage attacks . 84
11.3. Availability of good random numbers . . . . . . . . . . 83 11.3. Availability of good random numbers . . . . . . . . . . 84
11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 83 11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 84
11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 84 11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 85
11.6. Manufacturer Maintenance of trust anchors . . . . . . . 85 11.6. Manufacturer Maintenance of trust anchors . . . . . . . 86
11.6.1. Compromise of Manufacturer IDevID signing keys . . . 87 11.6.1. Compromise of Manufacturer IDevID signing keys . . . 88
11.6.2. Compromise of MASA signing keys . . . . . . . . . . 87 11.6.2. Compromise of MASA signing keys . . . . . . . . . . 88
11.6.3. Compromise of MASA web service . . . . . . . . . . . 89 11.6.3. Compromise of MASA web service . . . . . . . . . . . 90
11.7. YANG Module Security Considerations . . . . . . . . . . 90 11.7. YANG Module Security Considerations . . . . . . . . . . 91
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
13.1. Normative References . . . . . . . . . . . . . . . . . . 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 91
13.2. Informative References . . . . . . . . . . . . . . . . . 94 13.2. Informative References . . . . . . . . . . . . . . . . . 95
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 98 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 99
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 98 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 99
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 98 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 99
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 98 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 99
Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 99 Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 100
C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 99 C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 100
C.1.1. Manufacturer Certificate Authority for IDevID C.1.1. Manufacturer Certificate Authority for IDevID
signatures . . . . . . . . . . . . . . . . . . . . . 100 signatures . . . . . . . . . . . . . . . . . . . . . 101
C.1.2. MASA key pair for voucher signatures . . . . . . . . 101 C.1.2. MASA key pair for voucher signatures . . . . . . . . 102
C.1.3. Registrar Certificate Authority . . . . . . . . . . . 103 C.1.3. Registrar Certificate Authority . . . . . . . . . . . 104
C.1.4. Registrar key pair . . . . . . . . . . . . . . . . . 104 C.1.4. Registrar key pair . . . . . . . . . . . . . . . . . 105
C.1.5. Pledge key pair . . . . . . . . . . . . . . . . . . . 106 C.1.5. Pledge key pair . . . . . . . . . . . . . . . . . . . 107
C.2. Example process . . . . . . . . . . . . . . . . . . . . . 107 C.2. Example process . . . . . . . . . . . . . . . . . . . . . 108
C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 107 C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 108
C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 111 C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 112
C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 117 C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 118
Appendix D. Additional References . . . . . . . . . . . . . . . 121 Appendix D. Additional References . . . . . . . . . . . . . . . 122
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122
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
Canada and parts of the US-midwest. [brewski] Canada and parts of the US-midwest. [brewski]
skipping to change at page 44, line 45 skipping to change at page 44, line 45
When a registrar receives a pledge voucher-request it in turn submits When a registrar receives a pledge voucher-request it in turn submits
a registrar voucher-request to the MASA service via an HTTPS a registrar voucher-request to the MASA service via an HTTPS
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. The entire registrar MUST sign the registrar voucher-request.
registrar certificate chain, up to and including the Domain CA, MUST
be included in the CMS structure. The voucher-request CMS object includes some number of certificates
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
'pinned-domain-cert', the MASA needs some signal as to what
certificate would be effective to populate the field with: it may
range from the End Entity (EE) Certificate that the Registrar uses,
to the entire private Enterprise CA certificate. More specific
certificates result in a tighter binding of the voucher to the
domain, while less specific certificates result in more flexibility
in how the domain is represented by certificates.
A Registrar which is seeking a nonceless voucher for later offline
use benefits from a less specific certificate, as it permits the
actual keypair used by a future Registrar to be determined by the
pinned certificate authority.
In some cases, a less specific certificate, such a public WebPKI
certificate authority, could be too open, and could permit any entity
issued a certificate by that authority to assume ownership of a
device that has a voucher pinned. Future work may provide a solution
to pin both a certificate and a name that would reduce such risk of
malicious ownership assertions.
The Registrar SHOULD request a voucher with the most specificity
consistent with the mode that it is operating in. In order to do
this, when the Registrar prepares the CMS structure for the signed
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
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,
including the Domain CA.
MASA impementations SHOULD anticipate future media types but of MASA impementations SHOULD anticipate future media types but of
course will simply fail the request if those types are not yet known. 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. Pledge's original request (see Section 5.2) but MAY be a subset. The
MASA's are expected to be flexible in what they accept. 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
request. This field provides additional information to the MASA. request. This field provides additional information to the MASA.
nonce: This value, if present, is copied from the pledge voucher- nonce: This value, if present, is copied from the pledge voucher-
request. The registrar voucher-request MAY omit the nonce as per request. The registrar voucher-request MAY omit the nonce as per
Section 3.1. Section 3.1.
skipping to change at page 46, line 36 skipping to change at page 47, line 16
renewed voucher is logged as detailed in Section 5.6. renewed voucher is logged as detailed in Section 5.6.
To inform the MASA that existing vouchers are not to be renewed one To inform the MASA that existing vouchers are not to be renewed one
can update or revoke the registrar credentials used to authorize the can update or revoke the registrar credentials used to authorize the
request (see Section 5.5.4 and Section 5.5.3). More flexible methods request (see Section 5.5.4 and Section 5.5.3). More flexible methods
will likely involve sales channel integration and authorizations will likely involve sales channel integration and authorizations
(details are out-of-scope of this document). (details are out-of-scope of this document).
5.5.2. MASA pinning of registrar 5.5.2. MASA pinning of registrar
The registrar's certificate chain is extracted from the signature A certificate chain is extracted from the Registrar's signed CMS
method. The entire registrar certificate chain was included in the container. This chain may be as short as a single End-Entity
CMS structure, as specified in Section 5.5. This CA certificate will Certificate, up to the entire registrar certificate chain, including
be used to populate the "pinned-domain-cert" of the voucher being the Domain CA certificate, as specified in Section 5.5.
issued.
If this domain CA is unknown to the MASA, then it is to be considered If the domain's CA is unknown to the MASA, then it is to be
a temporary trust anchor for the rest of the steps in this section. considered a temporary trust anchor for the rest of the steps in this
The intention is not to authenticate the message as having come from section. The intention is not to authenticate the message as having
a fully validated origin, but to establish the consistency of the come from a fully validated origin, but to establish the consistency
domain PKI. of the domain PKI.
The MASA MAY use the highest certificate from the certificate chain
that it received from the Registrar, as determined by MASA policy. A
MASA MAY have a local policy that it only pins the End-Entity
certificate. This is consistent with [RFC8366]. Details of the
policy will typically depend upon the degree of Supply Chain
Integration, and the mechanism used by the Registrar to authenticate.
Such a policy would also determine how a the MASA will respond to a
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.
Normal PKIX revocation checking is assumed during voucher-request Normal PKIX revocation checking is assumed during voucher-request
signature validation. This CA certificate MAY have Certificate signature validation. This CA certificate MAY have Certificate
Revocation List distribution points, or Online Certificate Status Revocation List distribution points, or Online Certificate Status
skipping to change at page 47, line 29 skipping to change at page 48, line 20
section 3.6.1) exists in the certificate of the entity that signed section 3.6.1) exists in the certificate of the entity that signed
the registrar voucher-request. This verification is only a the registrar voucher-request. This verification is only a
consistency check that the unauthenticated domain CA intended the consistency check that the unauthenticated domain CA intended the
voucher-request signer to be a registrar. Performing this check voucher-request signer to be a registrar. Performing this check
provides value to the domain PKI by assuring the domain administrator provides value to the domain PKI by assuring the domain administrator
that the MASA service will only respect claims from authorized that the MASA service will only respect claims from authorized
Registration Authorities of the domain. Registration Authorities of the domain.
Even when a domain CA is authenticated to the MASA, and there is Even when a domain CA is authenticated to the MASA, and there is
strong sales channel integration to understand who the legitimate strong sales channel integration to understand who the legitimate
owner is, the above cmcRC check prevents arbitrary End-Entity owner is, the above id-kp-cmcRA check prevents arbitrary End-Entity
certificates (such as an LDevID certificate) from having vouchers certificates (such as an LDevID certificate) from having vouchers
issued against them. issued against them.
Other cases of inappropriate voucher issuance are detected by Other cases of inappropriate voucher issuance are detected by
examination of the audit log. examination of the audit log.
If a nonceless voucher-request is submitted the MASA MUST If a nonceless voucher-request is submitted the MASA MUST
authenticate the registrar as described in either EST [RFC7030] authenticate the registrar as described in either EST [RFC7030]
section 3.2.3, section 3.3.2, or by validating the registrar's section 3.2.3, section 3.3.2, or by validating the registrar's
certificate used to sign the registrar voucher-request using a certificate used to sign the registrar voucher-request using a
skipping to change at page 50, line 38 skipping to change at page 51, line 38
Figure 14: An example voucher Figure 14: An example voucher
The MASA populates the voucher fields as follows: The MASA populates the voucher fields as follows:
nonce: The nonce from the pledge if available. See Section 5.5.6. nonce: The nonce from the pledge if available. See Section 5.5.6.
assertion: The method used to verify the relationship between pledge assertion: The method used to verify the relationship between pledge
and registrar. See Section 5.5.5. and registrar. See Section 5.5.5.
pinned-domain-cert: The domain CA cert. See Section 5.5.2. This pinned-domain-cert: A certificate. See Section 5.5.2. This figure
figure is illustrative, for an example, see Appendix C.2 is illustrative, for an example, see Appendix C.2 where an End
Entity certificate is used.
serial-number: The serial-number as provided in the voucher-request. serial-number: The serial-number as provided in the voucher-request.
Also see Section 5.5.5. Also see Section 5.5.5.
domain-cert-revocation-checks: Set as appropriate for the pledge's domain-cert-revocation-checks: Set as appropriate for the pledge's
capabilities and as documented in [RFC8366]. The MASA MAY set capabilities and as documented in [RFC8366]. The MASA MAY set
this field to 'false' since setting it to 'true' would require this field to 'false' since setting it to 'true' would require
that revocation information be available to the pledge and this that revocation information be available to the pledge and this
document does not make normative requirements for [RFC6961] or document does not make normative requirements for [RFC6961] or
equivalent integrations. equivalent integrations.
skipping to change at page 52, line 7 skipping to change at page 53, line 7
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
The 'pinned-domain-cert' element of the voucher contains the domain Following the process described in [RFC8366], the pledge should
CA's public key. The pledge MUST use the 'pinned-domain-cert' trust consider the public key from the pinned-domain-cert as the sole
anchor to immediately complete authentication of the provisional TLS temporary trust anchor.
connection.
The pledge then evaluates the TLS Server Certificate chain that it
received when the TLS connection was formed using this trust anchor.
It is possible that the pinned-domain-cert matches the End-Entity
Certificate provided in the TLS Server.
If a registrar's credentials cannot be verified using the pinned- If a registrar's credentials cannot be verified using the pinned-
domain-cert trust anchor from the voucher then the TLS connection is domain-cert trust anchor from the voucher then the TLS connection is
immediately discarded and the pledge abandons attempts to bootstrap immediately discarded and the pledge abandons attempts to bootstrap
with this discovered registrar. The pledge SHOULD send voucher with this discovered registrar. The pledge SHOULD send voucher
status telemetry (described below) before closing the TLS connection. status telemetry (described below) before closing the TLS connection.
The pledge MUST attempt to enroll using any other proxies it has The pledge MUST attempt to enroll using any other proxies it has
found. It SHOULD return to the same proxy again after unsuccessful found. It SHOULD return to the same proxy again after unsuccessful
attempts with other proxies. Attempts should be made repeated at attempts with other proxies. Attempts should be made repeated at
intervals according to the backoff timer described earlier. Attempts intervals according to the backoff timer described earlier. Attempts
skipping to change at page 106, line 17 skipping to change at page 107, line 17
The pledge has an IDevID key pair built in at manufacturing time: The pledge has an IDevID key pair built in at manufacturing time:
<CODE BEGINS> file "idevid_00-D0-E5-F2-00-02.key" <CODE BEGINS> file "idevid_00-D0-E5-F2-00-02.key"
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBHNh6r8QRevRuo+tEmBJeFjQKf6bpFA/9NGoltv+9sNoAoGCCqGSM49 MHcCAQEEIBHNh6r8QRevRuo+tEmBJeFjQKf6bpFA/9NGoltv+9sNoAoGCCqGSM49
AwEHoUQDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLx AwEHoUQDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLx
FjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJw== FjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJw==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
<CODE ENDS> <CODE ENDS>
The public key is used by the registrar to find the MASA. The certificate is used by the registrar to find the MASA.
<CODE BEGINS> file "idevid_00-D0-E5-F2-00-02.cert" <CODE BEGINS> file "idevid_00-D0-E5-F2-00-02.cert"
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 226876461 (0xd85dc2d) Serial Number: 226876461 (0xd85dc2d)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA
Validity Validity
Not Before: Feb 3 06:47:20 2020 GMT Not Before: Feb 3 06:47:20 2020 GMT
skipping to change at page 107, line 29 skipping to change at page 108, line 29
-----END CERTIFICATE----- -----END CERTIFICATE-----
<CODE ENDS> <CODE ENDS>
C.2. Example process C.2. Example process
The JSON examples below are wrapped at 60 columns. This results in The JSON examples below are wrapped at 60 columns. This results in
strings that have newlines in them, which makes them invalid JSON as strings that have newlines in them, which makes them invalid JSON as
is. The strings would otherwise be too long, so they need to be is. The strings would otherwise be too long, so they need to be
unwrapped before processing. unwrapped before processing.
For readability, the output of the asn1parse has been truncated at 72
columns rather than wrapped.
C.2.1. Pledge to Registrar C.2.1. Pledge to Registrar
As described in Section 5.2, the pledge will sign a pledge voucher- As described in Section 5.2, the pledge will sign a pledge voucher-
request containing the registrar's public key in the proximity- request containing the registrar's public key in the proximity-
registrar-cert field. The base64 has been wrapped at 60 characters registrar-cert field. The base64 has been wrapped at 60 characters
for presentation reasons. for presentation reasons.
<CODE BEGINS> file "vr_00-D0-E5-F2-00-02.b64" <CODE BEGINS> file "vr_00-D0-E5-F2-00-02.b64"
MIIG3wYJKoZIhvcNAQcCoIIG0DCCBswCAQExDTALBglghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGg MIIG3wYJKoZIhvcNAQcCoIIG0DCCBswCAQExDTALBglghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGg
ggN6BIIDdnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94 ggN6BIIDdnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94
skipping to change at page 121, line 35 skipping to change at page 122, line 35
Michael C. Richardson Michael C. Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/ URI: http://www.sandelman.ca/
Toerless Eckert Toerless Eckert
Futurewei Technologies Inc. USA Futurewei Technologies Inc. USA
2330 Central Expy 2330 Central Expy
Santa Clara, 95050 Santa Clara, CA 95050
United States of America United States of America
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de
Michael H. Behringer Michael H. Behringer
Email: Michael.H.Behringer@gmail.com Email: Michael.H.Behringer@gmail.com
Kent Watsen Kent Watsen
Watsen Networks Watsen Networks
 End of changes. 19 change blocks. 
109 lines changed or deleted 155 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/