draft-ietf-ace-coap-est-02.txt   draft-ietf-ace-coap-est-03.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 23, 2018 Cisco Systems Expires: December 27, 2018 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 21, 2018 June 25, 2018
EST over secure CoAP (EST-coaps) EST over secure CoAP (EST-coaps)
draft-ietf-ace-coap-est-02 draft-ietf-ace-coap-est-03
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 23, 2018. This Internet-Draft will expire on December 27, 2018.
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 31 skipping to change at page 2, line 31
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 Results . . . . . . . . . . . . . . . . . . . . . 7
4.5. Server-side Key Generation . . . . . . . . . . . . . . . 8 4.5. Server-side Key Generation . . . . . . . . . . . . . . . 9
4.6. Message fragmentation . . . . . . . . . . . . . . . . . . 9 4.6. Message fragmentation . . . . . . . . . . . . . . . . . . 10
4.7. Deployment limits . . . . . . . . . . . . . . . . . . . . 10 4.7. Deployment limits . . . . . . . . . . . . . . . . . . . . 11
5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 10 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 11
6. DTLS Transport Protocol . . . . . . . . . . . . . . . . . . . 11 6. DTLS Transport Protocol . . . . . . . . . . . . . . . . . . . 13
7. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 13 7. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 14
8. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 16 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 17
9.2. Resource Type registry . . . . . . . . . . . . . . . . . 17 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10.1. EST server considerations . . . . . . . . . . . . . . . 17 10.1. EST server considerations . . . . . . . . . . . . . . . 18
10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 18 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 23 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 24
A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 23 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.2. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 28 A.2. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 29
A.3. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 29 A.3. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 29
A.4. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 31 A.4. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. EST-coaps Block message examples . . . . . . . . . . 33 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
1. Introduction 1. Introduction
"Classical" Enrollment over Secure Transport (EST) [RFC7030] is used "Classical" Enrollment over Secure Transport (EST) [RFC7030] is used
for authenticated/authorized endpoint certificate enrollment (and for authenticated/authorized endpoint certificate enrollment (and
optionally key provisioning) through a Certificate Authority (CA) or optionally key provisioning) through a Certificate Authority (CA) or
Registration Authority (RA). EST messages run over HTTPS. Registration Authority (RA). EST messages run over HTTPS.
This document defines a new transport for EST based on the This document defines a new transport for EST based on the
Constrained Application Protocol (CoAP) since some Internet of Things Constrained Application Protocol (CoAP) since some Internet of Things
(IoT) devices use CoAP instead of HTTP. Therefore, this (IoT) devices use CoAP instead of HTTP. Therefore, this
specification utilizes DTLS [RFC6347], CoAP [RFC7252], and UDP specification utilizes DTLS [RFC6347], CoAP [RFC7252], and UDP
instead of TLS [RFC5246], HTTP [RFC7230] and TCP. instead of TLS [RFC5246], HTTP [RFC7230] and TCP.
EST messages may be relatively large and for this reason this EST messages may be relatively large and for this reason this
document also uses CoAP Block-Wise Transfer [RFC7959] to offer a document also uses CoAP Block-Wise Transfer [RFC7959] to offer a
fragmentation mechanism of EST messages at the CoAP layer. COAP fragmentation mechanism of EST messages at the CoAP layer.
Observe options [RFC7641] are also used to convey delayed EST
responses to clients.
This specification also profiles the use of EST to only support This specification also profiles the use of EST to only support
certificate-based client Authentication. HTTP Basic or Digest certificate-based client Authentication. HTTP Basic or Digest
authentication (as described in Section 3.2.3 of [RFC7030] are not authentication (as described in Section 3.2.3 of [RFC7030] are not
supported. supported.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 10 skipping to change at page 4, line 9
resource devices described in [RFC7925]. resource devices described in [RFC7925].
EST-coaps can transport certificates and private keys. Certificates EST-coaps can transport certificates and private keys. Certificates
are responses to (re-)enrollment requests or request for a trusted are responses to (re-)enrollment requests or request for a trusted
certificate list. Private keys can be transported as responses to a certificate list. Private keys can be transported as responses to a
request to a server-side keygeneration as described in section 4.4 of request to a server-side keygeneration as described in section 4.4 of
[RFC7030] and discussed in Section 4.5 of this document. [RFC7030] and discussed in Section 4.5 of this document.
As per [RFC7925] section 3.3 and section 4.4, the mandatory cipher As per [RFC7925] section 3.3 and section 4.4, the mandatory cipher
suite for DTLS in EST-coaps is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 suite for DTLS in EST-coaps is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
defined in [RFC7251], and the the curve secp256r1 MUST be supported defined in [RFC7251], and the curve secp256r1 MUST be supported
[RFC4492]; this curve is equivalent to the NIST P-256 curve. Crypto [RFC4492]; this curve is equivalent to the NIST P-256 curve. Crypto
agility is important, and the recommendations in [RFC7925] section agility is important, and the recommendations in [RFC7925] section
4.4 and any updates to RFC7925 concerning Curve25519 and other CFRG 4.4 and any updates to RFC7925 concerning Curve25519 and other CFRG
curves also applies. curves also applies.
DTLS1.2 implementations MUST use the Supported Elliptic Curves and DTLS1.2 implementations MUST use the Supported Elliptic Curves and
Supported Point Formats Extensions [RFC4492]. Uncompressed point Supported Point Formats Extensions [RFC4492]. Uncompressed point
format MUST also be supported. [RFC6090] can be used as summary of format MUST also be supported. [RFC6090] can be used as summary of
the ECC algorithms. DTLS 1.3 implementations differ from DTLS 1.2 the ECC algorithms. DTLS 1.3 implementations differ from DTLS 1.2
because they do not support point format negotiation in favor of a because they do not support point format negotiation in favor of a
skipping to change at page 5, line 8 skipping to change at page 5, line 8
EST-coaps uses CoAP to transfer EST messages, aided by Block-Wise EST-coaps uses CoAP to transfer EST messages, aided by Block-Wise
Transfer [RFC7959] to transport CoAP messages in blocks thus avoiding Transfer [RFC7959] to transport CoAP messages in blocks thus avoiding
(excessive) fragmentation of UDP datagrams. The use of "Block" for (excessive) fragmentation of UDP datagrams. The use of "Block" for
the transfer of larger EST messages is specified in Section 4.6. The the transfer of larger EST messages is specified in Section 4.6. The
Figure 1 below shows the layered EST-coaps architecture. Figure 1 below shows the layered EST-coaps architecture.
+------------------------------------------------+ +------------------------------------------------+
| EST request/response messages | | EST request/response messages |
+------------------------------------------------+ +------------------------------------------------+
| CoAP for message transfer and signaling | | CoAP for message transfer and signalling |
+------------------------------------------------+ +------------------------------------------------+
| DTLS for transport security | | DTLS for transport security |
+------------------------------------------------+ +------------------------------------------------+
| UDP for transport | | UDP for transport |
+------------------------------------------------+ +------------------------------------------------+
Figure 1: EST-coaps protocol layers Figure 1: EST-coaps protocol layers
The EST-coaps protocol design follows closely the EST design. The The EST-coaps protocol design follows closely the EST design. The
actions supported by EST-coaps are identified by their message types: actions supported by EST-coaps are identified by their message types:
skipping to change at page 7, line 13 skipping to change at page 7, line 13
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 Results
If the server is slow providing the response, she can respond with an Using the enroll request with CSR reponse, examples ae shown for a
empty ACK, sending the content later, according to [RFC7252], section server without delay, a short delay and a long delay.
5.2.2. If the response will be more than one packet (requring block
mode) then the client needs to send an empty ACK with code 0.00 for
the first block and acknowledge the rest of the blocks accordingly.
To demonstrate this situation below we show a client sending an
enrollment request that will use more than one Block1 blocks to send
the CSR to the server. The server on the other hand will need more
than one Block2 blocks to respond, but will need take some time to
provide the response. Thus the server will use a 0.00 ACK for the
response which will be provided when ready by using 2.04 messages and
Block2 options. Readers should note that the client asks for a
decrease in the block size when acknowledging the first Block2.
CON | POST 1:0/1/256 (enroll request with CSR) --> When the server can respond immediately, and multiple blocks need to
<-- ACK | 2.31 1:0/1/256 be sent, Appendix B.2 shows the corresponding exchange of blocks.
CON | POST 1:1/1/256 (enroll request with CSR)
<-- ACK | 2.31 1:1/1/256
CON | POST 1:2/0/256 (enroll request with CSR)
<-- ACK (code 0.00, no payload,
to signal delay in the response.
When ready, the server transfers
the response in Block2 blocks.)
CON | 2.04 1:2/0/256 & 2:0/1/128 (Certificate) -->
<-- ACK (code 0.00, no payload)
<-- CON | POST 2:1/0/128
ACK | 2.04 2:1/1/128 (Certificate) -->
<-- CON | POST 2:2/0/128
ACK | 2.04 2:2/0/128 (Certificate) -->
[EDNOTE: To update this. HTTP 202 Retry-After in EST needs an According to section 5.2.2 of [RFC7252], a slow server can
equivalent mechanism in EST-coaps. Observe seems like a candidate acknowledge the request and respond later with the requested resource
but after the HTTP 202 the client needs to do a new POST, not a GET, representation.
so Observe is not the best option. We could use 2.04 or a new 2.0x
with Max-Age to convey the EST Retry-After. ] It is possible that
responses are not always directly available by the server, and may
even require manual intervention to generate the certificate for the
server response. Delays of minutes to hours are possible. EST
requires the use of an HTTP 202 message with a Retry-After header by
the server which signals to the client to attempt the request in a
certain amount of time. In EST, each GET request MUST be accompanied
by the observe option. When the result is directly available, the
client receives the result and forgets about the observe as specified
in section 3.6 of [RFC7641]. When a POST response is delayed, the
POST returns a 2.01 (Created) response code, having put a value in
the Location-Path option. After reception of 2.01 the client does a
GET request with the observe option to the newly returned location.
Once the delayed result is notified by the server, the client forgets
about the observe.
Next to the observe option the server MUST specify the Max-Age option In particular, A slow server can respond to a CSR request with an
that indicates the maximum waiting time in minutes. 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).
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)
|
...... short delay before certificate is ready.......
|
<-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp}
(ACK) -->
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) -->
<-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp}
.
.
.
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
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.
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.
Figure 5 can be compared with Figure 3 to see the extra requests
after a Max-Age wait.
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} -->
<-- (ACK) (1:N1/0/256) (2:0/0/128) (5.03 Service Unavailable)
(Max-Age)
|
|
Client tries one or more times 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.04 Changed){Cert resp}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) -->
<-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp}
.
.
.
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) -->
<-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp}
Figure 3: EST-COAP enrolment with long wait
4.5. Server-side Key Generation 4.5. Server-side Key Generation
Constrained devices sometimes do not have the necessary hardware to Constrained devices sometimes do not have the necessary hardware to
generate statistically random numbers for private keys and DTLS generate statistically random numbers for private keys and DTLS
ephemeral keys. Past experience has shown that low-resource ephemeral keys. Past experience has shown that low-resource
endpoints sometimes generate numbers which could allow someone to endpoints sometimes generate numbers which could allow someone to
decrypt the communication or guess the private key and impersonate as decrypt the communication or guess the private key and impersonate as
the device. Studies have shown that the same keys are generated by the device. Studies have shown that the same keys are generated by
the same model devices deployed on-line. the same model devices deployed on-line.
skipping to change at page 13, line 21 skipping to change at page 14, line 43
use the same authenticated DTLS connection. Given that after a use the same authenticated DTLS connection. Given that after a
successful enrollment, it is more likely that a new EST transaction successful enrollment, it is more likely that a new EST transaction
will take place after a significant amount of time, the DTLS will take place after a significant amount of time, the DTLS
connections SHOULD only be kept alive for EST messages that are connections SHOULD only be kept alive for EST messages that are
relatively close to each other. In some cases, such as NAT relatively close to each other. In some cases, such as NAT
rebinding, keeping the state of a connection is not possible when rebinding, keeping the state of a connection is not possible when
devices sleep for extended periods of time. In such occasions, devices sleep for extended periods of time. In such occasions,
[I-D.rescorla-tls-dtls-connection-id] negotiates a connection ID that [I-D.rescorla-tls-dtls-connection-id] negotiates a connection ID that
can eliminate the need for new handshake and its additional cost. can eliminate the need for new handshake and its additional cost.
Support for Observe CoAP options [RFC7641] is compulsory. The
necessity of Observer for long delays (minutes - hours)is explained
in Section 4.4. Observe options could also be used by the server to
notify clients about a change in the cacerts or csr attributes
(resources) and might be an area of future work.
7. HTTPS-CoAPS Registrar 7. HTTPS-CoAPS Registrar
In real-world deployments, the EST server will not always reside In real-world deployments, the EST server will not always reside
within the CoAP boundary. The EST-server can exist outside the within the CoAP boundary. The EST-server can exist outside the
constrained network in a non-constrained network that supports TLS/ constrained network in a non-constrained network that supports TLS/
HTTP. In such environments EST-coaps is used by the client within HTTP. In such environments EST-coaps is used by the client within
the CoAP boundary and TLS is used to transport the EST messages the CoAP boundary and TLS is used to transport the EST messages
outside the CoAP boundary. A Registrar at the edge is required to outside the CoAP boundary. A Registrar at the edge is required to
operate between the CoAP environment and the external HTTP network. operate between the CoAP environment and the external HTTP network.
The EST coaps-to-HTTPS Registrar MUST terminate EST-coaps and The EST coaps-to-HTTPS Registrar MUST terminate EST-coaps and
authenticate the client downstream and initiate EST connections over authenticate the client downstream and initiate EST connections over
TLS upstream. TLS upstream.
The Registrar SHOULD authenticate the client downstream and it should The Registrar SHOULD authenticate the client downstream and it should
be authenticated by the EST server or CA upstream. The Registration be authenticated by the EST server or CA upstream. The Registration
Authority (re-)creates the secure connection from DTLS to TLS and Authority (re-)creates the secure connection from DTLS to TLS and
vice versa. A trust relationship SHOULD be pre-established between vice versa. A trust relationship SHOULD be pre-established between
the Registrar and the EST servers to be able to proxy these the Registrar and the EST servers to be able to proxy these
connections on behalf of various clients. connections on behalf of various clients.
skipping to change at page 15, line 34 skipping to change at page 16, line 50
THis section addresses transmission parameters described in sections THis section addresses transmission parameters described in sections
4.7 and 4.8 of the CoAP document [RFC7252]. 4.7 and 4.8 of the CoAP document [RFC7252].
ACK_TIMEOUT | 2 seconds | ACK_TIMEOUT | 2 seconds |
ACK_RANDOM_FACTOR | 1.5 | ACK_RANDOM_FACTOR | 1.5 |
MAX_RETRANSMIT | 4 | MAX_RETRANSMIT | 4 |
NSTART | 1 | NSTART | 1 |
DEFAULT_LEISURE | 5 seconds | DEFAULT_LEISURE | 5 seconds |
PROBING_RATE | 1 byte/second | PROBING_RATE | 1 byte/second |
Figure 2: EST-COAP protocol parameters Figure 4: EST-COAP protocol parameters
EST does not impose any unique parameters that affect the CoAP EST does not impose any unique parameters that affect the CoAP
parameters in Table 2 and 3 in the CoAP draft but the ones in CoAP parameters in Table 2 and 3 in the CoAP draft but the ones in CoAP
could be affecting EST. For example, the processing delay of CAs could be affecting EST. For example, the processing delay of CAs
could be less then 2s, but in this case they should send a CoAP ACK could be less then 2s, but in this case they should send a CoAP ACK
every 2s while processing. every 2s while processing.
The main recommendation, based on experiments using Nexus Certificate The main recommendation, based on experiments using Nexus Certificate
Manager with Californium for CoAP support, communicating with a Manager with Californium for CoAP support, communicating with a
ContikiOS and tinyDTLS based client, from RISE SICS, is to start with ContikiOS and tinyDTLS based client, from RISE SICS, is to start with
skipping to change at page 17, line 24 skipping to change at page 18, line 24
| application/pkcs7-mime; | - | TBD | [RFC5751] [RFC5273] | | application/pkcs7-mime; | - | TBD | [RFC5751] [RFC5273] |
| smime-type=CMC-request | | 3 | | | smime-type=CMC-request | | 3 | |
| application/pkcs7-mime; | - | TBD | [RFC5751] [RFC5273] | | application/pkcs7-mime; | - | TBD | [RFC5751] [RFC5273] |
| smime-type=CMC-response | | 4 | | | smime-type=CMC-response | | 4 | |
| application/pkcs8 | - | TBD | [RFC5751] [RFC5958] | | application/pkcs8 | - | TBD | [RFC5751] [RFC5958] |
| | | 5 | | | | | 5 | |
| application/csrattrs | - | TBD | [RFC7030] [RFC7231] | | application/csrattrs | - | TBD | [RFC7030] [RFC7231] |
| | | 6 | | | | | 6 | |
| application/pkcs10 | - | TBD | [RFC5751] [RFC5967] | | application/pkcs10 | - | TBD | [RFC5751] [RFC5967] |
| | | 7 | | | | | 7 | |
| application/multict | - | TBD | [I-D.fossati-core-multip | | application/multipart- | - | TBD | [I-D.fossati-core-multip |
| | | 8 | art-ct] | | core | | 8 | art-ct] |
+-------------------------+--------+-----+--------------------------+ +-------------------------+--------+-----+--------------------------+
Table 2: New CoAP Content-Formats Table 2: New CoAP Content-Formats
9.2. Resource Type registry 9.2. Resource Type registry
Additions to the sub-registry "CoAP Resource Type", within the "CoRE Additions to the sub-registry "CoAP Resource Type", within the "CoRE
Parameters" registry are needed for a new resource type. Parameters" registry are needed for a new resource type.
o rt="ace.est" needs registration with IANA. o rt="ace.est" needs registration with IANA.
skipping to change at page 19, 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
-03:
Removed observe and simplified long waits
Repaired content-format specification
-02: -02:
Added paremeter discussion in section 8 Added parameter discussion in section 8
Concluded content-format specification using multipart-ct draft Concluded content-format specification using multipart-ct draft
examples updated examples updated
-01: -01:
Editorials done. Editorials done.
Redefinition of proxy to Registrar in Section 7. Explained better Redefinition of proxy to Registrar in Section 7. Explained better
skipping to change at page 23, line 21 skipping to change at page 24, line 30
CCM Elliptic Curve Cryptography (ECC) Cipher Suites for CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
<https://www.rfc-editor.org/info/rfc7251>. <https://www.rfc-editor.org/info/rfc7251>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925, Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016, DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
Appendix A. EST messages to EST-coaps Appendix A. EST messages to EST-coaps
This section takes all examples from Appendix A of [RFC7030], changes This section takes all examples from Appendix A of [RFC7030], changes
the payload from Base64 to binary and replaces the http headers by the payload from Base64 to binary and replaces the http headers by
skipping to change at page 24, line 19 skipping to change at page 25, line 26
Ver = 1 Ver = 1
T = 0 (CON) T = 0 (CON)
Code = 0x01 (0.01 is GET) Code = 0x01 (0.01 is GET)
Token = 0x9a (client generated) Token = 0x9a (client generated)
Options Options
Option1 (Uri-Host) [optional] Option1 (Uri-Host) [optional]
Option Delta = 0x3 (option nr = 3) Option Delta = 0x3 (option nr = 3)
Option Length = 0x9 Option Length = 0x9
Option Value = 192.0.2.1 Option Value = 192.0.2.1
Option2 (Observe) Option2 (Uri-Port) [optional]
Option Delta = 0x1 (option nr = 3+3=6) Option Delta = 0x4 (option nr = 3+4=7)
Option Length = 0x1
Option Value = 0 (register)
Option3 (Uri-Port) [optional]
Option Delta = 0x1 (option nr = 6+1=7)
Option Length = 0x4 Option Length = 0x4
Option Value = 8085 Option Value = 8085
Option4 (Uri-Path) Option3 (Uri-Path)
Option Delta = 0x4 (option nr = 7+4= 11) Option Delta = 0x4 (option nr = 7+4= 11)
Option Length = 0x5 Option Length = 0x5
Option Value = "est" Option Value = "est"
Option5 (Uri-Path) Option4 (Uri-Path)
Option Delta = 0x0 (option nr = 11+0= 11) Option Delta = 0x0 (option nr = 11+0= 11)
Option Length = 0x6 Option Length = 0x6
Option Value = "crts" Option Value = "crts"
Option6 (Max-Age) Option5 (Max-Age)
Option Delta = 0x3 (option nr = 11+3= 14) Option Delta = 0x3 (option nr = 11+3= 14)
Option Length = 0x1 Option Length = 0x1
Option Value = 0x1 (1 minute) Option Value = 0x1 (1 minute)
Payload = [Empty] Payload = [Empty]
A 2.05 Content response with a cert in EST-coaps will then be: A 2.05 Content response with a cert in EST-coaps will then be:
2.05 Content (Content-Format: TBD2) 2.05 Content (Content-Format: TBD2)
{payload} {payload}
with CoAP fields with CoAP fields
Ver = 1 Ver = 1
T = 2 (ACK) T = 2 (ACK)
Code = 0x45 (2.05 Content) Code = 0x45 (2.05 Content)
Token = 0x9a (copied by server) Token = 0x9a (copied by server)
Options Options
Option1 (Observe) Option1 (Content-Format)
Option Delta = 0x6 (option nr =6) Option Delta = 0xC (option nr =12)
Option Length = 0x1
Option Value = 12 ( 12 > 0)
Option2 (Content-Format)
Option Delta = 0xC (option nr = 6+6 =12)
Option Length = 0x2 Option Length = 0x2
Option Value = TBD2 (defined in this document) Option Value = TBD2 (defined in this document)
Payload = Payload =
h'30233906092a6206734107028c2a3023260201013100300b06092a6206734107018 h'30233906092a6206734107028c2a3023260201013100300b06092a6206734107018
c0c3020bb302063c20102020900a61e75193b7acc0d06092a620673410105050030 c0c3020bb302063c20102020900a61e75193b7acc0d06092a620673410105050030
1b31193017060355040313106573744578616d706c654341204f774f301e170d313 1b31193017060355040313106573744578616d706c654341204f774f301e170d313
3303530393033353333315a170d3134303530393033353333315a301b3119301706 3303530393033353333315a170d3134303530393033353333315a301b3119301706
0355040313106573744578616d706c654341204f774f302062300d06092a6206734 0355040313106573744578616d706c654341204f774f302062300d06092a6206734
10101050003204f0030204a022041003a923a2968bae4aae136ca4e2512c5200680 10101050003204f0030204a022041003a923a2968bae4aae136ca4e2512c5200680
skipping to change at page 28, line 30 skipping to change at page 29, line 29
1F10530030101FC1D0603551D0E04160414112966E304761732FBFE6A2C823C30 1F10530030101FC1D0603551D0E04160414112966E304761732FBFE6A2C823C30
0E0603551D0F0101F10403020106300D06092A620673410105050003204100423 0E0603551D0F0101F10403020106300D06092A620673410105050003204100423
F06D4B760F4B42744A279035571696F272A0060F1325A40898509601AD14004F6 F06D4B760F4B42744A279035571696F272A0060F1325A40898509601AD14004F6
52DB6312A1475C4D7CD50F4B269035585D7856C5337765A66B38462D5BDAA7778 52DB6312A1475C4D7CD50F4B269035585D7856C5337765A66B38462D5BDAA7778
AAB24BBE2815E37722CD10E7166C50E75AB75A1271324460211991E7445A2960F AAB24BBE2815E37722CD10E7166C50E75AB75A1271324460211991E7445A2960F
47351A1A62925334119794B90E320BC730D6C1BEE496E7AC125CE9A1ECA595A3A 47351A1A62925334119794B90E320BC730D6C1BEE496E7AC125CE9A1ECA595A3A
4C54A865E6B623C9247BFD0A7C19B56077392555C955E233642BEC643AE37C166 4C54A865E6B623C9247BFD0A7C19B56077392555C955E233642BEC643AE37C166
C5E221D797AEA3748F0391C8D692A5CF9BB71F6D0E37984D6FA673A30D0C00634 C5E221D797AEA3748F0391C8D692A5CF9BB71F6D0E37984D6FA673A30D0C00634
3116F58403100 3116F58403100
After reception of the 2.05 response, the client can forget the
observe.
A.2. csrattrs A.2. csrattrs
In the following valid /csrattrs exchange, the EST-coaps client In the following valid /csrattrs exchange, the EST-coaps client
authenticates itself with a certificate issued by the connected CA. authenticates itself with a certificate issued by the connected CA.
The initial DTLS handshake is identical to the enrollment example. The initial DTLS handshake is identical to the enrollment example.
The IPv6 CoAP GET request looks like: The IPv6 CoAP GET request looks like:
REQ: REQ:
GET coaps://[2001:db8::2:1]:61616/est/att GET coaps://[2001:db8::2:1]:61616/est/att
(Content-Format: TBD6)(observe =0)(Max-Age =1) (Content-Format: TBD6)
A 2.05 Content response contains attributes which are relevant for A 2.05 Content response contains attributes which are relevant for
the authenticated client. In this example, the EST-coaps server the authenticated client. In this example, the EST-coaps server
returns two attributes that the client can ignore when they are returns two attributes that the client can ignore when they are
unknown to him. unknown to him.
A.3. enroll / reenroll A.3. enroll / reenroll
During the Enroll/Reenroll exchange, the EST-coaps client uses a CSR During the Enroll/Reenroll exchange, the EST-coaps client uses a CSR
(Content-Format TBD7) request in the POST request payload. (Content-Format TBD7) request in the POST request payload.
After verification of the CSR by the server, a 2.05 Content response After verification of the CSR by the server, a 2.05 Content response
with the issued certificate will be returned to the client. As with the issued certificate will be returned to the client. As
described in Section 4.4, if the server is not able to provide a described in Section 4.4, if the server is not able to provide a
response, then it ACKs the GET (with no payload), and the payload response immediately, it sends an empty ACK with response code 5.03
will be sent later as part of the OBSERVE processing. (Service Unavailabel) and the Max-Age option. See Figure 3 for an
example exchange.
[EDNOTE: When redoing this example, given that proof of possession [EDNOTE: When redoing this example, given that proof of possession
(POP) is also used, make sure it is obvious that the (POP) is also used, make sure it is obvious that the
ChallengePassword attribute in the CSR is valid HMAC output. HMAC- ChallengePassword attribute in the CSR is valid HMAC output. HMAC-
REAL.] REAL.]
POST [2001:db8::2:1]:61616/est/sen POST [2001:db8::2:1]:61616/est/sen
(token 0x45) (token 0x45)
(Content-Format: TBD7)(observe 0) (Content-Format: TBD7)
h'30208530206d020100301f311d301b0603550403131464656d6f7374657034203 h'30208530206d020100301f311d301b0603550403131464656d6f7374657034203
1333638313431333532302062300d06092a620673410101050003204f0030204a 1333638313431333532302062300d06092a620673410101050003204f0030204a
022041005d9f4dffd3c5949f646a9584367778560950b355c35b8e34726dd3764 022041005d9f4dffd3c5949f646a9584367778560950b355c35b8e34726dd3764
54231734795b4c09b9c6d75d408311307a81f7adef7f5d241f7d5be85620c5d44 54231734795b4c09b9c6d75d408311307a81f7adef7f5d241f7d5be85620c5d44
38bbb4242cf215c167f2ccf36c364ea2618a62f0536576369d6304e6a96877224 38bbb4242cf215c167f2ccf36c364ea2618a62f0536576369d6304e6a96877224
7d86824f079faac7a6f694cfda5b84c42087dc062d462190c525813f210a036a7 7d86824f079faac7a6f694cfda5b84c42087dc062d462190c525813f210a036a7
37b4f30d8891f4b75559fb72752453146332d51c937557716ccec624f5125c3a4 37b4f30d8891f4b75559fb72752453146332d51c937557716ccec624f5125c3a4
447ad3115020048113fef54ad554ee88af09a2583aac9024075113db4990b1786 447ad3115020048113fef54ad554ee88af09a2583aac9024075113db4990b1786
b871691e0f02030100018701f06092a620673410907311213102b72724369722f b871691e0f02030100018701f06092a620673410907311213102b72724369722f
372b45597535305434300d06092a620673410105050003204100441b40177a3a6 372b45597535305434300d06092a620673410105050003204100441b40177a3a6
5501487735a8ad5d3827a4eaa867013920e2afcda87aa81733c7c0353be47e1bf 5501487735a8ad5d3827a4eaa867013920e2afcda87aa81733c7c0353be47e1bf
a7cda5176e7ccc6be22ae03498588d5f2de3b143f2b1a6175ec544e8e7625af6b a7cda5176e7ccc6be22ae03498588d5f2de3b143f2b1a6175ec544e8e7625af6b
836fd4416894c2e55ea99c6606f69075d6d53475d410729aa6d806afbb9986caf 836fd4416894c2e55ea99c6606f69075d6d53475d410729aa6d806afbb9986caf
7b844b5b3e4545f19071865ada007060cad6db26a592d4a7bda7d586b68110962 7b844b5b3e4545f19071865ada007060cad6db26a592d4a7bda7d586b68110962
17071103407553155cddc75481e272b5ed553a8593fb7e25100a6f7605085dab4 17071103407553155cddc75481e272b5ed553a8593fb7e25100a6f7605085dab4
fc7e0731f0e7fe305703791362d5157e92e6b5c2e3edbcadb40' fc7e0731f0e7fe305703791362d5157e92e6b5c2e3edbcadb40'
RET: RET:
(Content-Format: TBD2)(token =0x45)(observe =12) (Content-Format: TBD2)(token =0x45)
2.01 Created 2.01 Created
h'3020f806092a62067341070283293020e50201013100300b06092a62067341070 h'3020f806092a62067341070283293020e50201013100300b06092a62067341070
1830b3020c730206fc20102020115300d06092a6206734101050500301b311930 1830b3020c730206fc20102020115300d06092a6206734101050500301b311930
17060355040313106573744578616d706c654341204e774e301e170d313330353 17060355040313106573744578616d706c654341204e774e301e170d313330353
0393233313535335a170d3134303530393233313535335a301f311d301b060355 0393233313535335a170d3134303530393233313535335a301f311d301b060355
0403131464656d6f73746570342031333638313431333532302062300d06092a6 0403131464656d6f73746570342031333638313431333532302062300d06092a6
20673410101050003204f0030204a022041005d9f4dffd3c5949f646a95843677 20673410101050003204f0030204a022041005d9f4dffd3c5949f646a95843677
78560950b355c35b8e34726dd376454231734795b4c09b9c6d75d408311307a81 78560950b355c35b8e34726dd376454231734795b4c09b9c6d75d408311307a81
f7adef7f5d241f7d5be85620c5d4438bbb4242cf215c167f2ccf36c364ea2618a f7adef7f5d241f7d5be85620c5d4438bbb4242cf215c167f2ccf36c364ea2618a
62f0536576369d6304e6a968772247d86824f079faac7a6f694cfda5b84c42087 62f0536576369d6304e6a968772247d86824f079faac7a6f694cfda5b84c42087
skipping to change at page 30, line 49 skipping to change at page 32, line 5
1d0f0101f104030204c1d0603551d0e04160414e81d0788aa2710304c5ecd4d1e 1d0f0101f104030204c1d0603551d0e04160414e81d0788aa2710304c5ecd4d1e
065701f0603551d230418301653112966e304761732fbfe6a2c823c300d06092a 065701f0603551d230418301653112966e304761732fbfe6a2c823c300d06092a
6206734101050500032041002910d86f2ffeeb914c046816871de601567d291b4 6206734101050500032041002910d86f2ffeeb914c046816871de601567d291b4
3fabee0f0e8ff81cea27302a7133e20e9d04029866a8963c7d14e26fbe8a0ab1b 3fabee0f0e8ff81cea27302a7133e20e9d04029866a8963c7d14e26fbe8a0ab1b
77fbb1214bbcdc906fbc381137ec1de685f79406c3e416b8d82f97174bc691637 77fbb1214bbcdc906fbc381137ec1de685f79406c3e416b8d82f97174bc691637
5a4e1c4bf744c7572b4b2c6bade9fb35da786392ee0d95e3970542565f3886ad6 5a4e1c4bf744c7572b4b2c6bade9fb35da786392ee0d95e3970542565f3886ad6
7746d1b12484bb02616e63302dc371dc6006e431fb7c457598dd204b367b0b3d3 7746d1b12484bb02616e63302dc371dc6006e431fb7c457598dd204b367b0b3d3
258760a303f1102db26327f929b7c5a60173e1799491b69150248756026b80553 258760a303f1102db26327f929b7c5a60173e1799491b69150248756026b80553
171e4733ad3d13c0103100' 171e4733ad3d13c0103100'
After reception of the 2.01 response the client can forget the
observe registration
The same example when delays occur (omitting the payloads in the
examples) has a different behavior. The response to the POST is an
empty payload with response code 2.01 (Created) that also returns the
resource to query. The client issues a GET with an observe and a new
token value, and waits for the notification after possibly receiving
an empty payload first.
POST [2001:db8::2:1]:61616/est/sen
(token 0x45)(observe = 0)
(Content-Format: TBD7)(Max-Age=120)
[payload]
RET:
(token =0x45)(observe =12)(Location-Path=/est/1245)
2.01 Created
[empty payload]
GET [2001:db8::2:1]:61616/est/1245
(token 0x53)
(observe =0)(Max-Age=120)
RET:
(token =0x53)(observe = 5)
2.01 Created
[empty payload]
RET:
(token =0x53)(observe = 6)
(Content-Format: TBD2)
2.04 Changed
[payload]
A.4. serverkeygen A.4. serverkeygen
During this valid /serverkeygen exchange, the EST-coaps client During this valid /serverkeygen exchange, the EST-coaps client
authenticates itself using the certificate provided by the connected authenticates itself using the certificate provided by the connected
CA. CA.
The initial DTLS handshake is identical to the enrollment example. The initial DTLS handshake is identical to the enrollment example.
The CoAP GET request looks like: The CoAP GET request looks like:
[EDNOTE: same comment as HMAC-REAL above applies.] [EDNOTE: same comment as HMAC-REAL above applies.]
skipping to change at page 32, line 4 skipping to change at page 32, line 20
The initial DTLS handshake is identical to the enrollment example. The initial DTLS handshake is identical to the enrollment example.
The CoAP GET request looks like: The CoAP GET request looks like:
[EDNOTE: same comment as HMAC-REAL above applies.] [EDNOTE: same comment as HMAC-REAL above applies.]
[EDNOTE: Suggestion to have only one example with complete encrypted [EDNOTE: Suggestion to have only one example with complete encrypted
payload (the short one) and point out the different fields. Update payload (the short one) and point out the different fields. Update
this example according to the agreed upon solution from Section 4.5. this example according to the agreed upon solution from Section 4.5.
] ]
POST coaps://192.0.2.1:8085/est/skg POST coaps://192.0.2.1:8085/est/skg
(token 0xa5)(observe = 0) (token 0xa5)
(Content-Format: TBD7)(Max-Age=120) (Content-Format: TBD7)(Max-Age=120)
h'302081302069020100305b313e303c060355040313357365727665724b6579476 h'302081302069020100305b313e303c060355040313357365727665724b6579476
56e2072657120627920636c69656e7420696e2064656d6f207374657020313220 56e2072657120627920636c69656e7420696e2064656d6f207374657020313220
3133363831343139353531193017060355040513105049443a576964676574205 3133363831343139353531193017060355040513105049443a576964676574205
34e3a3130302062300d06092a620673410101050003204f0030204a02204100f4 34e3a3130302062300d06092a620673410101050003204f0030204a02204100f4
dfa6c03f7f2766b23776c333d2c0f9d1a7a6ee36d01499bbe6f075d1e38a57e98 dfa6c03f7f2766b23776c333d2c0f9d1a7a6ee36d01499bbe6f075d1e38a57e98
ecc197f51b75228454b7f19652332de5e52e4a974c6ae34e1df80b33f15f47d3b ecc197f51b75228454b7f19652332de5e52e4a974c6ae34e1df80b33f15f47d3b
cbf76116bb0e4d3e04a9651218a476a13fc186c2a255e4065ff7c271cff104e47 cbf76116bb0e4d3e04a9651218a476a13fc186c2a255e4065ff7c271cff104e47
31fad53c22b21a1e5138bf9ad0187314ac39445949a48805392390e78c7659621 31fad53c22b21a1e5138bf9ad0187314ac39445949a48805392390e78c7659621
skipping to change at page 32, line 29 skipping to change at page 32, line 46
4447672300d06092a620673410105050003204100472d11007e5a2b2c2023d47a 4447672300d06092a620673410105050003204100472d11007e5a2b2c2023d47a
6d71d046c307701d8ebc9e47272713378390b4ee321462a3dbe54579f5a514f6f 6d71d046c307701d8ebc9e47272713378390b4ee321462a3dbe54579f5a514f6f
4050af497f428189b63655d03a194ef729f101743e5d03fbc6ae1e84486d1300a 4050af497f428189b63655d03a194ef729f101743e5d03fbc6ae1e84486d1300a
f9288724381909188c851fa9a5059802eb64449f2a3c9e441353d136768da27ff f9288724381909188c851fa9a5059802eb64449f2a3c9e441353d136768da27ff
4f277651d676a6a7e51931b08f56135a2230891fd184960e1313e7a1a9139ed19 4f277651d676a6a7e51931b08f56135a2230891fd184960e1313e7a1a9139ed19
28196867079a456cd2266cb754a45151b7b1b939e381be333fea61580fe5d25bf 28196867079a456cd2266cb754a45151b7b1b939e381be333fea61580fe5d25bf
4823dbd2d6a98445b46305c10637e202856611' 4823dbd2d6a98445b46305c10637e202856611'
RET: RET:
2.01 Content (Content-Format: TBD8) 2.01 Content (Content-Format: TBD8)
(observe = 5)(token=0xa5) (token=0xa5)
[TBD5, [TBD5,
h'30213e020100300d06092a6206734101010500042128302124020100022041003 h'30213e020100300d06092a6206734101010500042128302124020100022041003
c0bc2748f2003e3e8ea15f746f2a71e83f585412b92cf6f8e64de02e056153274 c0bc2748f2003e3e8ea15f746f2a71e83f585412b92cf6f8e64de02e056153274
dd01c95dd9cff3112aa141774ab655c3d56359c3b3df055294692ed848e7e30a1 dd01c95dd9cff3112aa141774ab655c3d56359c3b3df055294692ed848e7e30a1
1bf14e47e0693d93017022b4cdb3e6d40325356152b213c8b535851e681a7074c 1bf14e47e0693d93017022b4cdb3e6d40325356152b213c8b535851e681a7074c
0c6d2b60e7c32fc0336b28e743eba4e5921074d47195d3c05e43c527526e692d5 0c6d2b60e7c32fc0336b28e743eba4e5921074d47195d3c05e43c527526e692d5
45e562578d2d4b5f2191bff89d3eef0222764a2674637a1f99257216647df6704 45e562578d2d4b5f2191bff89d3eef0222764a2674637a1f99257216647df6704
efec5adbf54dab24231844eb595875795000e673dd6862310a146ad7e31083010 efec5adbf54dab24231844eb595875795000e673dd6862310a146ad7e31083010
001022041004e6b3f78b7791d6377f33117c17844531c81111fb8000282816264 001022041004e6b3f78b7791d6377f33117c17844531c81111fb8000282816264
skipping to change at page 35, line 14 skipping to change at page 35, line 32
Ver = 1 Ver = 1
T = 0 (CON) T = 0 (CON)
Code = 0x01 (0.1 GET) Code = 0x01 (0.1 GET)
Token = 0x9a (client generated) Token = 0x9a (client generated)
Options Options
Option1 (Uri-Host) [optional] Option1 (Uri-Host) [optional]
Option Delta = 0x3 (option nr = 3) Option Delta = 0x3 (option nr = 3)
Option Length = 0x9 Option Length = 0x9
Option Value = 192.0.2.1 Option Value = 192.0.2.1
Option2 (Observe) Option2 (Uri-Port) [optional]
Option Delta = 0x3 (option nr = 3+3=6)
Option Length = 0x1
Option Value = 0 (register)
Option3 (Uri-Port) [optional]
Option Delta = 0x4 (option nr = 3+4=7) Option Delta = 0x4 (option nr = 3+4=7)
Option Length = 0x4 Option Length = 0x4
Option Value = 8085 Option Value = 8085
Option4 (Uri-Path) Option3 (Uri-Path)
Option Delta = 0x4 (option nr = 7+4=11) Option Delta = 0x4 (option nr = 7+4=11)
Option Length = 0x5 Option Length = 0x5
Option Value = "est" Option Value = "est"
Option5 (Uri-Path) Option4 (Uri-Path)
Option Delta = 0x0 (option nr = 11+0=11) Option Delta = 0x0 (option nr = 11+0=11)
Option Length = 0x6 Option Length = 0x6
Option Value = "crts" Option Value = "crts"
Option6 (Max-Age)
Option Delta = 0x3 (option nr = 11+3=14)
Option Length = 0x1
Option Value = 0x1 ( 1 minute)
Payload = [Empty] Payload = [Empty]
The header of the first response looks like: The header of the first response looks like:
Ver = 1 Ver = 1
T = 2 (ACK) T = 2 (ACK)
Code = 0x45 (2.05 Content) Code = 0x45 (2.05 Content)
Token = 0x9a (copied by server) Token = 0x9a (copied by server)
Options Options
Option1 (Observe) Option1 (Content-Format)
Option Delta = 0x6 (option nr=6) Option Delta = 0xC (option nr =12)
Option Length = 0x1
Option Value = 12 (12 > 0)
Option2 (Content-Format)
Option Delta = 0xC (option nr =6+6=12)
Option Length = 0x2 Option Length = 0x2
Option Value = TBD2 Option Value = TBD2
Option2 (Block2) Option2 (Block2)
Option Delta = 0xB (option 23 = 12 + 11) Option Delta = 0xB (option 23 = 12 + 11)
Option Length = 0x1 Option Length = 0x1
Option Value = 0x0A (block number = 0, M=1, SZX=2) Option Value = 0x0A (block number = 0, M=1, SZX=2)
Payload = Payload =
h'30233906092a6206734107028c2a3023260201013100300b06092a6206734107018 h'30233906092a6206734107028c2a3023260201013100300b06092a6206734107018
c0c3020bb302063c20102020900a61e75193b7acc0d06092a6206734101' c0c3020bb302063c20102020900a61e75193b7acc0d06092a6206734101'
The second Block2: The second Block2:
Ver = 1 Ver = 1
T = 2 (means ACK) T = 2 (means ACK)
Code = 0x45 (2.05 Content) Code = 0x45 (2.05 Content)
Token = 0x9a (copied by server) Token = 0x9a (copied by server)
Options Options
Option1 (Observe) Option1 (Content-Format)
Option Delta = 0x6 (option nr=6) Option Delta = 0xC (option nr =12)
Option Length = 0x1
Option Value = 16 (16 > 12)
Option2 (Content-Format)
Option Delta = 0xC (option nr =6+6=12)
Option Length = 0x2 Option Length = 0x2
Option Value = TBD2 Option Value = TBD2
Option2 (Block2) Option2 (Block2)
Option Delta = 0xB (option 23 = 12 + 11) Option Delta = 0xB (option 23 = 12 + 11)
Option Length = 0x1 Option Length = 0x1
Option Value = 0x1A (block number = 1, M=1, SZX=2) Option Value = 0x1A (block number = 1, M=1, SZX=2)
Payload = Payload =
h'05050030 h'05050030
1b31193017060355040313106573744578616d706c654341204f774f301e170d313 1b31193017060355040313106573744578616d706c654341204f774f301e170d313
3303530393033353333315a170d3134303530393033353333315a' 3303530393033353333315a170d3134303530393033353333315a'
The 40th and final Block2: The 40th and final Block2:
Ver = 1 Ver = 1
T = 2 (means ACK) T = 2 (means ACK)
Code = 0x45 (2.05 Content) Code = 0x45 (2.05 Content)
Token = 0x9a (copied by server) Token = 0x9a (copied by server)
Options Options
Option1 (Observe) Option1 (Content-Format)
Option Delta = 0x6 (option nr=6) Option Delta = 0xC (option nr =12)
Option Length = 0x1
Option Value = 55 (55 > 12)
Option2 (Content-Format)
Option Delta = 0xC (option nr =6+6=12)
Option Length = 0x2 Option Length = 0x2
Option Value = TBD2 Option Value = TBD2
Option2 (Block2) Option2 (Block2)
Option Delta = 0xB (option 23 = 12 + 11) Option Delta = 0xB (option 23 = 12 + 11)
Option Length = 0x2 Option Length = 0x2
Option Value = 0x272 (block number = 39, M=0, SZX=2) Option Value = 0x272 (block number = 39, M=0, SZX=2)
Payload = h'73a30d0c006343116f58403100' Payload = h'73a30d0c006343116f58403100'
B.2. enroll block example B.2. enroll block example
skipping to change at page 38, line 13 skipping to change at page 38, line 13
payload is shown within curly brackets. payload is shown within curly brackets.
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} -->
<-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed)(Cert resp} <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) -->
<-- (ACK) (2:1/1/256) (2.04 Changed) (Cert resp} <-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp}
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->
<-- (ACK) (2:N2/0/256) (2.04 Changed) (Cert resp} <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp}
Figure 5: EST-COAP enrolment with multiple blocks
N1+1 blocks have been transferred from client to server and N2+1 N1+1 blocks have been transferred from client to server and N2+1
blocks have been transferred from server to client. blocks have been transferred from server to client.
Authors' Addresses Authors' Addresses
Peter van der Stok Peter van der Stok
Consultant Consultant
Email: consultancy@vanderstok.org Email: consultancy@vanderstok.org
 End of changes. 44 change blocks. 
186 lines changed or deleted 167 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/