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

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

Dear Göran,

Thank you for your review, it is much appreciated. We will address your 
comments and answer as soon as possible.

Best Regards.

Dan,

On 25/11/21 10:09, Göran Selander wrote:
>
> Hello authors of draft-ietf-ace-wg-coap-eap,
>
> Thanks for working with this draft. Here is a mix of nits/editorials 
> and more substantial comments in the order as they appear in the draft.
>
> Abstract
>
> OLD
>
> One of the primer goals is to
>
> NEW
>
> One of the main goals is to
>
> Section 1.
>
> "EAP methods transported in CoAP MUST generate cryptographic material
>
>    [RFC5247] for this specification. "
>
> The term “cryptographic material” is used multiple times in this 
> document but is not defined. RFC 5247 uses “keying material”, does 
> that match the intended meaning?
>
> Section2.
>
> Figure 1 is perhaps too informative containing endpoints, stacks, what 
> is CoAP, and scope of this document. There is no line/arrow between 
> IoT Device and Controller, presumably because there is too much other 
> information. Section 2 don’t talk about the stack at all.
>
> * Proposal: Make two figures: one with nodes and lines/arrows 
> (“architecture”); another with the stack, which is essentially the 
> same in the two nodes in scope of this document.
>
> *  It is confusing that CoAP role allocation is shown in the figure 
> since those only apply to one step of the operation in section 3.2. In 
> all other steps the roles are reversed. Proposal: omit the CoAP roles 
> in the figure, and/or provide an explanation in section text or 
> caption. The section text talking about CoAP client also needs to be 
> modified accordingly.
>
> * Nit: RFC8323 calls the layer between request/response and reliable 
> transport “message framing”. Perhaps you want to have a common layer 
> renaming the "Messages" layer with “Message /framing/”.
>
> Section 3.
>
> "It is RECOMMENDED a light EAP method for the case of constrained link 
> and constrained IoT devices."
>
> If this will remain a normative recommendation, then there needs to be 
> a definition (reference) of "light EAP method". Perhaps consider just 
> explain the intention of "light" ("lightweight"?) and remove the 
> normative recommendation?
>
> ---
>
> OLD
>
> The article [eap-framework], highlights the benefits of the EAP
>
>    framework.
>
> NEW
>
> The benefits of the EAP framework are highlighted in [eap-framework].
>
> 3.1
>
> "resource directory"
>
> Provide a reference or at least as an example, like 
> draft-ietf-core-resource-directory,
>
> ---
>
> OLD
>
> Example of this protocols
>
> NEW
>
> Example of such protocols
>
> 3.2
>
> Step 0
>
> "The message also includes an URI in the payload of the message to 
> indicate to what resource (e.g. '/a/x') the Controller MUST send the 
> first message with the EAP authentication"
>
> The DoS issues with requiring the Controller to send a message to an 
> unknown URI need to be considered.
>
> Step 1
>
> "the Sender ID for OSCORE selected by the Controller"
>
> Is this the Sender ID *of the IoT device* selected by the Controller? 
> In other words, is it the Recipient ID of the Controller selected by 
> the Controller? That would correspond to how OSCORE identifiers are 
> chosen in EDHOC:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#section-3.3.2
>
> Best not to use the terms "SID" or "RID" unqualified in message fields 
> since they are reversed on the IoT device and Controller. Better use 
> terminology like e.g. RID-I and RID-C for RID of IoT device and 
> Controller, respectively.
>
> Step 2
>
> "the EAP response, the Recipient ID and the selected ciphersuite for 
> OSCORE are in the payload."
>
> Is this the Recipient ID *of the IoT device*? See comment above.
>
> ---
>
> OLD
>
> In this step, the IoT device MAY create a OSCORE security context with 
> the Sender ID and Recipient ID.
>
> NEW
>
> In this step, the IoT device MAY create a OSCORE security context with 
> its Sender ID and Recipient ID.
>
> Step 7
>
> OLD
>
> The reception of the POST message protected with OSCORE using the 
> Sender ID sent in Step 1 is considered by the IoT device as an 
> alternate indication of success ([RFC3748]).
>
> The unqualified "Sender ID" is confusing here. Why does the ID sent in 
> step 1 indicate success to the IoT device? I would expect the ID 
> selected by the IoT device itself and sent in step 2, if used by the 
> Controller to derive the OSCORE security context to protect the 
> message in step 7 would be a stronger indication of success. Proposal 
> (check if this is correct):
>
> NEW
>
> The reception of the POST message protected with an OSCORE security 
> context derived using the Recipient ID of the IoT device sent in Step 
> 2 is considered by the IoT device as an alternate indication of 
> success ([RFC3748]).
>
> ---
>
> "The communication with the last resource (e.g. '/a/w') from this 
> point MUST be protected with OSCORE except during a new 
> (re)authentication (see Section 3.3)."
>
> I don't understand why there is an exception. OSCORE seems to be 
> applied to communication with the last resource in all cases:
>
> * In the case of new authentication the procedure explained in Section 
> 3.2 applies protection with OSCORE in communication with the last 
> resource.
>
> * In the case of re-authentication, the procedure is explained in 
> Section 3.3 to be "exactly the same" as in Section 3.2.
>
> Also I find the expression "new (re)authentication" confusing - what 
> is the the difference between "re-authentication" and "new 
> re-authentication"?
>
> Section 4.
>
> "  1.  SID: It contains the Identifier for the Sender ID to be used in
>
>        the OSCORE security context.
>
>    2.  RID: It contains the Identifier for the Recipient to be used in
>
>        the OSCORE security context."
>
> Same comment as above to qualify SID and RID: is SID the Sender ID of 
> the IoT device or of the Controller?
>
> Section 5.1
>
> "If the Controller sends a restricted list
>
>    of ciphersuites that is willing to accept, and the ones supported by
>
>    the IoT device are not in that list, the IoT device will respond with
>
>    a '4.00 Bad Request', expressing in the payload the ciphersuites
>
>    supported. "
>
> Make clear (here or in a security consideration) that in case of an 
> error message containing a cipher suite, the exchange of cipher suites 
> between EAP authenticator and EAP peer cannot be verified. For 
> example, a man-in-the-middle could replace cipher suites in either 
> message which would not be noticed if the protocol is ended after step 2.
>
> Best regards
>
> Göran
>
> *From: *Ace <[e-mail]> on behalf of John Mattsson 
> <john.mattsson=[e-mail]>
> *Date: *Monday, 25 October 2021 at 17:03
> *To: *Dan Garcia Carrillo <[e-mail]>, [e-mail] 
> <[e-mail]>, EMU WG <[e-mail]>
> *Subject: *Re: [Ace] [Emu] New Version Notification for 
> draft-ietf-ace-wg-coap-eap-04.txt
>
> 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
>