Skip to content

Commit

Permalink
Barry L.'s IESG Review (issue# 153)
Browse files Browse the repository at this point in the history
  • Loading branch information
@csosto-pk
csosto-pk committed Dec 23, 2019
1 parent 5711116 commit 01f7014
Showing 1 changed file with 47 additions and 40 deletions.
87 changes: 47 additions & 40 deletions draft-ietf-ace-coap-est.xml
View file
Expand Up @@ -52,7 +52,7 @@
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" ipr="trust200902" docName="draft-ietf-ace-coap-est-17">
<rfc category="std" ipr="trust200902" docName="draft-ietf-ace-coap-est-18">
<front>
<title abbrev="EST-coaps">EST over secure CoAP (EST-coaps)</title>
<author fullname="Peter van der Stok" initials="P." surname="van der Stok">
Expand Down Expand Up @@ -109,8 +109,6 @@
</address>
</author>



<date/>
<area>Security</area>
<workgroup>ACE</workgroup>
Expand All @@ -130,6 +128,11 @@

<section anchor="changes" title="Change Log">
<t>EDNOTE: Remove this section before publication</t>
<t> -18
<list style="empty">
<t>IESG Reviews fixes. </t>
</list>
</t>
<t> -17
<list style="empty">
<t>v16 remnants by Ben K.</t>
Expand Down Expand Up @@ -384,21 +387,22 @@
<t>a previously installed certificate (e.g., manufacturer IDevID
<xref target="ieee802.1ar"/> or a certificate issued by some other party). IDevID's are expected to have
a very long life, as long as the device, but under some conditions
could expire. In that case, the server MAY want to authenticate
could expire. In that case, the server MAY authenticate
a client certificate against its trust store although the certificate
is expired (<xref target="sec"/>). </t>
</list></t>
<t>EST-coaps supports the certificate types and Trust Anchors (TA) that are specified for EST in Section 3 of <xref target="RFC7030"/>.
</t>

<t>As described in Section 2.1 of <xref target="RFC5272"/> proof-of-identity refers to
a value that can be used to prove that the private key corresponding to the certified public key
is in the possession of and can be used by an end-entity or client. Additionally, channel-binding
a value that can be used to prove that an end-entity or client
is in the possession of and can use the private key corresponding
to the certified public key. Additionally, channel-binding
information can link proof-of-identity with an established connection.
Connection-based proof-of-possession is OPTIONAL for EST-coaps clients and servers. When proof-of-possession is desired, a set of actions are required regarding the use of tls-unique, described in Section 3.5 in <xref target="RFC7030"/>. The tls-unique information consists of the contents of the first "Finished" message in the (D)TLS handshake between server and client <xref target="RFC5929"/>. The client adds the "Finished" message as a ChallengePassword in the attributes section of the PKCS#10 Request <xref target="RFC5967"/> to prove that the client is indeed in control of the private key at the time of the (D)TLS session establishment. </t>

