--- 1/draft-ietf-ace-coap-est-11.txt 2019-06-05 08:13:33.852502693 -0700 +++ 2/draft-ietf-ace-coap-est-12.txt 2019-06-05 08:13:33.944505012 -0700 @@ -1,23 +1,23 @@ ACE P. van der Stok Internet-Draft Consultant Intended status: Standards Track P. Kampanakis -Expires: November 18, 2019 Cisco Systems +Expires: December 7, 2019 Cisco Systems M. Richardson SSW S. Raza RISE SICS - May 17, 2019 + June 5, 2019 EST over secure CoAP (EST-coaps) - draft-ietf-ace-coap-est-11 + draft-ietf-ace-coap-est-12 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,85 +29,93 @@ 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 November 18, 2019. + This Internet-Draft will expire on December 7, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 7 5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 9 + 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 10 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12 - 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12 - 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13 - 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14 + 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13 + 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 14 + 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . 21 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 22 - 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 22 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 10.1. EST server considerations . . . . . . . . . . . . . . . 23 - 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 25 + 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 20 + 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 22 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 23 + 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 23 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 10.1. EST server considerations . . . . . . . . . . . . . . . 24 + 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . 28 - Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30 + Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 31 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31 - A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 32 - A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 34 - A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 36 - Appendix B. EST-coaps Block message examples . . . . . . . . . . 37 - B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 37 - B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 41 - Appendix C. Message content breakdown . . . . . . . . . . . . . 42 - C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42 - C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44 - C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45 + A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 33 + A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 35 + A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 37 + Appendix B. EST-coaps Block message examples . . . . . . . . . . 38 + B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 38 + B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 42 + Appendix C. Message content breakdown . . . . . . . . . . . . . 43 + C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 43 + C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 45 + C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 46 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Change Log EDNOTE: Remove this section before publication + -12 + + Updated section 5 based on Esko's comments and nits identified. + + Nits and some clarifications for Esko's new review from 5/21/2019. + + Nits and some clarifications for Esko's new review from 5/28/2019. + -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 @@ -351,30 +358,33 @@ [ieee802.1ar] or a certificate issued by some other party); the server is expected to trust that certificate. IDevID's are expected to have a very long life, as long as the device, but under some conditions could expire. In that case, the server MAY want to authenticate a client certificate against its trust store although the certificate is expired (Section 10). EST-coaps supports the certificate types and Trust Anchors (TA) that are specified for EST in Section 3 of [RFC7030]. - CoAP and DTLS can provide proof-of-identity for EST-coaps clients and - servers with simple PKI messages as described in Section 3.1 of - [RFC5272]. Moreover, channel-binding information for linking proof- - of-identity with connection-based proof-of-possession is OPTIONAL for - EST-coaps. When proof-of-possession is desired, a set of actions are - required regarding the use of tls-unique, described in Section 3.5 in + As described in Section 2.1 of [RFC5272] proof-of-identity refers to + a value that can be used to prove that the private key corresponding + to the public key is in the possession of and can be used by an end- + entity or client. Additionally, channel-binding information can link + proof-of-identity with an established connetion. Connection-based + proof-of-possession is OPTIONAL for EST-coaps clients and servers. + When proof-of-possession is desired, a set of actions are required + regarding the use of tls-unique, described in Section 3.5 in [RFC7030]. The tls-unique information consists of the contents of the first "Finished" message in the (D)TLS handshake between server and client [RFC5929]. The client adds the "Finished" message as a ChallengePassword in the attributes section of the PKCS#10 Request + [RFC5967] to prove that the client is indeed in control of the private key at the time of the (D)TLS session establishment. In the case of EST-coaps, the same operations can be performed during the DTLS handshake. For DTLS 1.2, in the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed as if each handshake message had been sent as a single fragment (Section 4.2.6 of [RFC6347]). The Finished message is calculated as shown in Section 7.4.9 of [RFC5246]. Similarly, for DTLS 1.3, the Finished @@ -461,77 +471,75 @@ | /csrattrs | /att | | /serverkeygen | /skg (PKCS#7) | | /serverkeygen | /skc (application/pkix-cert) | +------------------+-------------------------------+ Table 1: Short EST-coaps URI path The /skg message is the EST /serverkeygen equivalent where the client requests for a certificate in PKCS#7 format and a private key. If the client prefers a single application/pkix-cert certificate instead - of PKCS#7, he will make an /skc request. + of PKCS#7, she will make an /skc request. Clients and servers MUST support the short resource EST-coaps URIs. In the context of CoAP, the presence and location of (path to) the - management data are discovered by sending a GET request to "/.well- + 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]. Upon success, the return payload will contain - the root resource of the EST resources. The example below shows the - discovery of the presence and location of EST-coaps resources. - Linefeeds are included only for readability. + "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* RES: 2.05 Content ;rt="ace.est.crts";ct="281 TBD287", ;rt="ace.est.sen";ct="281 TBD287", ;rt="ace.est.sren";ct="281 TBD287", ;rt="ace.est.att";ct=285, ;rt="ace.est.skg";ct=62, ;rt="ace.est.skc";ct=62 The first three lines 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. 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. Discoverable port numbers can be returned in the response payload. An example response payload for non-default CoAPS server port 61617 - follows below. Linefeeds were included only for readability. + 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", ;rt="ace.est.sen"; ct="281 TBD287", ;rt="ace.est.sren"; ct="281 TBD287", ;rt="ace.est.att"; ct=285, ;rt="ace.est.skg"; ct=62, ;rt="ace.est.skc"; ct=62 The server MUST support the default /.well-known/est root resource. The server SHOULD support resource discovery when he supports non- default URIs (like /est or /est/ArbitraryLabel) or ports. The client - SHOULD use resource discovery when he is unaware of the available + SHOULD use resource discovery when she is unaware of the available EST-coaps resources. - It is up to the implementation to choose its resource paths; - throughout this document the example root resource /est is used. + Throughout this document the example root resource of /est is used. 5.2. Mandatory/optional EST Functions This specification contains a set of required-to-implement functions, optional functions, and not specified functions. The latter ones are deemed too expensive for low-resource devices in payload and calculation times. Table 2 specifies the mandatory-to-implement or optional implementation of the EST-coaps functions. Discovery of the @@ -619,59 +626,73 @@ The general EST-coaps message characteristics are: o EST-coaps servers sometimes need to provide delayed responses which are conveyed with an empty ACK or an ACK containing response code 5.03 as explained in Section 5.7. Thus, it is RECOMMENDED for implementers to send EST-coaps requests in confirmable CON CoAP messages. o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- - Format, Block, Accept and Location-Path. These CoAP Options are - used to communicate the HTTP fields specified in the EST REST - messages. The Uri-host and Uri-Port Options can be omitted from - the COAP message sent on the wire. When omitted, they are - logically assumed to be the transport protocol destination address - and port respectively. Explicit Uri-Host and Uri-Port Options are + Format, Block1, Block2, and Accept. These CoAP Options are used + to communicate the HTTP fields specified in the EST REST messages. + The Uri-host and Uri-Port Options can be omitted from the COAP + message sent on the wire. When omitted, they are logically + assumed to be the transport protocol destination address and port + respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. Other COAP Options should be handled in accordance with [RFC7252]. o EST URLs are HTTPS based (https://), in CoAP these are assumed to be translated to CoAPS (coaps://) Table 1 provides the mapping from the EST URI path to the EST-coaps URI path. Appendix A includes some practical examples of EST messages translated to CoAP. 5.5. CoAP response codes Section 5.9 of [RFC7252] and Section 7 of [RFC8075] specify the - mapping of HTTP response codes to CoAP response codes. Every time - the HTTP response code 200 is specified in [RFC7030] in response to a - GET request (/cacerts, /csrattrs), the equivalent CoAP response code - 2.05 or 2.03 MUST be used in EST-coaps. Similarly, 2.01, 2.02 or - 2.04 MUST be used in response to EST POST requests (/simpleenroll, - /simplereenroll, /serverkeygen). + mapping of HTTP response codes to CoAP response codes. The success + code in response to an EST-coaps GET request (/crts, /att), is 2.05. + Similarly, 2.04 is used in successfull response to EST-coaps POST + requests (/sen, /sren, /skg, /skc). + + EST makes use of HTTP 204 or 404 responses when a resource is not + available for the client. In EST-coaps 2.04 is used in response to a + POST (/sen, /sren, /skg, /skc). 4.04 is used when the resource is not + available for the client. HTTP response code 202 with a Retry-After header in [RFC7030] has no - equivalent in CoAP. Retry-After is used in EST for delayed server - responses. Section 5.7 specifies how EST-coaps handles delayed - messages. + equivalent in CoAP. HTTP 202 with Retry-After is used in EST for + delayed server responses. Section 5.7 specifies how EST-coaps + handles delayed messages with 5.03 responses with a Max-Age Option. - EST makes use of HTTP 204 and 404 responses when a resource is not - available for the client. The equivalent CoAP codes to use in an - EST-coaps responses are 2.04 and 4.04. Additionally, EST's HTTP 401 - error translates to 4.01 in EST-coaps. Other EST HTTP error messages - are 400, 423 and 503. Their equivalent CoAP errors are 4.00, 4.03 - and 5.03 respectively. In case a CoAP Option is unrecognized and - critical, the server is expected to return a 4.02 (Bad Option). + Additionally, EST's HTTP 400, 401, 403, 404 and 503 status codes have + their equivalent CoAP 4.00, 4.01, 4.03, 4.04 and 5.03 response codes + in EST-coaps. Table 3 summarizes the EST-coaps response codes. + + +-----------------+-----------------+-------------------------------+ + | operation | EST-coaps | Description | + | | response code | | + +-----------------+-----------------+-------------------------------+ + | /crts, /att | 2.05 | Success. Certs included in | + | | | the response payload. | + | | 4.xx / 5.xx | Failure. | + | /sen, /skg, | 2.04 | Success. Cert included in the | + | /sren, /skc | | response payload. | + | | 5.03 | Retry in Max-Age Option time. | + | | 4.xx / 5.xx | Failure. | + +-----------------+-----------------+-------------------------------+ + + Table 3: EST-coaps response codes 5.6. Message fragmentation DTLS defines fragmentation only for the handshake and not for secure data exchange (DTLS records). [RFC6347] states that to avoid using IP fragmentation, which involves error-prone datagram reconstitution, invokers of the DTLS record layer should size DTLS records so that they fit within any Path MTU estimates obtained from the record layer. In addition, invokers residing on a 6LoWPAN over IEEE 802.15.4 [ieee802.15.4] network should attempt to size CoAP messages @@ -695,22 +716,24 @@ conservative IPv4 datagram sizes such as 576 bytes. Even with ECC, EST-coaps messages can still exceed MTU sizes on the Internet or 6LoWPAN [RFC4919] (Section 2 of [RFC7959]). EST-coaps needs to be able to fragment messages into multiple DTLS datagrams. To perform fragmentation in CoAP, [RFC7959] specifies the Block1 Option for fragmentation of the request payload and the Block2 Option for fragmentation of the return payload of a CoAP flow. As explained in Section 1 of [RFC7959], block-wise transfers should be used in Confirmable CoAP messages to avoid the exacerbation of lost blocks. - The EST-coaps client and server MUST support Block2. Block1 MUST be - supported for EST-coaps enrollment requests that exceed the Path MTU. + Both EST-coaps clients and servers MUST support Block2. EST-coaps + servers MUST also support Block1. The EST-coaps client MUST support + Block1 only if it sends EST-coaps requests with an IP packet size + that exceeds the Path MTU. [RFC7959] also defines Size1 and Size2 Options to provide size information about the resource representation in a request and response. EST-client and server MAY support Size1 and Size2 Options. Examples of fragmented EST-coaps messages are shown in Appendix B. 5.7. Delayed Responses Server responses can sometimes be delayed. According to @@ -725,41 +748,41 @@ This situation is shown in Figure 2. The client sends an enrollment request that uses N1+1 Block1 blocks. The server uses an empty 0.00 ACK to announce the delayed response which is provided later with 2.04 messages containing N2+1 Block2 Options. The first 2.04 is a confirmable message that is acknowledged by the client. Onwards, having received the first 256 bytes in the first Block2 block, the client asks for a block reduction to 128 bytes in a confirmable enrollment request and acknowledges the Block2 blocks sent up to that point. - POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> +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 req} --> +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 req} --> +POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> <-- (0.00 empty ACK) | - ...... short delay before certificate is ready ...... + ... Short delay before the certificate is ready ... | - <-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp} + <-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp (frag# 1)} (ACK) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) --> - <-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp} + <-- (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} + <-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp (frag# N2+1)} Figure 2: EST-COAP enrollment with short wait If the server is very slow (i.e. minutes) in providing the response (i.e. when a manual intervention is needed), he SHOULD respond with an ACK containing response code 5.03 (Service unavailable) and a Max- Age Option to indicate the time the client SHOULD wait to request the content later. After a delay of Max-Age, the client SHOULD resend the identical CSR to the server. As long as the server responds with response code 5.03 (Service Unavailable) with a Max-Age Option, the @@ -764,50 +787,58 @@ the identical CSR to the server. As long as the server responds with response code 5.03 (Service Unavailable) with a Max-Age Option, the client SHOULD keep resending the enrollment request until the server responds with the certificate or the client abandons for other reasons. To demonstrate this scenario, Figure 3 shows a client sending an enrollment request that uses N1+1 Block1 blocks to send the CSR to the server. The server needs N2+1 Block2 blocks to respond, but also needs to take a long delay (minutes) to provide the response. + Consequently, the server uses a 5.03 ACK response with a Max-Age - Option. The client waits for a period of Max-Age as many times as he - receives the same 5.03 response and retransmits the enrollment - request until he receives a certificate in a fragmented 2.01 + Option. The client waits for a period of Max-Age as many times as + she receives the same 5.03 response and retransmits the enrollment + request until she receives a certificate in a fragmented 2.04 response. Note that the server asks for a decrease in the block size when acknowledging the first Block2. - POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> +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 req} --> +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 req} --> - <-- (ACK) (1:N1/0/256) (2:0/0/128)(5.03 Service Unavailable) - (Max-Age) + . +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 one or more times after Max-Age with identical payload + ... Client tries again after Max-Age with identical payload ... | | - POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR req} --> - <-- (ACK) (1:N1/0/256) (2:0/1/128) (2.01 Created){Cert resp} +POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/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)}--> + <-- (ACK) (1:N1/0/256) (2:0/1/128) (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.01 Created) {Cert resp} + <-- (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.01 Created) {Cert resp} + <-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp (frag# N2+1)} Figure 3: EST-COAP enrollment with long wait 5.8. Server-side Key Generation 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 @@ -942,22 +973,22 @@ MUST take place at the Registrar when server-side key generation is supported. If CMS end-to-end encryption is employed for the private key, the encrypted CMS EnvelopedData blob MUST be converted to binary in CBOR type 2 downstream to the client. Due to fragmentation of large messages into blocks, an EST-coaps-to- HTTP Registrar MUST reassemble the BLOCKs before translating the binary content to Base64, and consecutively relay the message upstream. - If necessary, the EST-coaps-to-HTTP Registrar will support resouce - discovery according to the rules in Section 5.1. + The EST-coaps-to-HTTP Registrar MUST support resource discovery + according to the rules in Section 5.1. Section 5.1. 7. Parameters 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 EST parameter values need to be tuned to the CoAP parameter values. It is recommended, based on experiments, to follow the default CoAP configuration parameters ([RFC7252]). However, depending on the @@ -997,42 +1028,42 @@ ensure that EST works for networks of constrained devices that choose to limit their communications stack to DTLS/CoAP. It is up to the network designer to decide which devices execute the EST protocol and which do not. 9. IANA Considerations 9.1. Content-Format Registry Additions to the sub-registry "CoAP Content-Formats", within the - "CoRE Parameters" registry [COREparams] are specified in Table 3. - These have been registered provisionally in the Expert Review range - (0-255). + "CoRE Parameters" registry [COREparams] are specified in Table 4. + These have been registered provisionally in the IETF Review or IESG + Approval range (256-9999). +------------------------------+-------+----------------------------+ | HTTP Media-Type | ID | Reference | +------------------------------+-------+----------------------------+ | application/pkcs7-mime; | 280 | [RFC7030] [I-D.ietf-lamps- | | smime-type=server-generated- | | rfc5751-bis] | | key | | | | application/pkcs7-mime; | 281 | [I-D.ietf-lamps-rfc5751-bi | | smime-type=certs-only | | s] | | application/pkcs8 | 284 | [RFC5958] [I-D.ietf-lamps- | | | | rfc5751-bis] | | application/csrattrs | 285 | [RFC7030] [RFC7231] | | application/pkcs10 | 286 | [RFC5967] [I-D.ietf-lamps- | | | | rfc5751-bis] | | application/pkix-cert | TBD28 | [RFC2585] | | | 7 | | +------------------------------+-------+----------------------------+ - Table 3: New CoAP Content-Formats + Table 4: New CoAP Content-Formats It is suggested that 287 is allocated to TBD287. 9.2. Resource Type registry This memo registers new Resource Type (rt=) Link Target Attributes in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry. @@ -1134,28 +1165,26 @@ an attacker could invalidate the purpose of the POP linking ChallengePassword in the client request by resuming an EST-coaps connection. Even though the practical risk of such an attack to EST- coaps is not devastating, we would rather use a more secure channel binding mechanism. Such a mechanism could include an updated tls- unique value generation like the tls-unique-prf defined in [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]). Such mechanism has not been standardized yet. Adopting a channel binding value generated from an exporter would break backwards compatibility. + Thus, in this specification we still depend on the tls-unique + mechanism defined in [RFC5929], especially since a 3SHAKE attack does + not expose messages exchanged with EST-coaps. - Thus, in this specification we still depend in the tls-unique - mechanism defined in [RFC5929], especially since the practicality of - such an attack would not expose any messages exchanged with EST- - coaps. - - Regarding the Certificate Signing Request (CSR), a CA is expected to - be able to enforce policies to recover from improper CSR requests. + Regarding the Certificate Signing Request (CSR), an EST-coaps server + is expected to be able to recover from improper CSR requests. Interpreters of ASN.1 structures should be aware of the use of invalid ASN.1 length fields and should take appropriate measures to guard against buffer overflows, stack overruns in particular, and malicious content in general. 10.2. HTTPS-CoAPS Registrar considerations The Registrar proposed in Section 6 must be deployed with care, and only when the recommended connections are impossible. When POP @@ -1164,21 +1193,21 @@ for POP linking to be enforced end-to-end for the EST transaction. The EST server could be configured to accept POP linking information that does not match the current TLS session because the authenticated EST Registrar client has verified this information when acting as an EST server. The introduction of an EST-coaps-to-HTTP Registrar assumes the client can trust the registrar using its implicit or explicit TA database. It also assumes the Registrar has a trust relationship with the upstream EST server in order to act on behalf of the clients. When a - client uses the Implicit TA database for certificate validation, he + client uses the Implicit TA database for certificate validation, she SHOULD confirm if the server is acting as an RA by the presence of the id-kp-cmcRA EKU [RFC6402] in the server certificate. In a server-side key generation case, if no end-to-end encryption is used, the Registrar may be able see the private key as it acts as a man-in-the-middle. Thus, the client puts its trust on the Registrar not exposing the private key. Clients that leverage server-side key generation without end-to-end encryption of the private key (Section 5.8) have no knowledge if the @@ -1263,26 +1292,20 @@ [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, . - [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and - E. Dijk, "Guidelines for Mapping Implementations: HTTP to - the Constrained Application Protocol (CoAP)", RFC 8075, - DOI 10.17487/RFC8075, February 2017, - . - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 13.2. Informative References @@ -1373,20 +1396,26 @@ Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, . + [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and + E. Dijk, "Guidelines for Mapping Implementations: HTTP to + the Constrained Application Protocol (CoAP)", RFC 8075, + DOI 10.17487/RFC8075, February 2017, + . + [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, . [RSAfact] "Factoring RSA keys from certified smart cards: Coppersmith in the wild", Advances in Cryptology - ASIACRYPT 2013, August 2013. @@ -1539,24 +1567,24 @@ 028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75 f602f9152618f816a2b23b5638e59fd9a073303406092a864886f70d0109 0731270c2576437630292a264a4b4a3bc3a2c280c2992f3e3c2e2c3d6b6e 7634332323403d204e787e60303b06092a864886f70d01090e312e302c30 2a0603551d1104233021a01f06082b06010505070804a013301106092b06 010401b43b0a01040401020304300a06082a8648ce3d0403020348003045 02210092563a546463bd9ecff170d0fd1f2ef0d3d012160e5ee90cffedab ec9b9a38920220179f10a3436109051abad17590a09bc87c4dce5453a6fc 1135a1e84eed754377 - After verification of the CSR by the server, a 2.01 Content response + After verification of the CSR by the server, a 2.04 Changed response with the issued certificate will be returned to the client. - 2.01 Created + 2.04 Changed (Token: 0x45) (Content-Format: 281) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] 3082026e06092a864886f70d010702a082025f3082025b0201013100300b 06092a864886f70d010701a08202413082023d308201e2a0030201020208 7e7661d7b54e4632300a06082a8648ce3d040302305d310b300906035504 @@ -1596,21 +1624,21 @@ 3081cf3078020100301631143012060355040a0c0b736b67206578616d70 6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b b8c1117896f98e4506c03d70efbe820d8e38ea97e9d65d52c8460c5852c5 1dd89a61370a2843760fc859799d78cd33f3c1846e304f1717f8123f1a28 4cc99fa000300a06082a8648ce3d04030203470030440220387cd4e9cf62 8d4af77f92ebed4890d9d141dca86cd2757dd14cbd59cdf6961802202f24 5e828c77754378b66660a4977f113cacdaa0cc7bad7d1474a7fd155d090d The response would follow [I-D.ietf-core-multipart-ct] and could look like - 2.01 Content + 2.04 Changed (Token: 0xa5) (Content-Format: 62) [ The hexadecimal representations below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] 84 # array(4) 19 011C # unsigned(284) 58 8A # bytes(138)