draft-ietf-ace-coap-est-09.txt   draft-ietf-ace-coap-est-10.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: August 31, 2019 Cisco Systems Expires: September 9, 2019 Cisco Systems
M. Richardson M. Richardson
SSW SSW
S. Raza S. Raza
RISE SICS RISE SICS
February 27, 2019 March 8, 2019
EST over secure CoAP (EST-coaps) EST over secure CoAP (EST-coaps)
draft-ietf-ace-coap-est-09 draft-ietf-ace-coap-est-10
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 constrained devices to use secure CoAP (EST-coaps), which allows constrained devices to use
existing EST functionality for provisioning certificates. existing EST functionality for provisioning certificates.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 August 31, 2019. This Internet-Draft will expire on September 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 6 4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 7
5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 9 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 9
5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 11 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12
5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12
5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13
5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14
5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 14 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 15
5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 15 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 16
5.8. Server-side Key Generation . . . . . . . . . . . . . . . 17 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 18
6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19
7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Deployment limitations . . . . . . . . . . . . . . . . . . . 21 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 21 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 22
9.2. Resource Type registry . . . . . . . . . . . . . . . . . 22 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. EST server considerations . . . . . . . . . . . . . . . 23 10.1. EST server considerations . . . . . . . . . . . . . . . 23
10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 24 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 25
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 26 13.1. Normative References . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30
A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 32 A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 32
A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 34 A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 34
A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 36 A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. EST-coaps Block message examples . . . . . . . . . . 37 Appendix B. EST-coaps Block message examples . . . . . . . . . . 37
B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 37 B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 41 B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 41
Appendix C. Message content breakdown . . . . . . . . . . . . . 42 Appendix C. Message content breakdown . . . . . . . . . . . . . 42
C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42 C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42
C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44
C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Change Log 1. Change Log
EDNOTE: Remove this section before publication EDNOTE: Remove this section before publication
-10
Addressed WGLC comments
More consistent request format in the examples.
Explained root resource difference when there is resource
discovery
Clarified when the client is supposed to do discovery
Fixed nits and minor Option length inaccurracies in the examples.
-09 -09
WGLC comments taken into account WGLC comments taken into account
consensus about discovery of content-format consensus about discovery of content-format
added additional path for content-format selection added additional path for content-format selection
merged DTLS sections merged DTLS sections
skipping to change at page 9, line 39 skipping to change at page 10, line 7
o Server-side key generation messages to provide a private client o Server-side key generation messages to provide a private client
identity key when the client choses so. identity key when the client choses so.
5.1. Discovery and URIs 5.1. Discovery and URIs
EST-coaps is targeted for low-resource networks with small packets. EST-coaps is targeted for low-resource networks with small packets.
Saving header space is important and short EST-coaps URIs are Saving header space is important and short EST-coaps URIs are
specified in this document. These URIs are shorter than the ones in specified in this document. These URIs are shorter than the ones in
[RFC7030]. Two example EST-coaps resource path names are: [RFC7030]. Two example EST-coaps resource path names are:
coaps://est-coaps.example.org:<port>/.well-known/est/<short-est> coaps://example.com:<port>/.well-known/est/<short-est>
coaps://est-coaps.example.org:<port>/.well-known/est/ coaps://example.com:<port>/.well-known/est/
ArbitraryLabel/<short-est> ArbitraryLabel/<short-est>
The short-est strings are defined in Table 1. The ArbitraryLabel The short-est strings are defined in Table 1. Arbitrary Labels are
path-segment, if used, SHOULD be of the shortest length possible usually defined and used by EST CAs in order to route client requests
(Sections 3.1 and 3.2.2 of [RFC7030]. Arbitrary Labels are usually to the appropriate certificate profile. Implementers should consider
defined and used by EST CAs in order to route client requests to the using short labels to minimize transmission overhead.
appropriate certificate profile.
The EST-coaps server URIs, obtained through discovery of the EST- The EST-coaps server URIs, obtained through discovery of the EST-
coaps root resource(s) as shown below, are of the form: coaps resource(s) as shown below, are of the form:
coaps://est-coaps.example.org:<port>/<root-resource>/<short-est> coaps://example.com:<port>/<root-resource>/<short-est>
coaps://est-coaps.example.org:<port>/<root-resource>/ coaps://example.com:<port>/<root-resource>/
ArbitraryLabel/<short-est> ArbitraryLabel/<short-est>
Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and
corresponding paths which are supported by EST. Table 1 provides the corresponding paths which are supported by EST. Table 1 provides the
mapping from the EST URI path to the shorter EST-coaps URI path. mapping from the EST URI path to the shorter EST-coaps URI path.
+------------------+-------------------------------+ +------------------+-------------------------------+
| EST | EST-coaps | | EST | EST-coaps |
+------------------+-------------------------------+ +------------------+-------------------------------+
| /cacerts | /crts | | /cacerts | /crts |
skipping to change at page 10, line 31 skipping to change at page 10, line 45
| /serverkeygen | /skc (application/pkix-cert) | | /serverkeygen | /skc (application/pkix-cert) |
+------------------+-------------------------------+ +------------------+-------------------------------+
Table 1: Short EST-coaps URI path Table 1: Short EST-coaps URI path
The /skg message is the EST /serverkeygen equivalent where the client The /skg message is the EST /serverkeygen equivalent where the client
requests for a certificate in PKCS#7 format and a private key. If requests for a certificate in PKCS#7 format and a private key. If
the client prefers a single application/pkix-cert certificate instead the client prefers a single application/pkix-cert certificate instead
of PKCS#7, he will make an /skc request. of PKCS#7, he will make an /skc request.
Clients and servers MUST support the short resource URIs. Clients and servers MUST support the short resource EST-coaps URIs.
In the context of CoAP, the presence and location of (path to) the In the context of CoAP, the presence and location of (path to) the
management data are discovered by sending a GET request to "/.well- management data are discovered by sending a GET request to "/.well-
known/core" including a resource type (RT) parameter with the value known/core" including a resource type (RT) parameter with the value
"ace.est*" [RFC6690]. Upon success, the return payload will contain "ace.est*" [RFC6690]. Upon success, the return payload will contain
the root resource of the EST resources. The example below shows the the root resource of the EST resources. The example below shows the
discovery of the presence and location of EST-coaps resources. discovery of the presence and location of EST-coaps resources.
Linefeeds are included only for readability. Linefeeds are included only for readability.
REQ: GET /.well-known/core?rt=ace.est* REQ: GET /.well-known/core?rt=ace.est*
skipping to change at page 11, line 6 skipping to change at page 11, line 21
</est/sen>;rt="ace.est.sen";ct="281 TBD287", </est/sen>;rt="ace.est.sen";ct="281 TBD287",
</est/sren>;rt="ace.est.sren";ct="281 TBD287", </est/sren>;rt="ace.est.sren";ct="281 TBD287",
</est/att>;rt="ace.est.att";ct=285, </est/att>;rt="ace.est.att";ct=285,
</est/skg>;rt="ace.est.skg";ct=62, </est/skg>;rt="ace.est.skg";ct=62,
</est/skc>;rt="ace.est.skc";ct=62 </est/skc>;rt="ace.est.skc";ct=62
The first three lines of the discovery response above MUST be The first three lines of the discovery response above MUST be
returned if the server supports resource discovery. The last three returned if the server supports resource discovery. The last three
lines are only included if the corresponding EST functions are lines are only included if the corresponding EST functions are
implemented. The Content-Formats in the response allow the client to implemented. The Content-Formats in the response allow the client to
request one that is supported by the server. 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. Discoverable port numbers can be returned in the response payload.
An example response payload for non-default CoAPS server port 61617 An example response payload for non-default CoAPS server port 61617
follows below. Linefeeds were included only for readability. follows below. Linefeeds were included only for readability.
REQ: GET /.well-known/core?rt=ace.est* REQ: GET /.well-known/core?rt=ace.est*
RES: 2.05 Content RES: 2.05 Content
<coaps://[2001:db8:3::123]:61617/est/crts>;rt="ace.est.crts"; <coaps://[2001:db8:3::123]:61617/est/crts>;rt="ace.est.crts";
ct="281 TBD287", ct="281 TBD287",
skipping to change at page 11, line 31 skipping to change at page 11, line 47
<coaps://[2001:db8:3::123]:61617/est/att>;rt="ace.est.att"; <coaps://[2001:db8:3::123]:61617/est/att>;rt="ace.est.att";
ct=285, ct=285,
<coaps://[2001:db8:3::123]:61617/est/skg>;rt="ace.est.skg"; <coaps://[2001:db8:3::123]:61617/est/skg>;rt="ace.est.skg";
ct=62, ct=62,
<coaps://[2001:db8:3::123]:61617/est/skc>;rt="ace.est.skc"; <coaps://[2001:db8:3::123]:61617/est/skc>;rt="ace.est.skc";
ct=62 ct=62
The server MUST support the default /.well-known/est root resource. The server MUST support the default /.well-known/est root resource.
The server SHOULD support resource discovery when he supports non- The server SHOULD support resource discovery when he supports non-
default URIs (like /est or /est/ArbitraryLabel) or ports. The client default URIs (like /est or /est/ArbitraryLabel) or ports. The client
SHOULD use resource discovery when /.well-known/est fails or when the SHOULD use resource discovery when he is unaware of the available
client is unaware of the available EST-coaps resources. EST-coaps resources.
It is up to the implementation to choose its root resource; 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 /est is used.
5.2. Mandatory/optional EST Functions 5.2. Mandatory/optional EST Functions
This specification contains a set of required-to-implement functions, This specification contains a set of required-to-implement functions,
optional functions, and not specified functions. The latter ones are optional functions, and not specified functions. The latter ones are
deemed too expensive for low-resource devices in payload and deemed too expensive for low-resource devices in payload and
calculation times. calculation times.
Table 2 specifies the mandatory-to-implement or optional Table 2 specifies the mandatory-to-implement or optional
skipping to change at page 13, line 39 skipping to change at page 13, line 49
container) with Content-Format identifier TBD287 (0x011F) instead of container) with Content-Format identifier TBD287 (0x011F) instead of
281. In cases where the private key is encrypted with CMS (as 281. In cases where the private key is encrypted with CMS (as
explained in Section 5.8) the Content-Format identifier is 280 explained in Section 5.8) the Content-Format identifier is 280
(0x0118) instead of 284. The key and certificate representations are (0x0118) instead of 284. The key and certificate representations are
ASN.1 encoded in binary format. An example is shown in Appendix A.3. ASN.1 encoded in binary format. An example is shown in Appendix A.3.
5.4. Message Bindings 5.4. Message Bindings
The general EST-coaps message characteristics are: The general EST-coaps message characteristics are:
o All EST-coaps request messages expect an acknowledgement (with a o EST-coaps servers sometimes need to provide delayed responses
response payload); EST-coaps requests are confirmable CON CoAP which are conveyed with an empty ACK or an ACK containing response
messages. 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- o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-
Format, Block, Accept and Location-Path. These CoAP Options are Format, Block, Accept and Location-Path. These CoAP Options are
used to communicate the HTTP fields specified in the EST REST used to communicate the HTTP fields specified in the EST REST
messages. The URI-host and Uri-Port Options can be omitted from messages. The Uri-host and Uri-Port Options can be omitted from
the COAP message sent on the wire. When omitted, they are the COAP message sent on the wire. When omitted, they are
logically assumed to be the transport protocol destination address logically assumed to be the transport protocol destination address
and port respectively. Explicit Uri-Host and Uri-Port Options are and port respectively. Explicit Uri-Host and Uri-Port Options are
typically used when an endpoint hosts multiple virtual servers and typically used when an endpoint hosts multiple virtual servers and
uses the Options to route the requests accordingly. Other COAP uses the Options to route the requests accordingly. Other COAP
Options should be handled in accordance with [RFC7252]. Options should be handled in accordance with [RFC7252].
o EST URLs are HTTPS based (https://), in CoAP these are assumed to o EST URLs are HTTPS based (https://), in CoAP these are assumed to
be translated to CoAPS (coaps://) be translated to CoAPS (coaps://)
skipping to change at page 20, line 48 skipping to change at page 21, line 29
If necessary, the EST-coaps-to-HTTP Registrar will support resouce If necessary, the EST-coaps-to-HTTP Registrar will support resouce
discovery according to the rules in Section 5.1. discovery according to the rules in Section 5.1.
7. Parameters 7. Parameters
This section addresses transmission parameters described in sections This section addresses transmission parameters described in sections
4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on 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 the CoAP parameters in [RFC7252], but the EST parameter values need
to be tuned to the CoAP parameter values. to be tuned to the CoAP parameter values.
It is RECOMMENDED, based on experiments, to follow the default CoAP It is recommended, based on experiments, to follow the default CoAP
configuration parameters ([RFC7252]). However, depending on the configuration parameters ([RFC7252]). However, depending on the
implementation scenario, retransmissions and timeouts can also occur implementation scenario, retransmissions and timeouts can also occur
on other networking layers, governed by other configuration on other networking layers, governed by other configuration
parameters. A change in a server parameter MUST ensure the adjusted parameters. A change in a server parameter MUST ensure the adjusted
value is also available to all the endpoints with which these value is also available to all the endpoints with which these
adjusted values are to be used to communicate. adjusted values are to be used to communicate.
Some further comments about some specific parameters, mainly from Some further comments about some specific parameters, mainly from
Table 2 in [RFC7252]: Table 2 in [RFC7252]:
skipping to change at page 27, line 32 skipping to change at page 28, line 12
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
13.2. Informative References 13.2. Informative References
[COREparams] [COREparams]
IANA, "Constrained RESTful Environments (CoRE) "Constrained RESTful Environments (CoRE) Parameters",
Parameters", <https://www.iana.org/assignments/core- <https://www.iana.org/assignments/core-parameters/
parameters/core-parameters.xhtml>. core-parameters.xhtml>.
[I-D.ietf-lamps-rfc5751-bis] [I-D.ietf-lamps-rfc5751-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", draft-ietf-lamps-rfc5751-bis-12 Message Specification", draft-ietf-lamps-rfc5751-bis-12
(work in progress), September 2018. (work in progress), September 2018.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,
"Connection Identifiers for DTLS 1.2", draft-ietf-tls- "Connection Identifiers for DTLS 1.2", draft-ietf-tls-
skipping to change at page 28, line 11 skipping to change at page 28, line 38
Josefsson, S., "Channel Bindings for TLS based on the Josefsson, S., "Channel Bindings for TLS based on the
PRF", draft-josefsson-sasl-tls-cb-03 (work in progress), PRF", draft-josefsson-sasl-tls-cb-03 (work in progress),
March 2015. March 2015.
[I-D.moskowitz-ecdsa-pki] [I-D.moskowitz-ecdsa-pki]
Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson,
"Guide for building an ECC pki", draft-moskowitz-ecdsa- "Guide for building an ECC pki", draft-moskowitz-ecdsa-
pki-04 (work in progress), September 2018. pki-04 (work in progress), September 2018.
[ieee802.15.4] [ieee802.15.4]
Institute of Electrical and Electronics Engineers, "IEEE "IEEE Standard 802.15.4-2006", 2006.
Standard 802.15.4-2006", 2006.
[ieee802.1ar] [ieee802.1ar]
Institute of Electrical and Electronics Engineers, "IEEE "IEEE 802.1AR Secure Device Identifier", December 2009.
802.1AR Secure Device Identifier", December 2009.
[PsQs] Nadia Heninger, Zakir Durumeric, Eric Wustrow, J. Alex [PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys
Halderman, "Mining Your Ps and Qs: Detection of Widespread in Network Devices", USENIX Security Symposium 2012 ISBN
Weak Keys in Network Devices", USENIX Security Symposium 978-931971-95-9, August 2012.
2012 ISBN 978-931971-95-9, August 2012.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>. <https://www.rfc-editor.org/info/rfc4919>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>. <https://www.rfc-editor.org/info/rfc5272>.
skipping to change at page 29, line 38 skipping to change at page 30, line 17
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>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422, Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018, DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>. <https://www.rfc-editor.org/info/rfc8422>.
[RSAorig] Petr Svenda, Matus Nemec, Peter Sekan, Rudolf Kvasnovsky, [RSAorig] "The Million-Key Question - Investigating the Origins of
David Formanek, David Komarek, Vashek Matyas, "The RSA Public Keys", USENIX Security Symposium 2016 ISBN
Million-Key Question - Investigating the Origins of RSA
Public Keys", USENIX Security Symposium 2016 ISBN
978-1-931971-32-4, August 2016. 978-1-931971-32-4, August 2016.
[tripleshake] [tripleshake]
Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cedric "Triple Handshakes and Cookie Cutters: Breaking and Fixing
Fournet, Alfredo Pironti, Pierre-Yves Strub, "Triple
Handshakes and Cookie Cutters: Breaking and Fixing
Authentication over TLS", IEEE Security and Privacy ISBN Authentication over TLS", IEEE Security and Privacy ISBN
978-1-4799-4686-0, May 2014. 978-1-4799-4686-0, May 2014.
Appendix A. EST messages to EST-coaps Appendix A. EST messages to EST-coaps
This section shows similar examples to the ones presented in This section shows similar examples to the ones presented in
Appendix A of [RFC7030]. The payloads in the examples are the hex Appendix A of [RFC7030]. The payloads in the examples are the hex
encoded binary, generated with 'xxd -p', of the PKI certificates encoded binary, generated with 'xxd -p', of the PKI certificates
created following [I-D.moskowitz-ecdsa-pki]. Hex is used for created following [I-D.moskowitz-ecdsa-pki]. Hex is used for
visualization purposes because a binary representation cannot be visualization purposes because a binary representation cannot be
rendered well in text. The hexadecimal representations would not be rendered well in text. The hexadecimal representations would not be
transported in hex, but in binary. The payloads are shown transported in hex, but in binary. The payloads are shown
unencrypted. In practice the message content would be transferred unencrypted. In practice the message content would be transferred
over an encrypted DTLS tunnel. over an encrypted DTLS tunnel.
The certificate responses included in the examples contain Content- The certificate responses included in the examples contain Content-
Format 281 (application/pkcs7). If the client had requested Content- Format 281 (application/pkcs7). If the client had requested Content-
Format TBD287 (application/pkix-cert) by querying /est/skc, the Format TBD287 (application/pkix-cert) by querying /est/skc, the
server would respond with a single DER binary certificate. server would respond with a single DER binary certificate.
These examples assume a short root resource path of "/est". These examples assume a short resource path of "/est". Even though
omitted from the examples for brevity, before making the EST-coaps
requests, a client would learn about the server supported EST-coaps
resources with a GET request for /.well-known/core?rt=ace.est* as
explained in Section 5.1.
The corresponding CoAP headers are only shown in Appendix A.1. The corresponding CoAP headers are only shown in Appendix A.1.
Creating CoAP headers is assumed to be generally understood. Creating CoAP headers is assumed to be generally understood.
The message content breakdown is presented in Appendix C. The message content breakdown is presented in Appendix C.
A.1. cacerts A.1. cacerts
In EST-coaps, a cacerts message can be: In EST-coaps, a cacerts message can be:
GET coaps://est-coaps.example.org:9085/est/crts GET example.com:9085/est/crts
(Accept: 281) (Accept: 281)
The corresponding CoAP header fields are shown below. The use of The corresponding CoAP header fields are shown below. The use of
block and DTLS are worked out in Appendix B. block and DTLS are worked out in Appendix B.
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
Option (Uri-Host) Option (Uri-Host)
Option Delta = 0x3 (option# 3) Option Delta = 0x3 (option# 3)
Option Length = 0x9 Option Length = 0xD
Option Value = est-coaps.example.org Option Value = "example.com"
Option (Uri-Port) Option (Uri-Port)
Option Delta = 0x4 (option# 3+4=7) Option Delta = 0x4 (option# 3+4=7)
Option Length = 0x4 Option Length = 0x4
Option Value = 9085 Option Value = 9085
Option (Uri-Path) Option (Uri-Path)
Option Delta = 0x4 (option# 7+4=11) Option Delta = 0x4 (option# 7+4=11)
Option Length = 0x5 Option Length = 0x5
Option Value = "est" Option Value = "est"
Option (Uri-Path) Option (Uri-Path)
Option Delta = 0x0 (option# 11+0=11) Option Delta = 0x0 (option# 11+0=11)
skipping to change at page 33, line 5 skipping to change at page 33, line 8
A.2. enroll / reenroll A.2. enroll / reenroll
During the (re-)enroll exchange the EST-coaps client uses a CSR During the (re-)enroll exchange the EST-coaps client uses a CSR
(Content-Format 286) request in the POST request payload. The Accept (Content-Format 286) request in the POST request payload. The Accept
option tells the server that the client is expecting Content-Format option tells the server that the client is expecting Content-Format
281 (PKCS#7) in the response. As shown in Appendix C.2, the CSR 281 (PKCS#7) in the response. As shown in Appendix C.2, the CSR
contains a ChallengePassword which is used for POP linking contains a ChallengePassword which is used for POP linking
(Section 4). (Section 4).
POST [2001:db8::2:1]:61616/est/sen POST [2001:db8::2:321]:61616/est/sen
(Token: 0x45) (Token: 0x45)
(Accept: 281) (Accept: 281)
(Content-Format: 286) (Content-Format: 286)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
3082018b30820131020100305c310b3009060355040613025553310b3009 3082018b30820131020100305c310b3009060355040613025553310b3009
06035504080c024341310b300906035504070c024c413114301206035504 06035504080c024341310b300906035504070c024c413114301206035504
skipping to change at page 35, line 4 skipping to change at page 35, line 4
05070804a013301106092b06010401b43b0a01040401020304300a06082a 05070804a013301106092b06010401b43b0a01040401020304300a06082a
8648ce3d0403020349003046022100c0d81996d2507d693f3c48eaa5ee94 8648ce3d0403020349003046022100c0d81996d2507d693f3c48eaa5ee94
91bda6db214099d98117c63b361374cd86022100a774989f4c321a5cf25d 91bda6db214099d98117c63b361374cd86022100a774989f4c321a5cf25d
832a4d336a08ad67df20f1506421188a0ade6d349236a1003100 832a4d336a08ad67df20f1506421188a0ade6d349236a1003100
The breakdown of the request and response is shown in Appendix C.2. The breakdown of the request and response is shown in Appendix C.2.
A.3. serverkeygen A.3. serverkeygen
In a serverkeygen exchange the CoAP POST request looks like In a serverkeygen exchange the CoAP POST request looks like
POST coaps://192.0.2.1:8085/est/skg POST 192.0.2.1:8085/est/skg
(Token: 0xa5) (Token: 0xa5)
(Accept: 62) (Accept: 62)
(Content-Format: 286) (Content-Format: 286)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
3081cf3078020100301631143012060355040a0c0b736b67206578616d70 3081cf3078020100301631143012060355040a0c0b736b67206578616d70
6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b 6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b
skipping to change at page 37, line 5 skipping to change at page 37, line 5
The private key in the response above is without CMS EnvelopedData The private key in the response above is without CMS EnvelopedData
and has no additional encryption beyond DTLS (Section 5.8). and has no additional encryption beyond DTLS (Section 5.8).
The breakdown of the request and response is shown in Appendix C.3 The breakdown of the request and response is shown in Appendix C.3
A.4. csrattrs A.4. csrattrs
Below is a csrattrs exchange Below is a csrattrs exchange
REQ: REQ:
GET coaps://[2001:db8::2:1]:61616/est/att GET example.com:61616/est/att
RES: RES:
2.05 Content 2.05 Content
(Content-Format: 285) (Content-Format: 285)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
307c06072b06010101011630220603883701311b131950617273652053455 307c06072b06010101011630220603883701311b131950617273652053455
skipping to change at page 38, line 25 skipping to change at page 38, line 25
option:NUM/M/size) indicating the kind of Block Option (2 in this option:NUM/M/size) indicating the kind of Block Option (2 in this
case) followed by a colon, and then the block number (NUM), the more case) followed by a colon, and then the block number (NUM), the more
bit (M = 0 in Block2 response means it is last block), and block size bit (M = 0 in Block2 response means it is last block), and block size
with exponent (2**(SZX+4)) separated by slashes. The Length 64 is with exponent (2**(SZX+4)) separated by slashes. The Length 64 is
used with SZX=2 to avoid IP fragmentation. The CoAP Request is sent used with SZX=2 to avoid IP fragmentation. The CoAP Request is sent
confirmable (CON) and the Content-Format of the response, even though confirmable (CON) and the Content-Format of the response, even though
not shown, is 281 (application/pkcs7-mime; smime-type=certs-only). not shown, is 281 (application/pkcs7-mime; smime-type=certs-only).
The transfer of the 10 blocks with partially filled block NUM=9 is The transfer of the 10 blocks with partially filled block NUM=9 is
shown below shown below
GET coaps://est-coaps.example.org:9085/est/crts (2:0/0/64) --> GET example.com:9085/est/crts (2:0/0/64) -->
<-- (2:0/1/64) 2.05 Content <-- (2:0/1/64) 2.05 Content
GET coaps://est-coaps.example.org:9085/est/crts (2:1/0/64) --> GET example.com:9085/est/crts (2:1/0/64) -->
<-- (2:1/1/64) 2.05 Content <-- (2:1/1/64) 2.05 Content
| |
| |
| |
GET coaps://est-coaps.example.org:9085/est/crts (2:9/0/64) --> GET example.com:9085/est/crts (2:9/0/64) -->
<-- (2:9/0/64) 2.05 Content <-- (2:9/0/64) 2.05 Content
The header of the GET request looks like The header of the GET request looks like
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
Option (Uri-Host) Option (Uri-Host)
Option Delta = 0x3 (option# 3) Option Delta = 0x3 (option# 3)
Option Length = 0x9 Option Length = 0xD
Option Value = est-coaps.example.org Option Value = "example.com"
Option (Uri-Port) Option (Uri-Port)
Option Delta = 0x4 (option# 3+4=7) Option Delta = 0x4 (option# 3+4=7)
Option Length = 0x4 Option Length = 0x4
Option Value = 9085 Option Value = 9085
Option (Uri-Path) Option (Uri-Path)
Option Delta = 0x4 (option# 7+4=11) Option Delta = 0x4 (option# 7+4=11)
Option Length = 0x5 Option Length = 0x5
Option Value = "est" Option Value = "est"
Option (Uri-Path)Uri-Path) Option (Uri-Path)Uri-Path)
Option Delta = 0x0 (option# 11+0=11) Option Delta = 0x0 (option# 11+0=11)
skipping to change at page 41, line 17 skipping to change at page 41, line 17
T = 2 (means ACK) T = 2 (means ACK)
Code = 0x45 (2.05 Content) Code = 0x45 (2.05 Content)
Token = 0x9a (copied from request by server) Token = 0x9a (copied from request by server)
Options Options
Option Option
Option Delta = 0xC (option# 12 Content-Format) Option Delta = 0xC (option# 12 Content-Format)
Option Length = 0x2 Option Length = 0x2
Option Value = 281 Option Value = 281
Option Option
Option Delta = 0xB (option# 12+11=23 Block2 ) Option Delta = 0xB (option# 12+11=23 Block2 )
Option Length = 0x2 Option Length = 0x1
Option Value = 0x92 (block#=9, M=0, SZX=2) Option Value = 0x92 (block#=9, M=0, SZX=2)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
Payload = Payload =
2ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f1353272f022047a28a 2ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f1353272f022047a28a
e5c7306163b3c3834bab3c103f743070594c089aaa0ac870cd13b902caa1 e5c7306163b3c3834bab3c103f743070594c089aaa0ac870cd13b902caa1
003100 003100
B.2. enroll / reenroll B.2. enroll / reenroll
In this example, the requested Block2 size of 256 bytes, required by In this example, the requested Block2 size of 256 bytes, required by
the client, is transferred to the server in the very first request the client, is transferred to the server in the very first request
message. The block size 256=(2**(SZX+4)) which gives SZX=4. The message. The block size 256=(2**(SZX+4)) which gives SZX=4. The
notation for block numbering is the same as in Appendix B.1. The notation for block numbering is the same as in Appendix B.1. The
header fields and the payload are omitted for brevity. header fields and the payload are omitted for brevity.
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> POST [2001:db8::2:321]: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:321]: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:321]: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:321]: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:321]: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 enrollment with multiple blocks Figure 5: EST-COAP enrollment with multiple blocks
N1+1 blocks have been transferred from client to the server and N2+1 N1+1 blocks have been transferred from client to the server and N2+1
blocks have been transferred from server to client. blocks have been transferred from server to client.
Appendix C. Message content breakdown Appendix C. Message content breakdown
This appendix presents the breakdown of the hexadecimal dumps of the This appendix presents the breakdown of the hexadecimal dumps of the
 End of changes. 45 change blocks. 
75 lines changed or deleted 87 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/