<t>In the case of handshake message fragmentation, if proof-of-possession is desired, the Finished
message added as the ChallengePassword in the CSR is calculated as specified by the DTLS standards. We summarize it here for convenience. For DTLS 1.2, in the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed as if each handshake message had been sent as a single fragment (Section 4.2.6 of <xref target="RFC6347"/>). The Finished message is calculated as shown in Section 7.4.9 of <xref target="RFC5246"/>.
message added as the ChallengePassword in the CSR is calculated as specified by the DTLS standards. We summarize it here for convenience. For DTLS 1.2, in the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed on each reassembled message, as if each message had not been fragmented (Section 4.2.6 of <xref target="RFC6347"/>). The Finished message is calculated as shown in Section 7.4.9 of <xref target="RFC5246"/>.
<!--<figure align="left"><artwork><![CDATA[
PRF(master_secret, finished_label, Hash(handshake_messages))
[0..verify_data_length-1];
Expand All @@ -415,8 +419,8 @@ HMAC(finished_key,
* Only included if present.
]]></artwork></figure> --> </t>

<t>In a constrained CoAP environment, endpoints can't always afford to establish a DTLS connection for every EST transaction. Authenticating and negotiating DTLS keys requires resources on low-end endpoints and consumes valuable bandwidth. To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions which was not the case with <xref target="RFC7030"/>.
For example, an EST csrattrs request that is followed by a simpleenroll request can use the same authenticated DTLS connection. However, when a cacerts request is included in the set of sequential EST transactions, some additional security considerations apply regarding the use of the Implicit and Explicit TA database as explained in <xref target="sec-est"/>.</t>
<t>In a constrained CoAP environment, endpoints can't always afford to establish a DTLS connection for every EST transaction. Authenticating and negotiating DTLS keys requires resources on low-end endpoints and consumes valuable bandwidth. To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions, which was not the case with <xref target="RFC7030"/>.
For example, if an EST csrattrs request is followed by a simpleenroll request, both can use the same authenticated DTLS connection. However, when a cacerts request is included in the set of sequential EST transactions, some additional security considerations apply regarding the use of the Implicit and Explicit TA database as explained in <xref target="sec-est"/>.</t>

<t>Given that after a successful enrollment, it is more likely that a new EST transaction will take place after a significant amount of time, the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other. In some cases, like NAT rebinding, keeping the state of a connection is not possible when devices sleep for extended periods of time. In such occasions, <xref target="I-D.ietf-tls-dtls-connection-id"/> negotiates a connection ID that can eliminate the need for new handshake and its additional cost; or DTLS session resumption provides a less costly alternative than re-doing a full DTLS handshake. </t>
</section> <!-- 7925 profile -->
Expand Down Expand Up @@ -448,7 +452,7 @@ HMAC(finished_key,

<section anchor="discovery" title = "Discovery and URIs">

<t>EST-coaps is targeted for low-resource networks with small packets. Two types of installations are possible (1) rigid ones where the address and the supported functions of the EST server(s) are known, and (2) flexible one where the EST server and it supported functions need to be discovered.</t>
<t>EST-coaps is targeted for low-resource networks with small packets. Two types of installations are possible: (1) rigid ones, where the address and the supported functions of the EST server(s) are known, and (2) a flexible one, where the EST server and its supported functions need to be discovered.</t>

<t>For both types of installations, saving header space is important and short EST-coaps URIs are specified in this document. These URIs are shorter than the ones in <xref target="RFC7030"/>. Two example EST-coaps resource path names are: </t>

Expand Down Expand Up @@ -687,9 +691,9 @@ representations. -->
<t>Section 5.9 of <xref target="RFC7252"/> and Section 7 of <xref target="RFC8075"/>
specify the mapping of HTTP response codes to CoAP response codes.
The success code in response to an EST-coaps GET request (/crts, /att),
is 2.05. Similarly, 2.04 <!--2.01 Making 2.04 based on comment from Esko https://github.com/SanKumar2015/EST-coaps/issues/145#issuecomment-497029846 -->
is used in successfull response to EST-coaps POST requests
(/sen, /sren, /skg, /skc). <!-- Removing because we now use 2.04 based on comment
is 2.05. Similarly, 2.04 is used in successfull response to EST-coaps POST requests (/sen, /sren, /skg, /skc).
<!--2.01 Making 2.04 based on comment from Esko https://github.com/SanKumar2015/EST-coaps/issues/145#issuecomment-497029846 -->
<!-- Removing because we now use 2.04 based on comment
from Esko https://github.com/SanKumar2015/EST-coaps/issues/145#issuecomment-497029846
Section 7 of
<xref target="RFC8075"/> maps 2.02 (Deleted) or 2.04 (Changed) to an HTTP
Expand Down Expand Up @@ -788,12 +792,16 @@ POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->
<-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)}
]]></artwork></figure>

<t>If the server is very slow (i.e., minutes) in providing the response (i.e., when a manual intervention is needed),
<t>If the server is very slow (for example, manual intervention
is required which would take minutes),
it SHOULD respond with an ACK containing response code 5.03 (Service unavailable) and a Max-Age
Option to indicate the time the client SHOULD wait to request the content later. After a delay of Max-Age,
the client SHOULD resend the identical CSR to the server. As long as the server responds with response code 5.03
(Service Unavailable) with a Max-Age Option, the client SHOULD keep resending the enrollment request until the server
responds with the certificate or the client abandons the request for other reasons. </t>
Option to indicate the time the client SHOULD wait before sending another request to obtain the content. After a delay of Max-Age,
the client SHOULD resend the identical CSR to the server.
As long as the server continues to respond with response code 5.03
(Service Unavailable) with a Max-Age Option, the client
will continue to delay for Max-Age and then resend the
enrollment request until the server
responds with the certificate or the client abandons the request for policy or other reasons. </t>

<t>To demonstrate this scenario, <xref target="fig-est-long-wait"/> shows a client sending an enrollment
request that uses N1+1 Block1 blocks to send the CSR to the server. The server needs
Expand Down Expand Up @@ -845,19 +853,18 @@ POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->
</section> <!-- Delayed Responses -->

