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

From: Göran Selander <[email-masked]>
Date: Thu, 25 Nov 2021 09:09:42 +0000

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 <[email-masked]> on behalf of John Mattsson <john.mattsson=[email-masked]>
Date: Monday, 25 October 2021 at 17:03
To: Dan Garcia Carrillo <[email-masked]>, [email-masked] <[email-masked]>, EMU WG <[email-masked]>
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 <[email-masked]> on behalf of Dan Garcia Carrillo <[email-masked]>
Date: Monday, 25 October 2021 at 13:27
To: [email-masked] <[email-masked]>, EMU WG <[email-masked]>
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, [email-masked] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Daniel Migault <[email-masked]>
Date: Thu, 25 Nov 2021 09:04:39 -0500

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=
[email-masked]> wrote:

> 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
>
> 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.
>
>
>
> 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 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"
>
>
>
> 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:
>
>
>
>
> 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 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.
>
>
>
> 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 <[email-masked]> on behalf of John Mattsson
> <john.mattsson=[email-masked]>
> *Date: *Monday, 25 October 2021 at 17:03
> *To: *Dan Garcia Carrillo <[email-masked]>, [email-masked] <
> [email-masked]>, EMU WG <[email-masked]>
> *Subject: *Re: [Ace] [Emu] New Version Notification for
> draft-ietf-ace-wg-coap-eap-04.txt
>
> Thanks,
>
>
>
> - 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.)
>
>
>
> - 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.
>
>
>
> - 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 <[email-masked]> on behalf of Dan Garcia Carrillo <
> [email-masked]>
> *Date: *Monday, 25 October 2021 at 13:27
> *To: [email-masked] <[email-masked]>, EMU WG <[email-masked]>
> *Subject: *Re: [Emu] New Version Notification for
> draft-ietf-ace-wg-coap-eap-04.txt
>
> Dear ACE and EMU WG,
>
> > 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:

-- 
Daniel Migault
Ericsson

---

From: Dan Garcia Carrillo <[email-masked]>
Date: Fri, 26 Nov 2021 10:03:33 +0100

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=[email-masked]> wrote:
>
>     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
>
>     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.
>
>     (“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.
>
>     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
>
>     indicate to what resource (e.g. '/a/x') the Controller MUST send
>     the first message with the EAP authentication"
>
>     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:
>
>     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 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
>     "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.
>
>     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
>
>     *To: *Dan Garcia Carrillo <[email-masked]>, [email-masked]
>     <[email-masked]>, EMU WG <[email-masked]>
>     - 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.
>     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.)
>
>     - 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.
>
>     - 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.
>
>     *From: *Emu <[email-masked]> on behalf of Dan Garcia
>     Carrillo <[email-masked]>

---

From: Dan Garcia Carrillo <[email-masked]>
Date: Fri, 26 Nov 2021 10:04:50 +0100

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:
> 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
>
> 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.
>
> *  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.
>
> 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
>
> indicate to what resource (e.g. '/a/x') the Controller MUST send the 
> first message with the EAP authentication"
>
> 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:
>
> terminology like e.g. RID-I and RID-C for RID of IoT device and 
> Controller, respectively.
>
> Step 2
>
> 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
>
> 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]).
>
> ---
>
> * In the case of new authentication the procedure explained in Section 
> 3.2 applies protection with OSCORE in communication with the last 
> resource.
>
> Also I find the expression "new (re)authentication" confusing - what 
> is the the difference between "re-authentication" and "new 
> re-authentication"?
>
> Section 4.
>
> 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
>
> - 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 
> 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.
>
> - 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.
>
> *From: *Emu <[email-masked]> on behalf of Dan Garcia Carrillo 
> <[email-masked]>

---

From: Dan Garcia Carrillo <[email-masked]>
Date: Fri, 26 Nov 2021 10:08:08 +0100

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.