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

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

Dear Daniel,

We are going to go through the reviews and do our best have the document 
ready by next week.

Thank you.

Best Regards,

Dan.

On 25/11/21 15:04, Daniel Migault wrote:
> 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