Thanks, I think this is a very useful mechanism and a well written draft. Some quick comments.
- "ciphersuite" Note that both TLS and EDHOC spells this with space "cipher suite" - Section 2. I don't understand what "SM" in Figure 1 is an abbrevation for. - Section 2. "UDP/TCP/Websockets" Why is the Websocket protocol in plural? - Section 3. "EAP method that exports cryptographic material" This can probably be reformulated in terms of MSK, EMSK or "Key derivation" which is the property that RFC 3748 uses. - "EAP-MD5 cannot be used since it does not export key material" MD5 should really not be used at all for security resons. Highlighting it like this might be the idea that it would be ok if EAP-MD5 had the "Key derivation" property. - "The required key, the Master Session Key (MSK), will be available once the EAP authentication is successful." Does this belong in step 2? - In Figure 2. I do not think you have to wait until EAP-SUCCES to make MSK available. The authentication can be successful before EAP-SUCCES. - In section 3.3. it might be good to state that "Reauthentication" might be needed to rekey MSK/EMSK and to increase protection against key leakage. (An important mitigation of pervasive monitoring is to force attackers to do dynamic key exfiltration instead of static key exfiltration. Dynamic key exfiltration increases the risk of discovery for the attacker [RFC7624]. While OSCORE will soon be augmented with a rekeying mechanism with forward secrecy, attackers can still get away with doing static key exfiltration. This is similar to TLS 1.3 with KeyUpdate, after leakage of application_traffic_secret_N, a passive attacker can passively eavesdrop on all future application data sent on the connection including application data encrypted with application_traffic_secret_N+1, application_traffic_secret_N+2, etc.) - "4. The values from 65000 to 65535 are reserved for experimentation" what does "The values" refer to? Lifetime? In that case it would fit better under 3. - In addition to AES-CCM-16-64-128, only ciphersuites only cipher suites with AES-GCM is included. My feeling was that most IoT people are more interested in ChaCha20-Poly1305 than AES-GCM. I don't have a strong personal opinion. - "which is considered fresh key material" “considered fresh”? Maybe "uniformally random"? - With normal use of DTLS, Appendix A violates “The CoAP-EAP operation is intended to be compatible with the use of intermediary entities between the IoT device and the Controller”. This limitation should be clearly stated. - Probably good if the labels have “CoAP-EAP” in all the labels to guarantee that they do not collide with anything else. Cheers, John From: Emu <emu-boun...@ietf.org> on behalf of Dan Garcia Carrillo <garcia...@uniovi.es> Date: Monday, 25 October 2021 at 13:27 To: ace@ietf.org <ace@ietf.org>, EMU WG <e...@ietf.org> Subject: Re: [Emu] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt Dear ACE and EMU WG, We have submitted a new version of the draft (draft-ietf-ace-wg-coap-eap) This version provides information on the different comments, from the reviews and interim meetings. Best Regards. El 10/25/2021 a las 1:23 PM, internet-dra...@ietf.org escribió: > A new version of I-D, draft-ietf-ace-wg-coap-eap-04.txt > has been successfully submitted by Dan Garcia-Carrillo and posted to the > IETF repository. > > Name: draft-ietf-ace-wg-coap-eap > Revision: 04 > Title: EAP-based Authentication Service for CoAP > Document date: 2021-10-25 > Group: ace > Pages: 29 > URL: > https://www.ietf.org/archive/id/draft-ietf-ace-wg-coap-eap-04.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-ace-wg-coap-eap > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-wg-coap-eap-04 > > Abstract: > This document specifies an authentication service that uses the > Extensible Authentication Protocol (EAP) transported employing > Constrained Application Protocol (CoAP) messages. As such, it > defines an EAP lower layer based on CoAP called CoAP-EAP. One of the > primer goals is to authenticate a CoAP-enabled IoT device (EAP peer) > that intends to join a security domain managed by a Controller (EAP > authenticator). Secondly, it allows deriving key material to protect > CoAP messages exchanged between them based on Object Security for > Constrained RESTful Environments (OSCORE), enabling the establishment > of a security association between them. > > > > > The IETF Secretariat > > _______________________________________________ Emu mailing list e...@ietf.org https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
