draft-ietf-ace-coap-est-10.txt   draft-ietf-ace-coap-est-11.txt 
ACE P. van der Stok ACE P. van der Stok
Internet-Draft Consultant Internet-Draft Consultant
Intended status: Standards Track P. Kampanakis Intended status: Standards Track P. Kampanakis
Expires: September 9, 2019 Cisco Systems Expires: November 18, 2019 Cisco Systems
M. Richardson M. Richardson
SSW SSW
S. Raza S. Raza
RISE SICS RISE SICS
March 8, 2019 May 17, 2019
EST over secure CoAP (EST-coaps) EST over secure CoAP (EST-coaps)
draft-ietf-ace-coap-est-10 draft-ietf-ace-coap-est-11
Abstract Abstract
Enrollment over Secure Transport (EST) is used as a certificate Enrollment over Secure Transport (EST) is used as a certificate
provisioning protocol over HTTPS. Low-resource devices often use the provisioning protocol over HTTPS. Low-resource devices often use the
lightweight Constrained Application Protocol (CoAP) for message lightweight Constrained Application Protocol (CoAP) for message
exchanges. This document defines how to transport EST payloads over exchanges. This document defines how to transport EST payloads over
secure CoAP (EST-coaps), which allows constrained devices to use secure CoAP (EST-coaps), which allows constrained devices to use
existing EST functionality for provisioning certificates. existing EST functionality for provisioning certificates.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 9, 2019. This Internet-Draft will expire on November 18, 2019.
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 2, line 28 skipping to change at page 2, line 28
5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 9 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 9
5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12
5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12
5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13
5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14
5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 15 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 15
5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 16 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 16
5.8. Server-side Key Generation . . . . . . . . . . . . . . . 18 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 18
6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19
7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Deployment limitations . . . . . . . . . . . . . . . . . . . 22 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 22 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 22
9.2. Resource Type registry . . . . . . . . . . . . . . . . . 23 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. EST server considerations . . . . . . . . . . . . . . . 23 10.1. EST server considerations . . . . . . . . . . . . . . . 23
10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 25 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 25
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 26 13.1. Normative References . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30
A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 3, line 11 skipping to change at page 3, line 11
C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42 C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42
C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44
C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Change Log 1. Change Log
EDNOTE: Remove this section before publication EDNOTE: Remove this section before publication
-11
Updated Server-side keygen to simplify motivation and added
paragraphs in Security considerations to point out that random
numbers are still needed (feedback from Hannes).
-10 -10
Addressed WGLC comments Addressed WGLC comments
More consistent request format in the examples. More consistent request format in the examples.
Explained root resource difference when there is resource Explained root resource difference when there is resource
discovery discovery
Clarified when the client is supposed to do discovery Clarified when the client is supposed to do discovery
skipping to change at page 18, line 7 skipping to change at page 18, line 7
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) -->
<-- (ACK) (2:N2/0/128) (2.01 Created) {Cert resp} <-- (ACK) (2:N2/0/128) (2.01 Created) {Cert resp}
Figure 3: EST-COAP enrollment with long wait Figure 3: EST-COAP enrollment with long wait
5.8. Server-side Key Generation 5.8. Server-side Key Generation
Constrained devices sometimes do not have the necessary hardware to In scenarios where it is desirable that the server generates the
generate statistically random numbers for private keys and DTLS private key, server-side key generation should be used. Such
ephemeral keys. Past experience has also shown that low-resource scenarios could be when it is considered more secure to generate at
endpoints sometimes generate numbers which could allow someone to the server the long-lived random private key that identifies the
decrypt the communication or guess the private key and impersonate as client, or when the resources spent to generate a random private key
the device [PsQs] [RSAorig]. Additionally, random number key at the client are considered scarce, or when the security policy
generation is costly, thus energy draining. Even though the random requires that the certificate public and corresponding private keys
numbers that constitute the identity/cert do not get generated often, are centrally generated and controlled. Of course, that does not
an endpoint may not want to spend time and energy generating eliminate the need for proper random numbers in various protocols
keypairs, and just ask for one from the server. like (D)TLS (Section 10.1).
In these scenarios, server-side key generation can be used. The When requesting server-side key generation, the client asks for the
client asks for the server or proxy to generate the private key and server or proxy to generate the private key and the certificate which
the certificate which are transferred back to the client in the are transferred back to the client in the server-side key generation
server-side key generation response. In all respects, the server response. In all respects, the server SHOULD treat the CSR as it
SHOULD treat the CSR as it would treat any enroll or re-enroll CSR; would treat any enroll or re-enroll CSR; the only distinction here is
the only distinction here is that the server MUST ignore the public that the server MUST ignore the public key values and signature in
key values and signature in the CSR. These are included in the the CSR. These are included in the request only to allow re-use of
request only to allow re-use of existing codebases for generating and existing codebases for generating and parsing such requests.
parsing such requests.
The client /skg request is for a certificate in a PKCS#7 container The client /skg request is for a certificate in a PKCS#7 container
and private key in two application/multipart-core elements. and private key in two application/multipart-core elements.
Respectively, an /skc request is for a single application/pkix-cert Respectively, an /skc request is for a single application/pkix-cert
certificate and a private key. The private key Content-Format certificate and a private key. The private key Content-Format
requested by the client is depicted in the PKCS#10 CSR request. If requested by the client is depicted in the PKCS#10 CSR request. If
the request contains SMIMECapabilities and DecryptKeyIdentifier or the request contains SMIMECapabilities and DecryptKeyIdentifier or
AsymmetricDecryptKeyIdentifier the client is expecting Content-Format AsymmetricDecryptKeyIdentifier the client is expecting Content-Format
280 for the private key. Then the private key is encrypted 280 for the private key. Then the private key is encrypted
symmetrically or asymmetrically as per [RFC7030]. The symmetric key symmetrically or asymmetrically as per [RFC7030]. The symmetric key
skipping to change at page 23, line 41 skipping to change at page 23, line 25
10. Security Considerations 10. Security Considerations
10.1. EST server considerations 10.1. EST server considerations
The security considerations of Section 6 of [RFC7030] are only The security considerations of Section 6 of [RFC7030] are only
partially valid for the purposes of this document. As HTTP Basic partially valid for the purposes of this document. As HTTP Basic
Authentication is not supported, the considerations expressed for Authentication is not supported, the considerations expressed for
using passwords do not apply. using passwords do not apply.
Given that the client has only limited resources and may not be able Modern security protocols require random numbers to be available
to generate sufficiently random keys to encrypt its identity, it is during the protocol run, for example for nonces, ephemeral (EC)
possible that the client uses server generated private/public keys. Diffie-Hellman key generation. This capability to generate random
The transport of these keys is inherently risky. Analysis SHOULD be numbers is also needed when the constrained device generates the
done to establish whether server-side key generation enhances or private key (that corresponds to the public key enrolled in the CSR).
decreases the probability of identity stealing. When server-side key generation is used, the constrained device
depends on the server to generate the private key randomly, but it
still needs locally generated random numbers for use in security
protocols, as explained in Section 12 of [RFC7925]. Additionally,
the transport of keys generated at the server is inherently risky.
Analysis SHOULD be done to establish whether server-side key
generation increases or decreases the probability of digital identity
theft.
It is important to note that sources contributing to the randomness
pool used to generate random numbers on laptops or desktop PCs are
not available on many constrained devices, such as mouse movement,
timing of keystrokes, air turbulence on the movement of hard drive
heads, as pointed out in [PsQs]. Other sources have to be used or
dedicated hardware has to be added. Selecting hardware for an IoT
device that is capable of producing high-quality random numbers is
therefore important [RSAfact].
It is also RECOMMENDED that the Implicit Trust Anchor database used It is also RECOMMENDED that the Implicit Trust Anchor database used
for EST server authentication is carefully managed to reduce the for EST server authentication is carefully managed to reduce the
chance of a third-party CA with poor certification practices chance of a third-party CA with poor certification practices
jeopardizing authentication. Disabling the Implicit Trust Anchor jeopardizing authentication. Disabling the Implicit Trust Anchor
database after successfully receiving the Distribution of CA database after successfully receiving the Distribution of CA
certificates response (Section 4.1.3 of [RFC7030]) limits any risk to certificates response (Section 4.1.3 of [RFC7030]) limits any risk to
the first DTLS exchange. Alternatively, in a case where a /sen the first DTLS exchange. Alternatively, in a case where a /sen
request immediately follows a /crt, a client MAY choose to keep the request immediately follows a /crts, a client MAY choose to keep the
connection authenticated by the Implicit TA open for efficiency connection authenticated by the Implicit TA open for efficiency
reasons (Section 4). A client that pipelines EST-coaps /crt request reasons (Section 4). A client that pipelines EST-coaps /crts request
with other requests in the same DTLS connection SHOULD revalidate the with other requests in the same DTLS connection SHOULD revalidate the
server certificate chain against the updated Explicit TA from the server certificate chain against the updated Explicit TA from the
/crt response before proceeding with the subsequent requests. If the /crts response before proceeding with the subsequent requests. If
server certificate chain does not authenticate against the database, the server certificate chain does not authenticate against the
the client SHOULD close the connection without completing the rest of database, the client SHOULD close the connection without completing
the requests. The updated Explicit TA MUST continue to be used in the rest of the requests. The updated Explicit TA MUST continue to
new DTLS connections. be used in new DTLS connections.
In cases where the IDevID used to authenticate the client is expired In cases where the IDevID used to authenticate the client is expired
the server MAY still authenticate the client because IDevIDs are the server MAY still authenticate the client because IDevIDs are
expected to live as long as the device itself (Section 4). In such expected to live as long as the device itself (Section 4). In such
occasions, checking the certificate revocation status or authorizing occasions, checking the certificate revocation status or authorizing
the client using another method is important for the server to ensure the client using another method is important for the server to ensure
that the client is to be trusted. that the client is to be trusted.
In accordance with [RFC7030], TLS cipher suites that include In accordance with [RFC7030], TLS cipher suites that include
"_EXPORT_" and "_DES_" in their names MUST NOT be used. More "_EXPORT_" and "_DES_" in their names MUST NOT be used. More
skipping to change at page 26, line 36 skipping to change at page 26, line 36
Camezind, Bjorn Elmers and Joel Hoglund. Camezind, Bjorn Elmers and Joel Hoglund.
Robert Moskowitz provided code to create the examples. Robert Moskowitz provided code to create the examples.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-core-multipart-ct] [I-D.ietf-core-multipart-ct]
Fossati, T., Hartke, K., and C. Bormann, "Multipart Fossati, T., Hartke, K., and C. Bormann, "Multipart
Content-Format for CoAP", draft-ietf-core-multipart-ct-02 Content-Format for CoAP", draft-ietf-core-multipart-ct-03
(work in progress), August 2018. (work in progress), March 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-30 (work in progress), 1.3", draft-ietf-tls-dtls13-31 (work in progress), March
November 2018. 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, DOI 10.17487/RFC2585, May 1999, RFC 2585, DOI 10.17487/RFC2585, May 1999,
<https://www.rfc-editor.org/info/rfc2585>. <https://www.rfc-editor.org/info/rfc2585>.
skipping to change at page 28, line 23 skipping to change at page 28, line 23
<https://www.iana.org/assignments/core-parameters/ <https://www.iana.org/assignments/core-parameters/
core-parameters.xhtml>. core-parameters.xhtml>.
[I-D.ietf-lamps-rfc5751-bis] [I-D.ietf-lamps-rfc5751-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", draft-ietf-lamps-rfc5751-bis-12 Message Specification", draft-ietf-lamps-rfc5751-bis-12
(work in progress), September 2018. (work in progress), September 2018.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
"Connection Identifiers for DTLS 1.2", draft-ietf-tls- Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
dtls-connection-id-02 (work in progress), October 2018. id-05 (work in progress), May 2019.
[I-D.josefsson-sasl-tls-cb] [I-D.josefsson-sasl-tls-cb]
Josefsson, S., "Channel Bindings for TLS based on the Josefsson, S., "Channel Bindings for TLS based on the
PRF", draft-josefsson-sasl-tls-cb-03 (work in progress), PRF", draft-josefsson-sasl-tls-cb-03 (work in progress),
March 2015. March 2015.
[I-D.moskowitz-ecdsa-pki] [I-D.moskowitz-ecdsa-pki]
Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson,
"Guide for building an ECC pki", draft-moskowitz-ecdsa- "Guide for building an ECC pki", draft-moskowitz-ecdsa-
pki-04 (work in progress), September 2018. pki-05 (work in progress), March 2019.
[ieee802.15.4] [ieee802.15.4]
"IEEE Standard 802.15.4-2006", 2006. "IEEE Standard 802.15.4-2006", 2006.
[ieee802.1ar] [ieee802.1ar]
"IEEE 802.1AR Secure Device Identifier", December 2009. "IEEE 802.1AR Secure Device Identifier", December 2009.
[PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys [PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys
in Network Devices", USENIX Security Symposium 2012 ISBN in Network Devices", USENIX Security Symposium 2012 ISBN
978-931971-95-9, August 2012. 978-931971-95-9, August 2012.
skipping to change at page 30, line 17 skipping to change at page 30, line 17
Profiles for the Internet of Things", RFC 7925, Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016, DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422, Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018, DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>. <https://www.rfc-editor.org/info/rfc8422>.
[RSAorig] "The Million-Key Question - Investigating the Origins of [RSAfact] "Factoring RSA keys from certified smart cards:
RSA Public Keys", USENIX Security Symposium 2016 ISBN Coppersmith in the wild", Advances in Cryptology -
978-1-931971-32-4, August 2016. ASIACRYPT 2013, August 2013.
[tripleshake] [tripleshake]
"Triple Handshakes and Cookie Cutters: Breaking and Fixing "Triple Handshakes and Cookie Cutters: Breaking and Fixing
Authentication over TLS", IEEE Security and Privacy ISBN Authentication over TLS", IEEE Security and Privacy ISBN
978-1-4799-4686-0, May 2014. 978-1-4799-4686-0, May 2014.
Appendix A. EST messages to EST-coaps Appendix A. EST messages to EST-coaps
This section shows similar examples to the ones presented in This section shows similar examples to the ones presented in
Appendix A of [RFC7030]. The payloads in the examples are the hex Appendix A of [RFC7030]. The payloads in the examples are the hex
 End of changes. 18 change blocks. 
49 lines changed or deleted 70 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/