draft-ietf-ace-coap-est-14.txt   draft-ietf-ace-coap-est-15.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: March 23, 2020 Cisco Systems Expires: April 2, 2020 Cisco Systems
M. Richardson M. Richardson
SSW SSW
S. Raza S. Raza
RISE SICS RISE SICS
September 20, 2019 September 30, 2019
EST over secure CoAP (EST-coaps) EST over secure CoAP (EST-coaps)
draft-ietf-ace-coap-est-14 draft-ietf-ace-coap-est-15
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 March 23, 2020. This Internet-Draft will expire on April 2, 2020.
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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 7 4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 7
5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 10 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 10
5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12
5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13
5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 14 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 14
5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15
5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 16 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 16
5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 17 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 17
5.8. Server-side Key Generation . . . . . . . . . . . . . . . 19 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 19
6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 21 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 21
7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 2, line 42 skipping to change at page 2, line 42
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10.1. EST server considerations . . . . . . . . . . . . . . . 25 10.1. EST server considerations . . . . . . . . . . . . . . . 25
10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 27 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . 30 13.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 32 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 32
A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 34 A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 35
A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 36 A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 36
A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 38 A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix B. EST-coaps Block message examples . . . . . . . . . . 39 Appendix B. EST-coaps Block message examples . . . . . . . . . . 39
B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 39 B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 43 B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 43
Appendix C. Message content breakdown . . . . . . . . . . . . . 44 Appendix C. Message content breakdown . . . . . . . . . . . . . 44
C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 44 C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 45 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 45
C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 47 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Change Log 1. Change Log
EDNOTE: Remove this section before publication EDNOTE: Remove this section before publication
-15
Updates to addressed Ben's AD follow up feedback.
-14 -14
Updates to complete Ben's AD review feedback and discussions. Updates to complete Ben's AD review feedback and discussions.
-13 -13
Updates based on AD's review and discussions Updates based on AD's review and discussions
Examples redone without password Examples redone without password
skipping to change at page 7, line 26 skipping to change at page 7, line 30
capitals, as shown here. capitals, as shown here.
Many of the concepts in this document are taken from [RFC7030]. Many of the concepts in this document are taken from [RFC7030].
Consequently, much text is directly traceable to [RFC7030]. Consequently, much text is directly traceable to [RFC7030].
4. DTLS and conformance to RFC7925 profiles 4. DTLS and conformance to RFC7925 profiles
This section describes how EST-coaps conforms to the profiles of low- This section describes how EST-coaps conforms to the profiles of low-
resource devices described in [RFC7925]. EST-coaps can transport resource devices described in [RFC7925]. EST-coaps can transport
certificates and private keys. Certificates are responses to certificates and private keys. Certificates are responses to
(re-)enrollment requests or requests a trusted certificate list. (re-)enrollment requests or requests for a trusted certificate list.
Private keys can be transported as responses to a server-side key Private keys can be transported as responses to a server-side key
generation request as described in Section 4.4 of [RFC7030] and generation request as described in Section 4.4 of [RFC7030] and
discussed in Section 5.8 of this document. discussed in Section 5.8 of this document.
EST-coaps depends on a secure transport mechanism that secures the EST-coaps depends on a secure transport mechanism that secures the
exchanged CoAP messages. DTLS is one such secure protocol. No other exchanged CoAP messages. DTLS is one such secure protocol. No other
changes are necessary regarding the secure transport of EST messages. changes are necessary regarding the secure transport of EST messages.
+------------------------------------------------+ +------------------------------------------------+
| EST request/response messages | | EST request/response messages |
skipping to change at page 8, line 11 skipping to change at page 8, line 14
curve. Additionally, crypto agility is important, and the curve. Additionally, crypto agility is important, and the
recommendations in Section 4.4 of [RFC7925] and any updates to it recommendations in Section 4.4 of [RFC7925] and any updates to it
concerning Curve25519 and other curves also apply. concerning Curve25519 and other curves also apply.
DTLS 1.2 implementations must use the Supported Elliptic Curves and DTLS 1.2 implementations must use the Supported Elliptic Curves and
Supported Point Formats Extensions in [RFC8422]. Uncompressed point Supported Point Formats Extensions in [RFC8422]. Uncompressed point
format must also be supported. DTLS 1.3 [I-D.ietf-tls-dtls13] format must also be supported. DTLS 1.3 [I-D.ietf-tls-dtls13]
implementations differ from DTLS 1.2 because they do not support implementations differ from DTLS 1.2 because they do not support
point format negotiation in favor of a single point format for each point format negotiation in favor of a single point format for each
curve. Thus, support for DTLS 1.3 does not mandate point format curve. Thus, support for DTLS 1.3 does not mandate point format
extensions and negotiation. In addition, DTLS 1.3 uses the extensions and negotiation. In addition, in DTLS 1.3 the Supported
"supported_groups" extension in contrast to Supported Elliptic Curves Elliptic Curves extension has been renamed to Supported Groups.
used by DTLS 1.2
CoAP was designed to avoid IP fragmentation. DTLS is used to secure CoAP was designed to avoid IP fragmentation. DTLS is used to secure
CoAP messages. However, fragmentation is still possible at the DTLS CoAP messages. However, fragmentation is still possible at the DTLS
layer during the DTLS handshake when using ECC ciphersuites. If layer during the DTLS handshake when using ECC ciphersuites. If
fragmentation is necessary, "DTLS provides a mechanism for fragmentation is necessary, "DTLS provides a mechanism for
fragmenting a handshake message over several records, each of which fragmenting a handshake message over several records, each of which
can be transmitted separately, thus avoiding IP fragmentation" can be transmitted separately, thus avoiding IP fragmentation"
[RFC6347]. [RFC6347].
The authentication of the EST-coaps server by the EST-coaps client is The authentication of the EST-coaps server by the EST-coaps client is
skipping to change at page 13, line 12 skipping to change at page 13, line 12
implementation of the EST-coaps functions. Discovery of the implementation of the EST-coaps functions. Discovery of the
existence of optional functions is described in Section 5.1. existence of optional functions is described in Section 5.1.
+------------------+--------------------------+ +------------------+--------------------------+
| EST Functions | EST-coaps implementation | | EST Functions | EST-coaps implementation |
+------------------+--------------------------+ +------------------+--------------------------+
| /cacerts | MUST | | /cacerts | MUST |
| /simpleenroll | MUST | | /simpleenroll | MUST |
| /simplereenroll | MUST | | /simplereenroll | MUST |
| /fullcmc | Not specified | | /fullcmc | Not specified |
| /csrattrs | OPTIONAL |
| /serverkeygen | OPTIONAL | | /serverkeygen | OPTIONAL |
| /csrattrs | OPTIONAL |
+------------------+--------------------------+ +------------------+--------------------------+
Table 2: List of EST-coaps functions Table 2: List of EST-coaps functions
5.3. Payload formats 5.3. Payload formats
EST-coaps is designed for low-resource devices and hence does not EST-coaps is designed for low-resource devices and hence does not
need to send Base64-encoded data. Simple binary is more efficient need to send Base64-encoded data. Simple binary is more efficient
(30% smaller payload for DER-encoded ASN.1) and well supported by (30% smaller payload for DER-encoded ASN.1) and well supported by
CoAP. Thus, the payload for a given Media-Type follows the ASN.1 CoAP. Thus, the payload for a given Media-Type follows the ASN.1
skipping to change at page 17, line 33 skipping to change at page 17, line 33
particular, a slow server can respond to an EST-coaps enrollment particular, a slow server can respond to an EST-coaps enrollment
request with an empty ACK with code 0.00, before sending the request with an empty ACK with code 0.00, before sending the
certificate to the client after a short delay. If the certificate certificate to the client after a short delay. If the certificate
response is large, the server will need more than one Block2 block to response is large, the server will need more than one Block2 block to
transfer it. transfer it.
This situation is shown in Figure 2. The client sends an enrollment This situation is shown in Figure 2. The client sends an enrollment
request that uses N1+1 Block1 blocks. The server uses an empty 0.00 request that uses N1+1 Block1 blocks. The server uses an empty 0.00
ACK to announce the delayed response which is provided later with ACK to announce the delayed response which is provided later with
2.04 messages containing N2+1 Block2 Options. The first 2.04 is a 2.04 messages containing N2+1 Block2 Options. The first 2.04 is a
confirmable message that is acknowledged by the client. Onwards, confirmable message that is acknowledged by the client. Onwards, the
having received the first 256 bytes in the first Block2 block, the client acknowledges all subsequent Block2 blocks.
client asks for a block reduction to 128 bytes in a confirmable
enrollment request and acknowledges the Block2 blocks sent up to that
point.
The notation of Figure 2 is explained in Appendix B.1. The notation of Figure 2 is explained in Appendix B.1.
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} -->
<-- (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 (frag# 2)} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} -->
<-- (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 (frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
<-- (0.00 empty ACK) <-- (0.00 empty ACK)
| |
... Short delay before the certificate is ready ... ... Short delay before the certificate is ready ...
| |
<-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp (frag# 1)} <-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp (frag# 1)}
(ACK) --> (ACK) -->
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) -->
<-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)} <-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp (frag# 2)}
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->
<-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp (frag# N2+1)} <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)}
Figure 2: EST-COAP enrollment with short wait Figure 2: EST-COAP enrollment with short wait
If the server is very slow (i.e., minutes) in providing the response If the server is very slow (i.e., minutes) in providing the response
(i.e., when a manual intervention is needed), he SHOULD respond with (i.e., when a manual intervention is needed), he SHOULD respond with
an ACK containing response code 5.03 (Service unavailable) and a Max- an ACK containing response code 5.03 (Service unavailable) and a Max-
Age Option to indicate the time the client SHOULD wait to request the Age Option to indicate the time the client SHOULD wait to request the
content later. After a delay of Max-Age, the client SHOULD resend content later. After a delay of Max-Age, the client SHOULD resend
the identical CSR to the server. As long as the server responds with the identical CSR to the server. As long as the server responds with
response code 5.03 (Service Unavailable) with a Max-Age Option, the response code 5.03 (Service Unavailable) with a Max-Age Option, the
skipping to change at page 18, line 48 skipping to change at page 18, line 48
other reasons. other reasons.
To demonstrate this scenario, Figure 3 shows a client sending an To demonstrate this scenario, Figure 3 shows a client sending an
enrollment request that uses N1+1 Block1 blocks to send the CSR to enrollment request that uses N1+1 Block1 blocks to send the CSR to
the server. The server needs N2+1 Block2 blocks to respond, but also the server. The server needs N2+1 Block2 blocks to respond, but also
needs to take a long delay (minutes) to provide the response. needs to take a long delay (minutes) to provide the response.
Consequently, the server uses a 5.03 ACK response with a Max-Age Consequently, the server uses a 5.03 ACK response with a Max-Age
Option. The client waits for a period of Max-Age as many times as Option. The client waits for a period of Max-Age as many times as
she receives the same 5.03 response and retransmits the enrollment she receives the same 5.03 response and retransmits the enrollment
request until she receives a certificate in a fragmented 2.04 request until she receives a certificate in a fragmented 2.04
response. Note that the client asks again for a decrease in the response.
block size when acknowledging the first Block2.
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} -->
<-- (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 (frag# 2)} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} -->
<-- (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 (frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
<-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age) <-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age)
skipping to change at page 19, line 31 skipping to change at page 19, line 31
POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} -->
<-- (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 (frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
| |
... Immediate response when certificate is ready ... ... Immediate response when certificate is ready ...
| |
<-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)} <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) -->
<-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)} <-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp (frag# 2)}
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->
<-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp (frag# N2+1)} <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)}
Figure 3: EST-COAP enrollment with long wait Figure 3: EST-COAP enrollment with long wait
5.8. Server-side Key Generation 5.8. Server-side Key Generation
In scenarios where it is desirable that the server generates the In scenarios where it is desirable that the server generates the
private key, server-side key generation is available. Such scenarios private key, server-side key generation is available. Such scenarios
could be when it is considered more secure to generate at the server could be when it is considered more secure to generate at the server
the long-lived random private key that identifies the client, or when the long-lived random private key that identifies the client, or when
the resources spent to generate a random private key at the client the resources spent to generate a random private key at the client
skipping to change at page 20, line 32 skipping to change at page 20, line 32
symmetrically or asymmetrically as per [RFC7030]. The symmetric key symmetrically or asymmetrically as per [RFC7030]. The symmetric key
or the asymmetric keypair establishment method is out of scope of the or the asymmetric keypair establishment method is out of scope of the
specification. A /skg or /skc request with a CSR without specification. A /skg or /skc request with a CSR without
SMIMECapabilities expects an application/multipart-core with an SMIMECapabilities expects an application/multipart-core with an
unencrypted PKCS#8 private key with Content-Format 284. unencrypted PKCS#8 private key with Content-Format 284.
The EST-coaps server-side key generation response is returned with The EST-coaps server-side key generation response is returned with
Content-Format application/multipart-core Content-Format application/multipart-core
[I-D.ietf-core-multipart-ct] containing a CBOR array with four items [I-D.ietf-core-multipart-ct] containing a CBOR array with four items
(Section 5.3) . The two representations (each consisting of two CBOR (Section 5.3) . The two representations (each consisting of two CBOR
array items) are preceded by its Content-Format ID. Dependent on the array items) do not have to be in a particular order since each
request, the private key can be in unprotected PKCS#8 [RFC5958] representation is preceded by its Content-Format ID. Dependent on
the request, the private key can be in unprotected PKCS#8 [RFC5958]
format (Content-Format 284) or protected inside of CMS SignedData format (Content-Format 284) or protected inside of CMS SignedData
(Content-Format 280). The SignedData, placed in the outermost (Content-Format 280). The SignedData, placed in the outermost
container, is signed by the party that generated the private key, container, is signed by the party that generated the private key,
which may be the EST server or the EST CA. SignedData placed within which may be the EST server or the EST CA. SignedData placed within
the Enveloped Data does not need additional signing as explained in the Enveloped Data does not need additional signing as explained in
Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted
key is included in the encryptedKey attribute in a KEKRecipientInfo key is included in the encryptedKey attribute in a KEKRecipientInfo
structure. In the case where the asymmetric encryption key is structure. In the case where the asymmetric encryption key is
suitable for transport key operations the generated private key is suitable for transport key operations the generated private key is
encrypted with a symmetric key which is encrypted by the client- encrypted with a symmetric key which is encrypted by the client-
skipping to change at page 21, line 14 skipping to change at page 21, line 14
[RFC7030] recommends the use of additional encryption of the returned [RFC7030] recommends the use of additional encryption of the returned
private key. For the context of this specification, clients and private key. For the context of this specification, clients and
servers that choose to support server-side key generation MUST servers that choose to support server-side key generation MUST
support unprotected (PKCS#8) private keys (Content-Format 284). support unprotected (PKCS#8) private keys (Content-Format 284).
Symmetric or asymmetric encryption of the private key (CMS Symmetric or asymmetric encryption of the private key (CMS
EnvelopedData, Content-Format 280) SHOULD be supported for EnvelopedData, Content-Format 280) SHOULD be supported for
deployments where end-to-end encryption is needed between the client deployments where end-to-end encryption is needed between the client
and a server. Such cases could include architectures where an entity and a server. Such cases could include architectures where an entity
between the client and the CA terminates the DTLS connection between the client and the CA terminates the DTLS connection
(Registrar in Figure 4). This document does not strongly recommend (Registrar in Figure 4). Although [RFC7030] strongly recommends that
CMS encryption on top of the DTLS channel like [RFC7030] unless clients request the use of CMS encryption on top of the TLS channel's
mandated by the use-case. protection, this document does not make such a recommendation; CMS
encryption can still be used when mandated by the use-case.
6. HTTPS-CoAPS Registrar 6. 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 which case it will support TLS/HTTP instead of constrained network in which case it will support TLS/HTTP instead of
CoAPS. In such environments EST-coaps is used by the client within CoAPS. 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 as operate between the CoAP environment and the external HTTP network as
skipping to change at page 26, line 38 skipping to change at page 26, line 38
used as signature keys, signing the certification request with the used as signature keys, signing the certification request with the
private key serves as a PoP on that key pair". The inclusion of tls- private key serves as a PoP on that key pair". The inclusion of tls-
unique in the certificate request links the proof-of-possession to unique in the certificate request links the proof-of-possession to
the TLS proof-of-identity. This implies but does not prove that only the TLS proof-of-identity. This implies but does not prove that only
the authenticated client currently has access to the private key. the authenticated client currently has access to the private key.
What's more, CMC PoP linking uses tls-unique as it is defined in What's more, CMC PoP linking uses tls-unique as it is defined in
[RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing [RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing
a man-in-the-middle to leverage session resumption and renegotiation a man-in-the-middle to leverage session resumption and renegotiation
to inject himself between a client and server even when channel to inject himself between a client and server even when channel
binding is in use. In the context of this specification, an attacker binding is in use. Implementers should use the Extended Master
could invalidate the purpose of the PoP linking ChallengePassword in Secret Extension in DTLS [RFC7627] to prevent such attacks. In the
the client request by resuming an EST-coaps connection. Even though context of this specification, an attacker could invalidate the
the practical risk of such an attack to EST-coaps is not devastating, purpose of the PoP linking ChallengePassword in the client request by
we would rather use a more secure channel binding mechanism. Such a resuming an EST-coaps connection. Even though the practical risk of
mechanism could include an updated tls-unique value generation like such an attack to EST-coaps is not devastating, we would rather use a
the tls-unique-prf defined in [I-D.josefsson-sasl-tls-cb] by using a more secure channel binding mechanism. Such a mechanism could
TLS exporter [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter include an updated tls-unique value generation like the tls-unique-
(Section 7.5 of [RFC8446]) value in place of the tls-unique value in prf defined in [I-D.josefsson-sasl-tls-cb] by using a TLS exporter
the CSR. Such mechanism has not been standardized yet. Adopting a [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter (Section 7.5 of
channel binding value generated from an exporter would break [RFC8446]) value in place of the tls-unique value in the CSR. Such
backwards compatibility for an RA that proxies through to a classic mechanism has not been standardized yet. Adopting a channel binding
EST server. Thus, in this specification we still depend on the tls- value generated from an exporter would break backwards compatibility
unique mechanism defined in [RFC5929], especially since a 3SHAKE for an RA that proxies through to a classic EST server. Thus, in
attack does not expose messages exchanged with EST-coaps. this specification we still depend on the tls-unique mechanism
defined in [RFC5929], especially since a 3SHAKE attack does not
expose messages exchanged with EST-coaps.
Regarding the Certificate Signing Request (CSR), an EST-coaps server Regarding the Certificate Signing Request (CSR), an EST-coaps server
is expected to be able to recover from improper CSR requests. is expected to be able to recover from improper CSR requests.
Interpreters of ASN.1 structures should be aware of the use of Interpreters of ASN.1 structures should be aware of the use of
invalid ASN.1 length fields and should take appropriate measures to invalid ASN.1 length fields and should take appropriate measures to
guard against buffer overflows, stack overruns in particular, and guard against buffer overflows, stack overruns in particular, and
malicious content in general. malicious content in general.
10.2. HTTPS-CoAPS Registrar considerations 10.2. HTTPS-CoAPS Registrar considerations
skipping to change at page 32, line 15 skipping to change at page 32, line 15
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX [RFC7299] Housley, R., "Object Identifier Registry for the PKIX
Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014,
<https://www.rfc-editor.org/info/rfc7299>. <https://www.rfc-editor.org/info/rfc7299>.
[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>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>.
[RSAfact] "Factoring RSA keys from certified smart cards: [RSAfact] "Factoring RSA keys from certified smart cards:
Coppersmith in the wild", Advances in Cryptology Coppersmith in the wild", Advances in Cryptology
- ASIACRYPT 2013, August 2013. - ASIACRYPT 2013, August 2013.
[tripleshake] [tripleshake]
"Triple Handshakes and Cookie Cutters: Breaking and Fixing "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
 End of changes. 21 change blocks. 
46 lines changed or deleted 55 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/