draft-ietf-anima-bootstrapping-keyinfra-14.txt   draft-ietf-anima-bootstrapping-keyinfra-15.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: October 15, 2018 Sandelman Expires: October 28, 2018 Sandelman
M. Behringer M. Behringer
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
K. Watsen K. Watsen
Juniper Networks Juniper Networks
April 13, 2018 April 26, 2018
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-14 draft-ietf-anima-bootstrapping-keyinfra-15
Abstract Abstract
This document specifies automated bootstrapping of a remote secure This document specifies automated bootstrapping of a remote secure
key infrastructure (BRSKI) using manufacturer installed X.509 key infrastructure (BRSKI) using manufacturer installed X.509
certificate, in combination with a manufacturer's authorizing certificate, in combination with a manufacturer's authorizing
service, both online and offline. Bootstrapping a new device can service, both online and offline. Bootstrapping a new device can
occur using a routable address and a cloud service, or using only occur using a routable address and a cloud service, or using only
link-local connectivity, or on limited/disconnected networks. link-local connectivity, or on limited/disconnected networks.
Support for lower security models, including devices with minimal Support for lower security models, including devices with minimal
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 October 15, 2018. This Internet-Draft will expire on October 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 21 skipping to change at page 3, line 21
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 37 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 37
5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 38 5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 38
5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 39 5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 39
5.4.1. MASA renewal of expired vouchers . . . . . . . . . . 40 5.4.1. MASA renewal of expired vouchers . . . . . . . . . . 40
5.4.2. MASA verification of voucher-request signature 5.4.2. MASA verification of voucher-request signature
consistency . . . . . . . . . . . . . . . . . . . . . 40 consistency . . . . . . . . . . . . . . . . . . . . . 40
5.4.3. MASA authentication of registrar (certificate) . . . 41 5.4.3. MASA authentication of registrar (certificate) . . . 41
5.4.4. MASA revocation checking of registrar (certificate) . 41 5.4.4. MASA revocation checking of registrar (certificate) . 41
5.4.5. MASA verification of pledge prior-signed-voucher- 5.4.5. MASA verification of pledge prior-signed-voucher-
request . . . . . . . . . . . . . . . . . . . . . . . 42 request . . . . . . . . . . . . . . . . . . . . . . . 41
5.4.6. MASA pinning of registrar . . . . . . . . . . . . . . 42 5.4.6. MASA pinning of registrar . . . . . . . . . . . . . . 41
5.4.7. MASA nonce handling . . . . . . . . . . . . . . . . . 42 5.4.7. MASA nonce handling . . . . . . . . . . . . . . . . . 42
5.5. MASA Voucher Response . . . . . . . . . . . . . . . . . . 42 5.5. MASA and Registrar Voucher Response . . . . . . . . . . . 42
5.5.1. Pledge voucher verification . . . . . . . . . . . . . 44 5.5.1. Pledge voucher verification . . . . . . . . . . . . . 44
5.5.2. Pledge authentication of provisional TLS connection . 44 5.5.2. Pledge authentication of provisional TLS connection . 45
5.6. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 45 5.6. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 46
5.7. Registrar audit log request . . . . . . . . . . . . . . . 46 5.7. Registrar audit log request . . . . . . . . . . . . . . . 46
5.7.1. MASA audit log response . . . . . . . . . . . . . . . 47 5.7.1. MASA audit log response . . . . . . . . . . . . . . . 48
5.7.2. Registrar audit log verification . . . . . . . . . . 49 5.7.2. Registrar audit log verification . . . . . . . . . . 49
5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 50 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 50
5.8.1. EST Distribution of CA Certificates . . . . . . . . . 50 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 51
5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51
5.8.3. EST Client Certificate Request . . . . . . . . . . . 52 5.8.3. EST Client Certificate Request . . . . . . . . . . . 52
5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52
5.8.5. Multiple certificates . . . . . . . . . . . . . . . . 53 5.8.5. Multiple certificates . . . . . . . . . . . . . . . . 53
5.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53 5.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53
6. Reduced security operational modes . . . . . . . . . . . . . 53 6. Reduced security operational modes . . . . . . . . . . . . . 53
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 53 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 54
6.2. Pledge security reductions . . . . . . . . . . . . . . . 54 6.2. Pledge security reductions . . . . . . . . . . . . . . . 54
6.3. Registrar security reductions . . . . . . . . . . . . . . 55 6.3. Registrar security reductions . . . . . . . . . . . . . . 55
6.4. MASA security reductions . . . . . . . . . . . . . . . . 56 6.4. MASA security reductions . . . . . . . . . . . . . . . . 56
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
7.1. Well-known EST registration . . . . . . . . . . . . . . . 56 7.1. Well-known EST registration . . . . . . . . . . . . . . . 57
7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 57 7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 57
7.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 57 7.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 57
7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 57 7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 58
7.5. MUD File Extension for the MASA server . . . . . . . . . 58 7.5. MUD File Extension for the MASA server . . . . . . . . . 58
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 58 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 58
8.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 58 8.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 58
9. Security Considerations . . . . . . . . . . . . . . . . . . . 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 59
9.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 60 9.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 60
9.2. Trusting manufacturers . . . . . . . . . . . . . . . . . 61 9.2. Trusting manufacturers . . . . . . . . . . . . . . . . . 61
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 62
11.1. Normative References . . . . . . . . . . . . . . . . . . 62 11.1. Normative References . . . . . . . . . . . . . . . . . . 62
11.2. Informative References . . . . . . . . . . . . . . . . . 65 11.2. Informative References . . . . . . . . . . . . . . . . . 65
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 67 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 67
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 67 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 67
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 67 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 67
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 67 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 68
Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 68 Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 68
C.1. Multiple Join networks on the Join Proxy side . . . . . . 69 C.1. Multiple Join networks on the Join Proxy side . . . . . . 69
C.2. Automatic configuration of tunnels on Registrar . . . . . 69 C.2. Automatic configuration of tunnels on Registrar . . . . . 70
C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 69 C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 70
C.4. Use of connected sockets; or IP_PKTINFO for CoAP on C.4. Use of connected sockets; or IP_PKTINFO for CoAP on
Registrar . . . . . . . . . . . . . . . . . . . . . . . . 70 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 70
C.5. Use of socket extension rather than virtual interface . . 70 C.5. Use of socket extension rather than virtual interface . . 71
Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 71 Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 71
Appendix E. Example Vouchers . . . . . . . . . . . . . . . . . . 73 Appendix E. Example Vouchers . . . . . . . . . . . . . . . . . . 73
E.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 73 E.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 73
E.1.1. MASA key pair for voucher signatures . . . . . . . . 73 E.1.1. MASA key pair for voucher signatures . . . . . . . . 73
E.1.2. Manufacturer key pair for IDevID signatures . . . . . 73 E.1.2. Manufacturer key pair for IDevID signatures . . . . . 73
E.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 74 E.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 74
E.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 76 E.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 76
E.2. Example process . . . . . . . . . . . . . . . . . . . . . 77 E.2. Example process . . . . . . . . . . . . . . . . . . . . . 78
E.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 77 E.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 78
E.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 83 E.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 84
E.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 89 E.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
1. Introduction 1. Introduction
BRSKI provides a solution for secure zero-touch (automated) bootstrap BRSKI provides a solution for secure zero-touch (automated) bootstrap
of virgin (untouched) devices that are called pledges in this of virgin (untouched) devices that are called pledges in this
document. These pledges need to discover (or be discovered by) an document. These pledges need to discover (or be discovered by) an
element of the network domain to which the pledge belongs to perform element of the network domain to which the pledge belongs to perform
the bootstrap. This element (device) is called the registrar. the bootstrap. This element (device) is called the registrar.
skipping to change at page 26, line 8 skipping to change at page 26, line 8
} }
} }
Example (2) The following example illustrates a registrar voucher- Example (2) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is request. The 'prior-signed-voucher-request' leaf is
populated with the pledge's voucher-request (such as the populated with the pledge's voucher-request (such as the
prior example). The pledge's voucher-request, if a prior example). The pledge's voucher-request, if a
signed artifact with a CMS format signature is a binary signed artifact with a CMS format signature is a binary
object. In the JSON encoding used here it must be object. In the JSON encoding used here it must be
base64 encoded. The nonce, created-on and assertion is base64 encoded. The nonce, created-on and assertion is
carried forward. serial-number is extracted from the carried forward. The serial-number is extracted from
pledge's Client Certificate from the TLS connection. the pledge's Client Certificate from the TLS connection.
See Section 5.4. See Section 5.4.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"assertion": "proximity", "assertion": "proximity",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
"prior-signed-voucher": "base64encodedvalue==" "prior-signed-voucher": "base64encodedvalue=="
skipping to change at page 40, line 28 skipping to change at page 40, line 28
The MASA verifies that the registrar voucher-request is internally The MASA verifies that the registrar voucher-request is internally
consistent but does not necessarily authenticate the registrar consistent but does not necessarily authenticate the registrar
certificate since the registrar is not known to the MASA server in certificate since the registrar is not known to the MASA server in
advance. The MASA performs the actions and validation checks advance. The MASA performs the actions and validation checks
described in the following sub-sections before issuing a voucher. described in the following sub-sections before issuing a voucher.
5.4.1. MASA renewal of expired vouchers 5.4.1. MASA renewal of expired vouchers
As described in [I-D.ietf-anima-voucher] vouchers are normally short As described in [I-D.ietf-anima-voucher] vouchers are normally short
lived to avoid revocation issues. If the request is for a previous lived to avoid revocation issues. If the request is for a previous
(expired) voucher using the same registrar (as determined by the (expired) voucher using the same registrar then the request for a
registrar pinned-domain-cert) and the MASA has not been informed that renewed voucher SHOULD be automatically authorized. The MASA has
the claim is invalid then the request for a renewed voucher SHOULD be sufficient information to determine this by examining the request,
automatically authorized. the registrar authentication, and the existing audit log. The
issuance of a renewed voucher is logged as detailed in Section 5.5.
To inform the MASA that existing vouchers are not to be renewed one
can update or revoke the registrar credentials used to authorize the
request (see Section 5.4.3 and Section 5.4.4). More flexible methods
will likely involve sales channel integration and authorizations
(details are out-of-scope of this document).
5.4.2. MASA verification of voucher-request signature consistency 5.4.2. MASA verification of voucher-request signature consistency
The MASA MUST verify that the registrar voucher-request is signed by The MASA MUST verify that the registrar voucher-request is signed by
a registrar. This is confirmed by verifying that the id-kp-cmcRA a registrar. This is confirmed by verifying that the id-kp-cmcRA
extended key usage extension field (as detailed in EST RFC7030 extended key usage extension field (as detailed in EST RFC7030
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
skipping to change at page 41, line 13 skipping to change at page 41, line 16
CMS structure as detailed in Section 5.4. CMS structure as detailed in Section 5.4.
5.4.3. MASA authentication of registrar (certificate) 5.4.3. MASA authentication of registrar (certificate)
If a nonceless voucher-request is submitted the MASA server MUST If a nonceless voucher-request is submitted the MASA server MUST
authenticate the registrar as described in either EST [RFC7030] authenticate the registrar as described in either EST [RFC7030]
section 3.2, section 3.3, or by validating the registrar's section 3.2, section 3.3, or by validating the registrar's
certificate used to sign the registrar voucher-request. Any of these certificate used to sign the registrar voucher-request. Any of these
methods reduce the risk of DDoS attacks and provide an authenticated methods reduce the risk of DDoS attacks and provide an authenticated
identity as an input to sales channel integration and authorizations identity as an input to sales channel integration and authorizations
(the actual sale-channel integration is also out-of-scope of this (details are out-of-scope of this document).
document).
In the nonced case, validation of the registrar MAY be omitted if the In the nonced case, validation of the registrar MAY be omitted if the
device policy is to accept audit-only vouchers. device policy is to accept audit-only vouchers.
5.4.4. MASA revocation checking of registrar (certificate) 5.4.4. MASA revocation checking of registrar (certificate)
Note that this section is about ensuring consistency of the As noted in Section 5.4.3 the MASA performs registrar authentication
registrar. These checks are not equivalent to [RFC5280] Certificate in a subset of situations (e.g. nonceless voucher requests). Normal
Revocation Checks that the pledge would ideally do if it had a real PKIX revocation checking is assumed during either EST client
time clock. authentication or voucher-request signature validation. Similarly,
as noted in Section 5.4.2, the MASA performs normal PKIX revocation
If the registrar uses a CA for which the MASA is able to obtain checking during signature consistency checks (a signature by a
revocation information, then the MASA SHOULD check for the maximum registrar certificate that has been revoked is an inconsistency).
validity period of the registrar's certificate.
A registrar which has done these checks may set the "domain-cert-
revocation-checks" attribute in the voucher to false (or omit it).
There are three times to consider: a) a configured voucher lifetime
in the MASA, b) the expiry time for the registrar's certificate, c)
any certificate revocation information (CRL) lifetime.
The resulting voucher should have a lifetime (expires-on field) which
is the earliest of these three values. Typically (b) will be some
significant time in the future, but (c) will typically be short (on
the order of a week or less). The RECOMMENDED period for (a) is on
the order of 20 minutes, so it will typically determine the lifespan
of the resulting voucher.
By limiting the voucher lifetime in this way, the MASA is ensuring
the voucher is consistent with any CRL and lifetime checks. See
section Section 2.6.1.
If CRL information is unavailable to the MASA, then the MASA SHOULD
rely on the validity information Because the registrar certificate
authority is unknown to the MASA in advance this is only an extended
consistency check and is not required. The maximum lifetime of the
voucher issued SHOULD NOT exceed the lifetime of the registrar's
revocation validation (for example if the registrar revocation status
is indicated in a CRL that is valid for two weeks then that is an
appropriate lifetime for the voucher.)
5.4.5. MASA verification of pledge prior-signed-voucher-request 5.4.5. MASA verification of pledge prior-signed-voucher-request
The MASA server MAY verify that the registrar voucher-request The MASA server MAY verify that the registrar voucher-request
includes the 'prior-signed-voucher-request' field populated with a includes the 'prior-signed-voucher-request' field. If so the prior-
signed pledge voucher-request that includes a 'proximity-registrar- signed-voucher-request MUST include a 'proximity-registrar-cert' that
cert' that is consistent with the certificate used to sign the is consistent with the certificate used to sign the registrar
registrar voucher-request. This ensures that the BRSKI-EST TLS voucher-request. Additionally the voucher-request serial-number leaf
connection has no man-in-the-middle. The MASA server is aware of MUST match the pledge serial-number that the MASA extracts from the
which pledges support signing of their voucher requests and can use signing certificate of the prior-signed-voucher-request. The MASA
this information to confirm proximity of the pledge with the server is aware of which pledges support signing of their voucher
registrar. requests and can use this information to confirm proximity of the
pledge with the registrar, thus ensuring that the BRSKI-EST TLS
connection has no man-in-the-middle.
If this check succeeds the MASA updates the voucher and audit log If these checks succeed the MASA updates the voucher and audit log
assertion leafs with the "proximity" assertion. assertion leafs with the "proximity" assertion.
5.4.6. MASA pinning of registrar 5.4.6. MASA pinning of registrar
The registrar's certificate chain is extracted from the signature The registrar's certificate chain is extracted from the signature
method. The chain includes the domain CA certificate as specified in method. The chain includes the domain CA certificate as specified in
Section 5.4. This certificate is used to populate the "pinned- Section 5.4. This certificate is used to populate the "pinned-
domain-cert" of the voucher being issued. The domainID (e.g., hash domain-cert" of the voucher being issued. The domainID (e.g., hash
of the root public key) is determined from the pinned-domain-cert and of the root public key) is determined from the pinned-domain-cert and
is used to update the audit log. is used to update the audit log.
skipping to change at page 42, line 44 skipping to change at page 42, line 20
The MASA does not verify the nonce itself. It MAY perform a simple The MASA does not verify the nonce itself. It MAY perform a simple
consistency check: If the registrar voucher-request contains a nonce consistency check: If the registrar voucher-request contains a nonce
and the prior-signed-voucher-request exists then the nonce in both and the prior-signed-voucher-request exists then the nonce in both
MUST be consistent. (Recall from above that the voucher-request MUST be consistent. (Recall from above that the voucher-request
might not contain a nonce, see Section 5.4 and Section 5.4.3). might not contain a nonce, see Section 5.4 and Section 5.4.3).
The MASA MUST use the nonce from the registrar voucher-request for The MASA MUST use the nonce from the registrar voucher-request for
the resulting voucher and audit log. The prior-signed-voucher- the resulting voucher and audit log. The prior-signed-voucher-
request nonce is ignored during this operation. request nonce is ignored during this operation.
5.5. MASA Voucher Response 5.5. MASA and Registrar Voucher Response
The voucher response to requests from the pledge and requests from a The MASA voucher response to the registrar is forwarded without
registrar are in the same format. A registrar either caches prior changes to the pledge; therefore this section applies to both the
MASA and the registrar. The HTTP signaling described applies to both
the MASA and registrar responses. A registrar either caches prior
MASA responses or dynamically requests a new voucher based on local MASA responses or dynamically requests a new voucher based on local
policy. policy (it does not generate or sign a voucher).
If the join operation is successful, the server (MASA responding to If the voucher-request is successful, the server (MASA responding to
registrar, and registrar responding to pledge) response MUST contain registrar or registrar responding to pledge) response MUST contain an
an HTTP 200 response code. The server MUST answer with a suitable HTTP 200 response code. The server MUST answer with a suitable 4xx
4xx or 5xx HTTP [RFC2616] error code when a problem occurs. In this or 5xx HTTP [RFC2616] error code when a problem occurs. In this
case, the response data from the MASA server MUST be a plaintext case, the response data from the MASA server MUST be a plaintext
human-readable (ASCII, English) error message containing explanatory human-readable (ASCII, English) error message containing explanatory
information describing why the request was rejected. information describing why the request was rejected.
The registrar MAY respond with an HTTP 202 ("the request has been The registrar MAY respond with an HTTP 202 ("the request has been
accepted for processing, but the processing has not been completed") accepted for processing, but the processing has not been completed")
as described in EST [RFC7030] section 4.2.3 wherein the client "MUST as described in EST [RFC7030] section 4.2.3 wherein the client "MUST
wait at least the specified 'Retry-After' time before repeating the wait at least the specified 'Retry-After' time before repeating the
same request". (see [RFC7231] section 6.6.4) The pledge is same request". (see [RFC7231] section 6.6.4) The pledge is
RECOMMENDED to provide local feedback (blinked LED etc) during this RECOMMENDED to provide local feedback (blinked LED etc) during this
skipping to change at page 43, line 44 skipping to change at page 43, line 20
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.
A 406 (Not Acceptable) response is appropriate if a voucher of the A 406 (Not Acceptable) response is appropriate if a voucher of the
desired type, or using the desired algorithms (as indicated by the desired type or using the desired algorithms (as indicated by the
Accept: headers, and algorithms used in the signature) cannot be Accept: headers, and algorithms used in the signature) cannot be
issued, such as because the MASA knows the pledge cannot process that issued such as because the MASA knows the pledge cannot process that
type. type. The registrar SHOULD use this response if it determines the
pledge is unacceptable due to inventory control, MASA audit logs, or
any other reason.
A 415 (Unsupported Media Type) response is approriate for a request A 415 (Unsupported Media Type) response is approriate for a request
that has a voucher encoding that is not understood. that has a voucher encoding that is not understood.
The response media type is: The response media type is:
application/voucher-cms+json The response is a "YANG-defined JSON application/voucher-cms+json The response is a "YANG-defined JSON
document that has been signed using a CMS structure" as described document that has been signed using a CMS structure" as described
in [I-D.ietf-anima-voucher] using the JSON encoded described in in [I-D.ietf-anima-voucher] using the JSON encoded described in
[RFC7951]. The MASA MUST sign the request. [RFC7951]. The MASA MUST sign the response.
The syntactic details of vouchers are described in detail in The syntactic details of vouchers are described in detail in
[I-D.ietf-anima-voucher]. For example, the voucher consists of: [I-D.ietf-anima-voucher]. For example, the voucher consists of:
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"assertion": "logging" "assertion": "logging"
"pinned-domain-cert": "base64encodedvalue==" "pinned-domain-cert": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
The MASA populates the voucher fields as follows:
nonce: The nonce from the pledge if available. See Section 5.4.7.
assertion: The method used to verify assertion. See Section 5.4.5.
pinned-domain-cert: The domain CA cert. See Section 5.4.6.
serial-number: The serial-number as provided in the voucher-request.
Also see Section 5.4.5.
domain-cert-revocation-checks: Set as appropriate for the pledge's
capabilities and as documented in [I-D.ietf-anima-voucher]. The
MASA MAY set this field to 'false' since setting it to 'true'
would require that revocation information be available to the
pledge and this document does not make normative requirements for
[RFC6961] or equivalent integrations.
expires-on: This is set for nonceless vouchers. The MASA ensures
the voucher lifetime is consistent with any revocation or pinned-
domain-cert consistency checks the pledge might perform. See
section Section 2.6.1. There are three times to consider: (a) a
configured voucher lifetime in the MASA, (b) the expiry time for
the registrar's certificate, (c) any certificate revocation
information (CRL) lifetime. The expires-on field SHOULD be before
the earliest of these three values. Typically (b) will be some
significant time in the future, but (c) will typically be short
(on the order of a week or less). The RECOMMENDED period for (a)
is on the order of 20 minutes, so it will typically determine the
lifespan of the resulting voucher.
Whenever a voucher is issued the MASA MUST update the audit log
appropriately. The internal state requirements to maintain the audit
log are out-of-scope. See Section 5.7.1 for a discussion of
reporting the log to a registrar.
5.5.1. Pledge voucher verification 5.5.1. Pledge voucher verification
The pledge MUST verify the voucher signature using the manufacturer The pledge MUST verify the voucher signature using the manufacturer
installed trust anchor associated with the manufacturer's MASA (this installed trust anchor associated with the manufacturer's MASA (this
is likely included in the pledge's firmware). is likely included in the pledge's firmware).
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 that the voucher nonce field is accurate and The pledge MUST verify that the voucher nonce field is accurate and
skipping to change at page 48, line 5 skipping to change at page 48, line 11
registrar MUST sign the request. The entire registrar certificate registrar MUST sign the request. The entire registrar certificate
chain, up to and including the Domain CA, MUST be included in the chain, up to and including the Domain CA, MUST be included in the
CMS structure. CMS structure.
5.7.1. MASA audit log response 5.7.1. MASA audit log response
A log data file is returned consisting of all log entries. The A log data file is returned consisting of all log entries. The
returned data is in JSON format ([RFC7951]), and the Content-Type returned data is in JSON format ([RFC7951]), and the Content-Type
SHOULD be "application/json". For example: SHOULD be "application/json". For example:
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"<date/time of the entry>", "date":"<date/time of the entry>",
"domainID":"<domainID extracted from voucher-request>", "domainID":"<domainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or the exact string 'NULL')>" "nonce":"<any nonce if supplied (or the exact string 'NULL')>"
"assertion":"<the value that was placed in the voucher assertion leaf>" "assertion":"<the value from the voucher assertion leaf>"
}, },
{ {
"date":"<date/time of the entry>", "date":"<date/time of the entry>",
"domainID":"<anotherDomainID extracted from voucher-request>", "domainID":"<anotherDomainID extracted from voucher-request>",
"nonce":"<any nonce if supplied (or the exact string 'NULL')>" "nonce":"<any nonce if supplied (or the exact string 'NULL')>"
"assertion":"<the value that was placed in the voucher assertion leaf>" "assertion":"<the value from the voucher assertion leaf>"
} }
], ],
"truncation": { "truncation": {
"nonced duplicates": <number of entries truncated>, "nonced duplicates": <number of entries truncated>,
"nonceless duplicates": <number of entries truncated>, "nonceless duplicates": <number of entries truncated>,
"arbitrary": <number of entries trucated> "arbitrary": <number of entries trucated>
} }
} }
Distribution of a large log is less than ideal. This structure can Distribution of a large log is less than ideal. This structure can
be optimized as follows: Nonced or Nonceless entries for the same be optimized as follows: Nonced or Nonceless entries for the same
domainID MAY be truncated from the log leaving only the single most domainID MAY be truncated from the log leaving only the single most
recent nonced or nonceless entry. The log SHOULD NOT be further recent nonced or nonceless entry. The log SHOULD NOT be further
reduced but there could exist operational situation where maintaining reduced but there could exist operational situation where maintaining
the full log is not possible. In such situations the log MAY be the full log is not possible. In such situations the log MAY be
arbitrarily truncated for length. The trunctation method(s) used arbitrarily truncated for length. The trunctation method(s) used
MUST be indicated in the JSON truncation dictionary using "nonced MUST be indicated in the JSON truncation dictionary using "nonced
duplicates", "nonceless duplicates", and "arbitrary" where the number duplicates", "nonceless duplicates", and "arbitrary" where the number
skipping to change at page 50, line 16 skipping to change at page 50, line 23
registrar's that expected only new (not pre-owned) pledges. A registrar's that expected only new (not pre-owned) pledges. A
"logged" assertion informs the registrar that the prior vouchers "logged" assertion informs the registrar that the prior vouchers
were issued with minimal verification. A "proximity" assertion were issued with minimal verification. A "proximity" assertion
assures the registrar that the pledge was truly communicating with assures the registrar that the pledge was truly communicating with
the prior domain and thus provides assurance that the prior domain the prior domain and thus provides assurance that the prior domain
really has deployed the pledge. really has deployed the pledge.
A relatively simple policy is to white list known (internal or A relatively simple policy is to white list known (internal or
external) domainIDs and to require all vouchers to have a nonce and/ external) domainIDs and to require all vouchers to have a nonce and/
or require that all nonceless vouchers be from a subset (e.g. only or require that all nonceless vouchers be from a subset (e.g. only
internal) domainIDs. A registrar MAY be configured to ignore the internal) domainIDs. A simple action is to revoke any locally issued
history of the device but it is RECOMMENDED that this only be credentials for the pledge in question or to refuse to forward the
configured if hardware assisted NEA [RFC5209] is supported. voucher. A registrar MAY be configured to ignore the history of the
device but it is RECOMMENDED that this only be configured if hardware
assisted NEA [RFC5209] is supported.
5.8. EST Integration for PKI bootstrapping 5.8. EST Integration for PKI bootstrapping
The pledge SHOULD follow the BRSKI operations with EST enrollment The pledge SHOULD follow the BRSKI operations with EST enrollment
operations including "CA Certificates Request", "CSR Attributes" and operations including "CA Certificates Request", "CSR Attributes" and
"Client Certificate Request" or "Server-Side Key Generation", etc. "Client Certificate Request" or "Server-Side Key Generation", etc.
This is a relatively seamless integration since BRSKI REST calls This is a relatively seamless integration since BRSKI REST calls
provide an automated alternative to the manual bootstrapping method provide an automated alternative to the manual bootstrapping method
described in [RFC7030]. As noted above, use of HTTP 1.1 persistent described in [RFC7030]. As noted above, use of HTTP 1.1 persistent
connections simplifies the pledge state machine. connections simplifies the pledge state machine.
skipping to change at page 57, line 38 skipping to change at page 58, line 9
o Status o Status
o Reason o Reason
o reason-context o reason-context
7.4. DNS Service Names 7.4. DNS Service Names
IANA is requested to register the following Service Names: IANA is requested to register the following Service Names:
Service Name: _brski-proxy Service Name: _brski-proxy
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>. Assignee: IESG <iesg@ietf.org>.
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Description: The Bootstrapping Remote Secure Key Infrastructures Proxy Description: The Bootstrapping Remote Secure Key
Reference: [This document] Infrastructures Proxy
Reference: [This document]
Service Name: _brski-registrar
Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>.
Contact: IETF Chair <chair@ietf.org>
Description: The Bootstrapping Remote Secure Key
Infrastructures Registrar
Reference: [This document]
Service Name: _brski-registrar
Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>.
Contact: IETF Chair <chair@ietf.org>
Description: The Bootstrapping Remote Secure Key Infrastructures Registrar
Reference: [This document]
7.5. MUD File Extension for the MASA server 7.5. MUD File Extension for the MASA server
The IANA is requested to list the name "masa" in the MUD extensions The IANA is requested to list the name "masa" in the MUD extensions
registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in
Appendix D. Appendix D.
8. Privacy Considerations 8. Privacy Considerations
8.1. MASA audit log 8.1. MASA audit log
skipping to change at page 66, line 25 skipping to change at page 66, line 40
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>. <https://www.rfc-editor.org/info/rfc5785>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<https://www.rfc-editor.org/info/rfc6961>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
skipping to change at page 75, line 13 skipping to change at page 75, line 13
-----END CERTIFICATE----- -----END CERTIFICATE-----
The registrar public certificate as decoded by openssl's x509 The registrar public certificate as decoded by openssl's x509
utility. Note that the registrar certificate is marked with the utility. Note that the registrar certificate is marked with the
cmcRA extension. cmcRA extension.
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 3 (0x3) Serial Number: 3 (0x3)
Signature Algorithm: ecdsa-with-SHA384 Signature Algorithm: ecdsa-with-SHA384
Issuer: DC = ca, DC = sandelman, CN = Unstrung Fount Issuer: DC=ca, DC=sandelman, CN=Unstrung Fountain CA
ain CA
Validity Validity
Not Before: Sep 5 01:12:45 2017 GMT Not Before: Sep 5 01:12:45 2017 GMT
Not After : Sep 5 01:12:45 2019 GMT Not After : Sep 5 01:12:45 2019 GMT
Subject: DC = ca, DC = sandelman, CN = localhost Subject: DC=ca, DC=sandelman, CN=localhost
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7
8:17: 8:17:
34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5
3:3e: 3:3e:
03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e
9:ba: 9:ba:
skipping to change at page 76, line 46 skipping to change at page 77, line 10
The pledge public certificate as decoded by openssl's x509 utility so The pledge public certificate as decoded by openssl's x509 utility so
that the extensions can be seen. A second custom Extension is that the extensions can be seen. A second custom Extension is
included to provided to contain the EUI48/EUI64 that the pledge will included to provided to contain the EUI48/EUI64 that the pledge will
configure. configure.
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 12 (0xc) Serial Number: 12 (0xc)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: DC = ca, DC = sandelman, CN = Unstrung Highw Issuer: DC=ca, DC=sandelman, CN=Unstrung Highway CA
ay CA
Validity Validity
Not Before: Oct 12 13:52:52 2017 GMT Not Before: Oct 12 13:52:52 2017 GMT
Not After : Dec 31 00:00:00 2999 GMT Not After : Dec 31 00:00:00 2999 GMT
Subject: DC = ca, DC = sandelman, CN = 00-D0-E5-F2-0 Subject: DC=ca, DC=sandelman, CN=00-D0-E5-F2-00-02
0-02
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:49:a7:98:b4:75:4d:5a:52:74:76:bb:cc:0 04:49:a7:98:b4:75:4d:5a:52:74:76:bb:cc:0
c:47: c:47:
08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b 08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b
4:28: 4:28:
96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e 96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e
d:b8: d:b8:
 End of changes. 40 change blocks. 
131 lines changed or deleted 158 lines changed or added

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