--- 1/draft-ietf-ace-coap-est-03.txt 2018-07-02 10:13:10.972223347 -0700 +++ 2/draft-ietf-ace-coap-est-04.txt 2018-07-02 10:13:11.052225258 -0700 @@ -1,27 +1,27 @@ ACE P. van der Stok Internet-Draft Consultant Intended status: Standards Track P. Kampanakis -Expires: December 27, 2018 Cisco Systems +Expires: January 3, 2019 Cisco Systems S. Kumar Philips Lighting Research M. Richardson SSW M. Furuhed Nexus Group S. Raza RISE SICS - June 25, 2018 + July 2, 2018 EST over secure CoAP (EST-coaps) - draft-ietf-ace-coap-est-03 + draft-ietf-ace-coap-est-04 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 low-resource constrained devices to use existing EST functionality for provisioning certificates. @@ -34,21 +34,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 December 27, 2018. + This Internet-Draft will expire on January 3, 2019. Copyright Notice Copyright (c) 2018 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 @@ -61,39 +61,39 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conformance to RFC7925 profiles . . . . . . . . . . . . . . . 3 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Payload format . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Content Format application/multipart-core . . . . . . 6 4.2. Message Bindings . . . . . . . . . . . . . . . . . . . . 6 4.3. CoAP response codes . . . . . . . . . . . . . . . . . . . 6 - 4.4. Delayed Results . . . . . . . . . . . . . . . . . . . . . 7 + 4.4. Delayed Responses . . . . . . . . . . . . . . . . . . . . 7 4.5. Server-side Key Generation . . . . . . . . . . . . . . . 9 4.6. Message fragmentation . . . . . . . . . . . . . . . . . . 10 4.7. Deployment limits . . . . . . . . . . . . . . . . . . . . 11 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 11 6. DTLS Transport Protocol . . . . . . . . . . . . . . . . . . . 13 7. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 14 8. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 17 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10.1. EST server considerations . . . . . . . . . . . . . . . 18 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 13.2. Informative References . . . . . . . . . . . . . . . . . 22 + 13.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 24 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.2. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 29 A.3. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 29 A.4. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 32 Appendix B. EST-coaps Block message examples . . . . . . . . . . 34 B.1. cacerts block example . . . . . . . . . . . . . . . . . . 34 B.2. enroll block example . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 @@ -279,43 +279,40 @@ 2.01, 2.02 or 2.04 MUST be used in response to POST EST requests. Response code HTTP 202 has no equivalent in CoAP. In Section 4.4 it is specified how EST requests over CoAP handle delayed messages. All other HTTP 2xx response codes are not used by EST. For the following HTTP 4xx error codes that may occur: 400, 401, 403, 404, 405, 406, 412, 413, 415; the equivalent CoAP response code for EST- coaps is 4.xx. For the HTTP 5xx error codes: 500, 501, 502, 503, 504 the equivalent CoAP response code is 5.xx. -4.4. Delayed Results - - Using the enroll request with CSR reponse, examples ae shown for a - server without delay, a short delay and a long delay. +4.4. Delayed Responses - When the server can respond immediately, and multiple blocks need to - be sent, Appendix B.2 shows the corresponding exchange of blocks. + Appendix B.2 shows an example of a server response that comes + immediately after a client request. The example shows the flows of + blocks as the large messages require fragmentation. But server + responses can sometimes be delayed. According to section 5.2.2 of [RFC7252], a slow server can acknowledge the request and respond later with the requested resource - representation. - - In particular, A slow server can respond to a CSR request with an - empty ACK with code 0.00, before sending the certificate to the - server after a short delay. Consecutively, the server will need more - than one "Block2" blocks to respond. This situation is shown in - Figure 2 where a client sends an enrollment request that uses more - than one "Block1" blocks. The server uses an empty 0.00 ACK to - announce the response which will be provided later with 2.04 messages - containing "Block2" options. Having received the first 128 bytes in - the first "block2" block, the client asks for a block reduction to - 128 bytes in all following "block2" blocks, starting with the second - block (NUM=1). + representation. In particular, a slow server can respond to a enroll + request with an empty ACK with code 0.00, before sending the + certificate to the server after a short delay. Consecutively, the + server will need more than one "Block2" blocks to respond if the + certificate is large. This situation is shown in Figure 2 where a + client sends an enrollment request that uses more than one "Block1" + blocks. The server uses an empty 0.00 ACK to announce the response + which will be provided later with 2.04 messages containing "Block2" + options. Having received the first 128 bytes in the first "block2" + block, the client asks for a block reduction to 128 bytes in all + following "block2" blocks, starting with the second block (NUM=1). POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> <-- (ACK) (1:0/1/256) (2.31 Continue) POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR req} --> <-- (ACK) (1:1/1/256) (2.31 Continue) . . . POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR req} --> <-- (0.00 empty ACK) @@ -329,32 +326,27 @@ . . . POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) --> <-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp} Figure 2: EST-COAP enrolment with short wait If the server is very slow providing the response (say minutes, possible when a manual intervention is wanted), the server SHOULD - respond with an empty ACK containing response code 5.03 (Service + 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. - - In particular, when the server is not ready to return the certificate - after an enrolment request, the server responds with response code - 5.03 (Service Unavailable) including the Max-Age option. After a - delay of Max-Age, the client SHOULD send the identical CSR to the - server. As long as the server responds with response code 5.03 - (Service Unavailable), the client can resend the enrolment request - until the server responds with the certificate or the client abandons - for other reasons. + 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), + the client can resend the enrolment request until the server responds + with the certificate or the client abandons for other reasons. To demonstrate this situation, Figure 3 shows a client sending an enrolment request that will use more than one "Block1" block to send the CSR to the server. The server needs more than one "Block2" blocks to respond, but also needs to take a long delay (minutes) to provide the response. Consequently, the server will use a 5.03 ACK for the response. The client can be requested to wait multiple times for a period of Max-Age. Note that in the example below the server asks for a decrease in the block size when acknowledging the first Block2. @@ -902,20 +892,25 @@ explanations on the use of Block with DTLS and his support for the content-format specification. The authors would like to thank Esko Dijk and Michael Verschoor for the valuable discussions that helped in shaping the solution. They would also like to thank Peter Panburana for his feedback on technical details of the solution. Constructive comments were received from Benjamin Kaduk, Eliot Lear, Jim Schaad, Hannes Tschofenig, Julien Vermillard, and John Manuel. 12. Change Log + -04: + + Updated Delayed response section to reflect short and long delay + options. + -03: Removed observe and simplified long waits Repaired content-format specification -02: Added parameter discussion in section 8