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