<section anchor="serverkey" title="Server-side Key Generation">
<t> In scenarios where it is desirable that the server generates the
private key, server-side key generation is available. Such
scenarios 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 resources spent to generate a random private key at the
<t>Private keys can be generated on the server to support
scenarios where serer-side key generation is needed. Such scenarios
include those where it is considered more secure to generate the
long-lived, random private key that identifies the client at the server,
or where the resources spent to generate a random private key at the
client are considered scarce, or when the security policy requires
that the certificate public and corresponding private keys are
centrally generated and controlled. Of course, that does not
eliminate the need for proper random numbers in various protocols
like (D)TLS (<xref target="sec-est"/>).</t>
centrally generated and controlled. As always, it is necessary
to use proper random numbers in various protocols such as (D)TLS (<xref target="sec-est"/>).</t>

<t>When requesting server-side key generation, the client
asks for the server or proxy to generate the private key and the certificate
asks for the server or proxy to generate the private key and the certificate,
which are transferred back to the client in the server-side key generation
response. In all respects, the server treats the CSR as it would treat any
enroll or re-enroll CSR; the only distinction here is that the server
Expand All @@ -876,19 +883,18 @@ POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->
Then the private key is encrypted symmetrically or asymmetrically as
per <xref target="RFC7030" />.
The symmetric key or the asymmetric keypair establishment method is
out of scope of the specification.
out of scope of this specification.
A /skg or /skc request with a CSR without SMIMECapabilities
expects an application/multipart-core with an unencrypted PKCS#8 private
key with Content-Format 284.</t>

<t>
The EST-coaps server-side key generation response is returned with Content-Format
application/multipart-core <xref target="I-D.ietf-core-multipart-ct"/>
containing a CBOR array with four items <!--(<xref target="cborpair"/>) -->
(<xref target="format"/>) <!-- with the order specified in <xref target="RFC7030"/> -->.
containing a CBOR array with four items (<xref target="format"/>). <!--(<xref target="cborpair"/>) --> <!-- with the order specified in <xref target="RFC7030"/> -->
The two representations (each consisting of two CBOR array items) do not have to be in a particular order since each representation is
preceded by its Content-Format ID.
Dependent on the request, the private key can be in unprotected PKCS#8 <xref target="RFC5958"/>
Depending on the request, the private key can be in unprotected PKCS#8 <xref target="RFC5958"/>
format (Content-Format 284) or protected inside of CMS SignedData
(Content-Format 280). The SignedData, placed in the outermost container, is signed by the party that
generated the private key, which may be the EST server or
Expand Down Expand Up @@ -1022,12 +1028,13 @@ POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->
PROBING_RATE | 1 byte/second | ]]></artwork></figure> -->
EST does not impose any unique values on the CoAP parameters
in <xref target="RFC7252"/>, but the setting of the CoAP parameter values may have consequence for the setting of the EST parameter values. </t>
<t>It is recommended, based on experiments,
<t>
Implementations should follow the default CoAP configuration
parameters <xref target="RFC7252"/>.
<!-- using Nexus Certificate Manager with Californium for
CoAP support, communicating with a ContikiOS and tinyDTLS based
client, from RISE SICS, --> to follow the default CoAP
configuration parameters (<xref target="RFC7252"/>). However,
depending on the implementation scenario, retransmissions
client, from RISE SICS, -->
However, depending on the implementation scenario, retransmissions
and timeouts can also occur on other networking layers,
governed by other configuration parameters. When a change in a
server parameter has taken place, the parameter values in the communicating endpoints MUST be adjusted as necessary.</t>
Expand Down Expand Up @@ -1123,11 +1130,11 @@ security considerations of <xref target="RFC7030"/> continue to apply.</t>
For those deploying server-side key generation, analysis SHOULD be done to establish whether server-side key generation increases
or decreases the probability of digital identity theft.</t>

<t>It is important to note that sources contributing to the randomness
pool used to generate random numbers on laptops or desktop PCs
are not available on many constrained devices, such as mouse
movement, timing of keystrokes, or air turbulence on the
movement of hard drive heads, as pointed out in <xref target="PsQs"/>.
<t>It is important to note that, as pointed out in <xref target="PsQs"/>, sources contributing to the randomness
pool used to generate random numbers on laptops or desktop PCs,
such as mouse movement, timing of keystrokes, or air turbulence
on the movement of hard drive heads,
are not available on many constrained devices.
Other sources have to be used or dedicated hardware has to be added.
Selecting hardware for an IoT device that is capable of producing
high-quality random numbers is therefore important <xref target="RSAfact"/>.</t>
Expand Down

0 comments on commit 01f7014

Please sign in to comment.