draft-ietf-anima-bootstrapping-keyinfra-27.txt   draft-ietf-anima-bootstrapping-keyinfra-28.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: March 18, 2020 Sandelman Expires: March 21, 2020 Sandelman
T. Eckert T. Eckert
Futurewei USA Futurewei USA
M. Behringer M. Behringer
K. Watsen K. Watsen
Watsen Networks Watsen Networks
September 15, 2019 September 18, 2019
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-27 draft-ietf-anima-bootstrapping-keyinfra-28
Abstract Abstract
This document specifies automated bootstrapping of an Autonomic This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Remote Secure Key Infrastructure (BRSKI) Control Plane. To do this a Remote Secure Key Infrastructure (BRSKI)
is created using manufacturer installed X.509 certificates, in is created using manufacturer installed X.509 certificates, in
combination with a manufacturer's authorizing service, both online combination with a manufacturer's authorizing service, both online
and offline. Bootstrapping a new device can occur using a routable and offline. Bootstrapping a new device can occur using a routable
address and a cloud service, or using only link-local connectivity, address and a cloud service, or using only link-local connectivity,
or on limited/disconnected networks. Support for lower security or on limited/disconnected networks. Support for lower security
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 March 18, 2020. This Internet-Draft will expire on March 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 35 skipping to change at page 3, line 35
5.5.4. MASA verification of domain registrar . . . . . . . . 46 5.5.4. MASA verification of domain registrar . . . . . . . . 46
5.5.5. MASA verification of pledge prior-signed-voucher- 5.5.5. MASA verification of pledge prior-signed-voucher-
request . . . . . . . . . . . . . . . . . . . . . . . 47 request . . . . . . . . . . . . . . . . . . . . . . . 47
5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 47 5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 47
5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 47 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 47
5.6.1. Pledge voucher verification . . . . . . . . . . . . . 50 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 50
5.6.2. Pledge authentication of provisional TLS connection . 51 5.6.2. Pledge authentication of provisional TLS connection . 51
5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 52 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 52
5.8. Registrar audit-log request . . . . . . . . . . . . . . . 53 5.8. Registrar audit-log request . . . . . . . . . . . . . . . 53
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 54 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 54
5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 56 5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 57
5.8.3. Registrar audit log verification . . . . . . . . . . 57 5.8.3. Registrar audit log verification . . . . . . . . . . 57
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 58 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 59
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 58 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 59
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 59 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 59
5.9.3. EST Client Certificate Request . . . . . . . . . . . 60 5.9.3. EST Client Certificate Request . . . . . . . . . . . 60
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 60 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 60
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 61 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 61
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 61 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 61
6. Clarification of transfer-encoding . . . . . . . . . . . . . 61 6. Clarification of transfer-encoding . . . . . . . . . . . . . 62
7. Reduced security operational modes . . . . . . . . . . . . . 61 7. Reduced security operational modes . . . . . . . . . . . . . 62
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 62 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 62
7.2. Pledge security reductions . . . . . . . . . . . . . . . 62 7.2. Pledge security reductions . . . . . . . . . . . . . . . 63
7.3. Registrar security reductions . . . . . . . . . . . . . . 63 7.3. Registrar security reductions . . . . . . . . . . . . . . 64
7.4. MASA security reductions . . . . . . . . . . . . . . . . 64 7.4. MASA security reductions . . . . . . . . . . . . . . . . 65
7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 64 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 65
7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 65 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 66
7.4.3. Updating or extending voucher trust anchors . . . . . 66 7.4.3. Updating or extending voucher trust anchors . . . . . 66
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 67 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 67
8.2. Well-known EST registration . . . . . . . . . . . . . . . 67 8.2. Well-known EST registration . . . . . . . . . . . . . . . 67
8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 67 8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 68
8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 67 8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 68
8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 68 8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 68
8.6. MUD File Extension for the MASA . . . . . . . . . . . . . 68 8.6. MUD File Extension for the MASA . . . . . . . . . . . . . 69
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 68 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 69
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 70 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 70
10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 70 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 70
10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 70 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 71
10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 71 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 71
10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 73 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 74
10.5. Manufacturers and Grey market equipment . . . . . . . . 74 10.5. Manufacturers and Grey market equipment . . . . . . . . 75
10.6. Some mitigations for meddling by manufacturers . . . . . 75 10.6. Some mitigations for meddling by manufacturers . . . . . 75
10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 76 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 76
11. Security Considerations . . . . . . . . . . . . . . . . . . . 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 77
11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 77 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 78
11.2. Availability of good random numbers . . . . . . . . . . 78 11.2. Availability of good random numbers . . . . . . . . . . 78
11.3. Freshness in Voucher-Requests . . . . . . . . . . . . . 78 11.3. Freshness in Voucher-Requests . . . . . . . . . . . . . 79
11.4. Trusting manufacturers . . . . . . . . . . . . . . . . . 79 11.4. Trusting manufacturers . . . . . . . . . . . . . . . . . 80
11.5. Manufacturer Maintenance of trust anchors . . . . . . . 81 11.5. Manufacturer Maintenance of trust anchors . . . . . . . 81
11.5.1. Compromise of Manufacturer IDevID signing keys . . . 82 11.5.1. Compromise of Manufacturer IDevID signing keys . . . 82
11.5.2. Compromise of MASA signing keys . . . . . . . . . . 82 11.5.2. Compromise of MASA signing keys . . . . . . . . . . 83
11.5.3. Compromise of MASA web service . . . . . . . . . . . 84 11.5.3. Compromise of MASA web service . . . . . . . . . . . 85
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 85
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
13.1. Normative References . . . . . . . . . . . . . . . . . . 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 86
13.2. Informative References . . . . . . . . . . . . . . . . . 89 13.2. Informative References . . . . . . . . . . . . . . . . . 89
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 92 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 92
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 92 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 93
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 92 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 93
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 93 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 93
Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 93 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 94
Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 96 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 96
D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 96 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 96
D.1.1. MASA key pair for voucher signatures . . . . . . . . 96 D.1.1. MASA key pair for voucher signatures . . . . . . . . 96
D.1.2. Manufacturer key pair for IDevID signatures . . . . . 96 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 96
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 97 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 97
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 99 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 99
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 100 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 100
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 101 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 101
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 104 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 104
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 109 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 109
skipping to change at page 49, line 23 skipping to change at page 49, line 23
The voucher response format is as indicated in the submitted Accept The voucher response format is as indicated in the submitted Accept
header fields or based on the MASA's prior understanding of proper header fields or based on the MASA's prior understanding of proper
format for this Pledge. Only the [RFC8366] "application/voucher- format for this Pledge. Only the [RFC8366] "application/voucher-
cms+json" media type is defined at this time. The syntactic details cms+json" media type is defined at this time. The syntactic details
of vouchers are described in detail in [RFC8366]. Figure 14 shows a of vouchers are described in detail in [RFC8366]. Figure 14 shows a
sample of the contents of a voucher. sample of the contents of a voucher.
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"assertion": "logging", "assertion": "logged",
"pinned-domain-cert": "base64encodedvalue==", "pinned-domain-cert": "base64encodedvalue==",
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
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.
skipping to change at page 54, line 33 skipping to change at page 54, line 33
A MASA that returns a code 200 MAY also include a Location: header A MASA that returns a code 200 MAY also include a Location: header
for future reference by the registrar. for future reference by the registrar.
5.8.1. MASA audit log response 5.8.1. MASA audit log response
A log data file is returned consisting of all log entries associated A log data file is returned consisting of all log entries associated
with the device selected by the IDevID presented in the request. The with the device selected by the IDevID presented in the request. The
audit log may be abridged by removal of old or repeated values as audit log may be abridged by removal of old or repeated values as
explained below. The returned data is in JSON format ([RFC8259]), explained below. The returned data is in JSON format ([RFC8259]),
and the Content-Type SHOULD be "application/json". For example: and the Content-Type SHOULD be "application/json".
The following CDDL ([RFC8610]) explains the structure of the JSON
format audit-log response:
audit-log-response = {
"version": uint,
"events": [ + event ]
"truncation": {
? "nonced duplicates": uint,
? "nonceless duplicates": uint,
? "arbitrary": uint,
}
}
event = {
"date": text,
"domainID": text,
"nonce": text / null,
"assertion": "verified" / "logged" / "proximity",
? "truncated": uint,
}
Figure 16: CDDL for audit-log response
As an abstract example:
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"<date and time as per RFC3339 section 5.6>", "date":"<date and time as per RFC3339 section 5.6>",
"domainID":"<domainID extracted from voucher-request>", "domainID":"<domainID extracted from voucher-request>",
"nonce":"<nonce as supplied (or NULL)>", "nonce":"<nonce as supplied (or NULL)>",
"assertion":"<the value from the voucher assertion leaf>", "assertion":"<the value from the voucher assertion leaf>",
"truncated":"<the number of domainID entries truncated>" "truncated":"<the number of domainID entries truncated>"
skipping to change at page 55, line 29 skipping to change at page 55, line 51
"assertion":"<the value from the voucher assertion leaf>" "assertion":"<the value from the voucher assertion leaf>"
} }
], ],
"truncation": { "truncation": {
"nonced duplicates": "<total number of entries truncated>", "nonced duplicates": "<total number of entries truncated>",
"nonceless duplicates": "<total number of entries truncated>", "nonceless duplicates": "<total number of entries truncated>",
"arbitrary": "<number of domainID entries removed entirely>" "arbitrary": "<number of domainID entries removed entirely>"
} }
} }
Figure 16: Example of audit-log response Figure 17: Example of audit-log response
The domainID is a binary value calculated SubjectKeyIdentifier The domainID is a binary value calculated SubjectKeyIdentifier
according to Section 5.8.2. It is encoded once in base64 in order to according to Section 5.8.2. It is encoded once in base64 in order to
be transported in this JSON container. be transported in this JSON container.
The date is in [RFC3339] format, which is consistent with typical The date is in [RFC3339] format, which is consistent with typical
JavaScript usage of JSON. JavaScript usage of JSON.
The truncation structure MAY be omitted if all values are zero. Any
counter missing from the truncation structure is the be assumed to be
zero.
The nonce is a string, as provided in the voucher-request, and used The nonce is a string, as provided in the voucher-request, and used
in the voucher. If no nonce was placed in the resulting voucher, in the voucher. If no nonce was placed in the resulting voucher,
then a value of null SHOULD be used in preference to omitting the then a value of null SHOULD be used in preference to omitting the
entry. While the nonce is often created as a base64 encoded random entry. While the nonce is often created as a base64 encoded random
series of bytes, this should not be assumed. series of bytes, this should not be assumed.
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 abridged from the log leaving only the single most domainID MAY be abridged from the log leaving only the single most
recent nonced or nonceless entry for that domainID. In the case of recent nonced or nonceless entry for that domainID. In the case of
skipping to change at page 60, line 51 skipping to change at page 61, line 27
An example status report can be seen below. It is sent with with the An example status report can be seen below. It is sent with with the
media type: application/json media type: application/json
{ {
"version":"1", "version":"1",
"Status":true, "Status":true,
"Reason":"Informative human readable message", "Reason":"Informative human readable message",
"reason-context": "Additional information" "reason-context": "Additional information"
} }
Figure 17: Example of enrollment status POST Figure 18: Example of enrollment status POST
The server SHOULD respond with an HTTP 200 but MAY simply fail with The server SHOULD respond with an HTTP 200 but MAY simply fail with
an HTTP 404 error. an HTTP 404 error.
Within the server logs the server MUST capture if this message was Within the server logs the server MUST capture if this message was
received over an TLS session with a matching client certificate. received over an TLS session with a matching client certificate.
5.9.5. Multiple certificates 5.9.5. Multiple certificates
Pledges that require multiple certificates could establish direct EST Pledges that require multiple certificates could establish direct EST
skipping to change at page 85, line 28 skipping to change at page 85, line 45
12. Acknowledgements 12. Acknowledgements
We would like to thank the various reviewers for their input, in We would like to thank the various reviewers for their input, in
particular William Atwood, Brian Carpenter, Fuyu Eleven, Eliot Lear, particular William Atwood, Brian Carpenter, Fuyu Eleven, Eliot Lear,
Sergey Kasatkin, Anoop Kumar, Markus Stenberg, Peter van der Stok, Sergey Kasatkin, Anoop Kumar, Markus Stenberg, Peter van der Stok,
and Thomas Werner and Thomas Werner
Significant reviews were done by Jari Arko, Christian Huitema and Significant reviews were done by Jari Arko, Christian Huitema and
Russ Housley. Russ Housley.
Henk Birkholz contributed the CDDL for the audit log response.
This document started it's life as a two-page idea from Steinthor This document started it's life as a two-page idea from Steinthor
Bjarnason. Bjarnason.
In addition, significant review comments were receives by many IESG In addition, significant review comments were receives by many IESG
members, including Adam Roach, Alexey Melnikov, Alissa Cooper, members, including Adam Roach, Alexey Melnikov, Alissa Cooper,
Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund. Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund.
13. References 13. References
13.1. Normative References 13.1. Normative References
 End of changes. 24 change blocks. 
36 lines changed or deleted 67 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/