--- 1/draft-ietf-ace-coap-est-13.txt 2019-09-20 21:13:10.237209396 -0700 +++ 2/draft-ietf-ace-coap-est-14.txt 2019-09-20 21:13:10.329211723 -0700 @@ -1,23 +1,23 @@ ACE P. van der Stok Internet-Draft Consultant Intended status: Standards Track P. Kampanakis -Expires: March 13, 2020 Cisco Systems +Expires: March 23, 2020 Cisco Systems M. Richardson SSW S. Raza RISE SICS - September 10, 2019 + September 20, 2019 EST over secure CoAP (EST-coaps) - draft-ietf-ace-coap-est-13 + draft-ietf-ace-coap-est-14 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 March 13, 2020. + This Internet-Draft will expire on March 23, 2020. 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 @@ -62,23 +62,23 @@ 5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 10 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 14 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 16 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 17 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 19 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 21 - 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 23 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 24 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10.1. EST server considerations . . . . . . . . . . . . . . . 25 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 27 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 30 @@ -94,20 +94,24 @@ C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 44 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 45 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 1. Change Log EDNOTE: Remove this section before publication + -14 + + Updates to complete Ben's AD review feedback and discussions. + -13 Updates based on AD's review and discussions Examples redone without password -12 Updated section 5 based on Esko's comments and nits identified. @@ -491,25 +494,24 @@ | /serverkeygen | /skg (PKCS#7) | | /serverkeygen | /skc (application/pkix-cert) | | /csrattrs | /att | +------------------+------------------------------+ Table 1: Short EST-coaps URI path The /skg message is the EST /serverkeygen equivalent where the client requests a certificate in PKCS#7 format and a private key. If the client prefers a single application/pkix-cert certificate instead of - PKCS#7, she will make an /skc request. In both cases a private key - MUST be returned + PKCS#7, she will make an /skc request. In both cases (i.e., /skg, + /skc) a private key MUST be returned Clients and servers MUST support the short resource EST-coaps URIs. - The corresponding longer URIs from [RFC7030] MAY be supported. In the context of CoAP, the presence and location of (path to) the EST resources are discovered by sending a GET request to "/.well- known/core" including a resource type (RT) parameter with the value "ace.est*" [RFC6690]. The example below shows the discovery over CoAPS of the presence and location of EST-coaps resources. Linefeeds are included only for readability. REQ: GET /.well-known/core?rt=ace.est* @@ -520,23 +522,21 @@ ;rt="ace.est.att";ct=285, ;rt="ace.est.skg";ct=62, ;rt="ace.est.skc";ct=62 The first three lines, describing ace.est.crts, ace.est.sen, and ace.est.sren, of the discovery response above MUST be returned if the server supports resource discovery. The last three lines are only included if the corresponding EST functions are implemented (see Table 2). The Content-Formats in the response allow the client to request one that is supported by the server. These are the values - that would be sent in the client request with an Accept option. This - approach allows future servers to incorporate currently not specified - content-formats and resources. + that would be sent in the client request with an Accept option. Discoverable port numbers can be returned in the response payload. An example response payload for non-default CoAPS server port 61617 follows below. Linefeeds are included only for readability. REQ: GET /.well-known/core?rt=ace.est* RES: 2.05 Content ;rt="ace.est.crts"; ct="281 TBD287", @@ -844,32 +844,32 @@ . . . POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> <-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age) | | ... Client tries again after Max-Age with identical payload ... | | -POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# 1)}--> +POST [2001:db8::2:1]:61616/est/sen(CON)(1:0/1/256){CSR (frag# 1)}--> <-- (ACK) (1:0/1/256) (2.31 Continue) POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> <-- (ACK) (1:1/1/256) (2.31 Continue) . . . POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> | ... Immediate response when certificate is ready ... | - <-- (ACK) (1:N1/0/256) (2:0/1/128) (2.04 Changed){Cert resp (frag# 1)} + <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)} POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) --> <-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)} . . . POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) --> <-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp (frag# N2+1)} Figure 3: EST-COAP enrollment with long wait @@ -907,55 +907,51 @@ or the asymmetric keypair establishment method is out of scope of the specification. A /skg or /skc request with a CSR without SMIMECapabilities expects an application/multipart-core with an unencrypted PKCS#8 private key with Content-Format 284. The EST-coaps server-side key generation response is returned with Content-Format application/multipart-core [I-D.ietf-core-multipart-ct] containing a CBOR array with four items (Section 5.3) . The two representations (each consisting of two CBOR array items) are preceded by its Content-Format ID. Dependent on the - contents of the CSR, the private key can be in unprotected PKCS#8 - [RFC5958] format (Content-Format 284) or protected inside of CMS - SignedData (Content-Format 280). The SignedData, placed in the - outermost container, is signed by the party that generated the - private key, which may be the EST server or the EST CA. SignedData - placed within the Enveloped Data does not need additional signing as - explained in Section 4.4.2 of [RFC7030]. In summary, the - symmetrically encrypted key is included in the encryptedKey attribute - in a KEKRecipientInfo structure. In the case where the asymmetric - encryption key is suitable for transport key operations the generated - private key is encrypted with a symmetric key which is encrypted by - the client-defined (in the CSR) asymmetric public key and is carried - in an encryptedKey attribute in a KeyTransRecipientInfo structure. + request, the private key can be in unprotected PKCS#8 [RFC5958] + format (Content-Format 284) or protected inside of CMS SignedData + (Content-Format 280). The SignedData, placed in the outermost + container, is signed by the party that generated the private key, + which may be the EST server or the EST CA. SignedData placed within + the Enveloped Data does not need additional signing as explained in + Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted + key is included in the encryptedKey attribute in a KEKRecipientInfo + structure. In the case where the asymmetric encryption key is + suitable for transport key operations the generated private key is + encrypted with a symmetric key which is encrypted by the client- + defined (in the CSR) asymmetric public key and is carried in an + encryptedKey attribute in a KeyTransRecipientInfo structure. Finally, if the asymmetric encryption key is suitable for key agreement, the generated private key is encrypted with a symmetric key which is encrypted by the client defined (in the CSR) asymmetric public key and is carried in an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. [RFC7030] recommends the use of additional encryption of the returned private key. For the context of this specification, clients and servers that choose to support server-side key generation MUST support unprotected (PKCS#8) private keys (Content-Format 284). Symmetric or asymmetric encryption of the private key (CMS EnvelopedData, Content-Format 280) SHOULD be supported for - deployments where end-to-end encryption needs to be provided between - the client and a server. Such cases could include architectures - where an entity between the client and the CA terminates the DTLS - connection (Registrar in Figure 4). - - Following [RFC7030]: "It is strongly RECOMMENDED that the clients - request that the returned private key be afforded the additional - security of the Cryptographic Message Syntax (CMS) EnvelopedData in - addition to the TLS-provided security to protect against unauthorized - disclosure." + deployments where end-to-end encryption is needed between the client + and a server. Such cases could include architectures where an entity + between the client and the CA terminates the DTLS connection + (Registrar in Figure 4). This document does not strongly recommend + CMS encryption on top of the DTLS channel like [RFC7030] unless + mandated by the use-case. 6. HTTPS-CoAPS Registrar In real-world deployments, the EST server will not always reside within the CoAP boundary. The EST server can exist outside the constrained network in which case it will support TLS/HTTP instead of CoAPS. In such environments EST-coaps is used by the client within the CoAP boundary and TLS is used to transport the EST messages outside the CoAP boundary. A Registrar at the edge is required to operate between the CoAP environment and the external HTTP network as @@ -992,21 +988,21 @@ the EST server when a Registrar is present. The EST server becomes aware of the presence of a Registrar from its TLS client certificate that includes id-kp-cmcRA [RFC6402] extended key usage extension (EKU). As explained in Section 3.7 of [RFC7030], the "EST server SHOULD apply an authorization policy consistent with a Registrar client. For example, it could be configured to accept PoP linking information that does not match the current TLS session because the authenticated EST client Registrar has verified this information when acting as an EST server". - For some use cases, clients that leverage server-side key generation + For some use-cases, clients that leverage server-side key generation might prefer for the enrolled keys to be generated by the Registrar if the CA does not support server-side key generation. Such a Registrar is responsible for generating a new CSR signed by a new key which will be returned to the client along with the certificate from the CA. In these cases, the Registrar MUST use random number generation with proper entropy. Table 1 contains the URI mappings between EST-coaps and EST that the Registrar MUST adhere to. Section 5.5 of this specification and Section 7 of [RFC8075] define the mappings between EST-coaps and HTTP @@ -1032,23 +1028,23 @@ This section addresses transmission parameters described in sections 4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on the CoAP parameters in [RFC7252], but the setting of the CoAP parameter values may have consequence for the setting of the EST parameter values. It is recommended, based on experiments, to follow the default CoAP configuration parameters ([RFC7252]). However, depending on the implementation scenario, retransmissions and timeouts can also occur on other networking layers, governed by other configuration - parameters. When a change in a server parameter has been - effectuated, the parameter values in the communicating endpoints MUST - be adjusted when necessary. + parameters. When a change in a server parameter has taken place, the + parameter values in the communicating endpoints MUST be adjusted as + necessary. Some further comments about some specific parameters, mainly from Table 2 in [RFC7252]: o NSTART: A parameter that controls the number of simultaneous outstanding interactions that a client maintains to a given server. An EST-coaps client is expected to control at most one interaction with a given server, which is the default NSTART value defined in [RFC7252]. @@ -1770,33 +1765,34 @@ The following is an example of a cacerts exchange over DTLS. The content length of the cacerts response in appendix A.1 of [RFC7030] contains 639 bytes in binary in this example. The CoAP message adds around 10 bytes in this exmple, the DTLS record around 29 bytes. To avoid IP fragmentation, the CoAP Block Option is used and an MTU of 127 is assumed to stay within one IEEE 802.15.4 packet. To stay below the MTU of 127, the payload is split in 9 packets with a payload of 64 bytes each, followed by a last tenth packet of 63 bytes. The client sends an IPv6 packet containing a UDP datagram - with the DTLS record that encapsulates a CoAP request 10 times. The - server returns an IPv6 packet containing a UDP datagram with a DTLS - record that encapsulates the CoAP response. The CoAP request- - response exchange with block option is shown below. Block Option is - shown in a decomposed way (block-option:NUM/M/size) indicating the - kind of Block Option (2 in this case) followed by a colon, and then - the block number (NUM), the more bit (M = 0 in Block2 response means - it is last block), and block size with exponent (2**(SZX+4)) - separated by slashes. The Length 64 is used with SZX=2. The CoAP - Request is sent confirmable (CON) and the Content-Format of the - response, even though not shown, is 281 (application/pkcs7-mime; - smime-type=certs-only). The transfer of the 10 blocks with partially - filled block NUM=9 is shown below + with DTLS record protection that encapsulates a CoAP request 10 times + (one fragment of the request per block). The server returns an IPv6 + packet containing a UDP datagram with the DTLS record that + encapsulates the CoAP response. The CoAP request-response exchange + with block option is shown below. Block Option is shown in a + decomposed way (block-option:NUM/M/size) indicating the kind of Block + Option (2 in this case) followed by a colon, and then the block + number (NUM), the more bit (M = 0 in Block2 response means it is last + block), and block size with exponent (2**(SZX+4)) separated by + slashes. The Length 64 is used with SZX=2. The CoAP Request is sent + confirmable (CON) and the Content-Format of the response, even though + not shown, is 281 (application/pkcs7-mime; smime-type=certs-only). + The transfer of the 10 blocks with partially filled block NUM=9 is + shown below GET example.com:9085/est/crts (2:0/0/64) --> <-- (2:0/1/64) 2.05 Content GET example.com:9085/est/crts (2:1/0/64) --> <-- (2:1/1/64) 2.05 Content | | | GET example.com:9085/est/crts (2:9/0/64) --> <-- (2:9/0/64) 2.05 Content