Re: [Ace] [Emu] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt

[Dan Garcia Carrillo <[e-mail]>]

Dear John,

First of all, our apologies for the late response to your review, for 
some unknown reason we did not see it at the time. It is much 
appreciated and we will try to answer you  as soon as possible.

Best Regards,
Dan.

On 25/10/21 17:02, John Mattsson wrote:
>
> 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 <[e-mail]> on behalf of Dan Garcia Carrillo 
> <[e-mail]>
> *Date: *Monday, 25 October 2021 at 13:27
> *To: *[e-mail] <[e-mail]>, EMU WG <[e-mail]>
> *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, [e-mail] 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-mail]
> https://www.ietf.org/mailman/listinfo/emu
>