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