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

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

Dear John,

Thank you for taking the time to review the document. I think with this 
the next version would be much more accurate.

Please find responses to your comments inline.

Best Regards,

CoAP-EAP authors.

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"
>
  [authors] We will change the wording, thank you

> - Section 2. I don't understand what "SM" in Figure 1 is an 
> abbrevation for.
>
  [authors] SM stands for State Machine, we will explain that in the 
text, thank you for pointing that out.
>
> - Section 2. "UDP/TCP/Websockets" Why is the Websocket protocol in plural?
>
  [authors] Probably a typo, thanks
>
> - 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.
>
  [authors] We will rephrase using key derivation.
>
> - "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.
>
[authors] That’s correct. Most probably is better to just mentioned that 
any EAP method that does not export key material MUST NOT be used. It is 
worth mentioning that the goal of this statement was, as the document 
defines an EAP lower layer, not so much as trying to make 
recommendations on which EAP methods are secure or should be considered 
deprecated. We just intend to provide information on which EAP methods 
are suitable for its use with this particular EAP lower layer.

> - "The required key, the Master Session Key (MSK), will be available 
> once the
>
> EAP authentication is successful."
>
>    Does this belong in step 2?
>
[authors] It is a clarification to highlight that the MSK is used to 
derive key material for the OSCORE context. We can remove it if it 
clarifies the paragraph or even to point to step 7.
>
> - 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.
>
[authors] This is an interesting comment that we already commented on 
EMU WG, though we do not receive any comment. In fact, we tend to agree 
with you. All the details are in this e-mail we sent:

https://mailarchive.ietf.org/arch/msg/emu/bnMFV4_1uTW7sSwVOp7WzVZZCAI/

In summary, the EAP peer state machine does not inform the EAP lower 
layer that the key is available in eapKeyData until it is in SUCCESS 
state. In this final state, the eapKeyAvailable is set to TRUE.

In any case, everything is now solved because the arrival of 
OSCORE-protected CoAP message is considered as an alternate success 
indication.

> - 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.)
>

[authors] Yes, sure. We will add this comment to the text. In fact that 
is the intention to the reauthentication: to refresh the MSK/EMSK. In 
fact, the EAP Key Management Framework establishes a default value of 8 
hours to refresh the MSK/EMSK. Therefore that would be the default value 
each time the OSCORE key material is refreshed.

> - "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.
>
[authors] Thank you for pointing that out. The CBOR structure is 
intended to be extensible. We have the values for what is currently 
expected in the protocol, but we want to keep the structure open for 
future additions if they are needed.

The values from 65000 to 65535are referring to  the index of the values 
that are not yet assigned, for extensibility. Those indexes are reserved 
for experimentation.

> - 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"?
>
[authors] Basically, the EAP Key Management Framework uses that specific 
terminology (RFC 5274- 5.7 
<https://datatracker.ietf.org/doc/html/rfc5247#section-5.7>.  Key 
Freshness”). That is why we used this term.  “While preserving algorithm 
independence, session keys MUST be strong and fresh.  Each session 
deserves an independent session key.”
>
> - 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.
>

[authors] We agree. that this consideration applies. We will add that to 
the DTLS annex.

> - Probably good if the labels have “CoAP-EAP” in all the labels to 
> guarantee that they do not collide with anything else.
>

[authors] Thank you for this point. We will apply this change when using 
labels for key derivation to avoid confusion.

> 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
>