From 53933bb9f93657955555f2302baef2e39709ae05 Mon Sep 17 00:00:00 2001 From: csosto-pk Date: Mon, 18 Nov 2019 14:00:30 -0500 Subject: [PATCH] v16 remnants by Ben K. --- draft-ietf-ace-coap-est.xml | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-ace-coap-est.xml b/draft-ietf-ace-coap-est.xml index 0a40fe3..e3a48da 100644 --- a/draft-ietf-ace-coap-est.xml +++ b/draft-ietf-ace-coap-est.xml @@ -329,8 +329,8 @@ are responses to (re-)enrollment requests or requests for a trusted certificate list. Private keys can be transported as responses to a server-side key generation request as described in Section 4.4 of - and discussed in - of this document. + (and subsections) and discussed in + of this document. EST-coaps depends on a secure transport mechanism that secures the exchanged CoAP messages. DTLS is one such secure protocol. No other changes are necessary regarding the secure transport of EST messages. @@ -350,7 +350,7 @@ TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 . Curve secp256r1 MUST be supported ; this curve is equivalent to the - NIST P-256 curve. After the standardization of , + NIST P-256 curve. After the publication of , support for Curve25519 will likely be required in the future by (D)TLS Profiles for the Internet of Things . @@ -414,7 +414,8 @@ HMAC(finished_key, * Only included if present. ]]> --> - 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. 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 . + 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 in . + 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 . 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, 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.