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

[Daniel Migault <[e-mail]>]

Thanks Goran for the review, that is well appreciated. I am wondering if
these concerns could be addressed by next week (by the co-authors) for
example ?

For all, please provide your comments or feedback as soon as possible, but
we do expect to ship that document to the IESG very soon - for what very
soon means.

Yours,
Daniel

On Thu, Nov 25, 2021 at 4:10 AM Göran Selander <goran.selander=
[e-mail]> 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
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>


-- 
Daniel Migault
Ericsson