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

[Dan Garcia Carrillo]

Hi Göran,

Thank you again for your comments.

We have incorporated them into the a new 06 version of the draft that we 
just submitted.


Best Regards,
Dan.


On 6/12/21 12:13, Göran Selander wrote:


Hi Dan,

Please find my replies to your two questions about the update inline 
below.


Best regards

Göran

*From: *Dan Garcia Carrillo 

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

[authors] Yes, we agree. We can remove that part from the sentence to 
avoid any confusion. Nevertheless, after your comment, it would be 
worth stating that if the access to any other resource requires OSCORE 
protection can use the generated OSCORE context. Does it sound 
reasonable?


[GS] Yes, the established security context can be used between other 
resources if allowed by the application's security policy. Proposed 
rephrasing of step 8:


OLD

  "The IoT Device answers with '2.04 Changed' if the EAP
  authentication is a success and the verification of the "POST"
  protected with OSCORE in Step 7 is correctly verified.  The
  communication with the last resource (e.g. '/a/w') from this point
  MUST be protected with OSCORE.  Any other resource that requires
  OSCORE protection MAY be protected with this OSCORE security
  context."
NEW
  "If the EAPauthentication and the verification of the OSCORE 
protected "POST"in Step 7 is successful, thenthe IoT Device answers 
with an OSCORE protected '2.04 Changed'. From this point on, the 
communication with the last resource (e.g. '/a/w')
MUST be protected with OSCORE. If allowed by application policy, 
sameOSCORE securitycontextMAY be use to protect communication toother 
resources between the same endpoints."




Another editorial comment refering to the recent update:

OLD

 "The reception of the POST

  message protected with OSCORE with Sender ID equal to RID-I

  (Recipient ID of the IoT device) sent in Step 2 is considered by

  the IoT device as an alternate indication of success ([RFC3748 
])."


I would avoid the term Sender ID since it is all about verification of 
a received message, e.g. like this.


NEW

 "The verification of the received OSCORE protected"POST"
messageusing RID-I(Recipient ID of the IoT device) sent in Step 2 is 
considered by
  the IoT device as an alternate indication of success ([RFC3748 
])."




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.

[authors] That’s right. However, after your comments, we believe this 
could be improved. The reason is that by default we can assume that at 
least cipher suite 0. AES-CCM-16-64-128, SHA-256 is implemented in 
both entities. As such, if the controller includes option 0 in the 
list of cipher suites, the controller will not receive a bad request 
since at least the IoT device can select cipher suite 0 and therefore 
the authentication will follow until the end cipher suite negotiation 
can be verified.  We think it is simpler and we can get rid of a bad 
request. Does it sound reasonable?


[GS] Sounds OK to me.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Göran Selander]

Hi Dan,

Please find my replies to your two questions about the update inline below.

Best regards
Göran



From: Dan Garcia Carrillo 

"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.
[authors] Yes, we agree. We can remove that part from the sentence to avoid any 
confusion. Nevertheless, after your comment, it would be worth stating that if 
the access to any other resource requires OSCORE protection can use the 
generated OSCORE context. Does it sound reasonable?

[GS] Yes, the established security context can be used between other resources 
if allowed by the application's security policy. Proposed rephrasing of step 8:

OLD

 "The IoT Device answers with '2.04 Changed' if the EAP

  authentication is a success and the verification of the "POST"

  protected with OSCORE in Step 7 is correctly verified.  The

  communication with the last resource (e.g. '/a/w') from this point

  MUST be protected with OSCORE.  Any other resource that requires

  OSCORE protection MAY be protected with this OSCORE security

  context."

NEW

 "If the EAP authentication and the verification of the OSCORE protected 
"POST" in Step 7 is successful, then the IoT Device answers with an OSCORE 
protected '2.04 Changed'. From this point on, the communication with the last 
resource (e.g. '/a/w')

MUST be protected with OSCORE. If allowed by application policy, same OSCORE 
security context MAY be use to protect communication to other resources between 
the same endpoints."




Another editorial comment refering to the recent update:


OLD
 "The reception of the POST
  message protected with OSCORE with Sender ID equal to RID-I
  (Recipient ID of the IoT device) sent in Step 2 is considered by
  the IoT device as an alternate indication of success 
([RFC3748])."


I would avoid the term Sender ID since it is all about verification of a 
received message, e.g. like this.


NEW

 "The verification of the received OSCORE protected "POST"

message using RID-I (Recipient ID of the IoT device) sent in Step 2 is 
considered by

  the IoT device as an alternate indication of success 
([RFC3748])."






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.


[authors] That’s right. However, after your comments, we believe this could be 
improved. The reason is that by default we can assume that at least cipher 
suite 0. AES-CCM-16-64-128, SHA-256 is implemented in both entities. As such, 
if the controller includes option 0 in the list of cipher suites, the 
controller will not receive a bad request since at least the IoT device can 
select cipher suite 0 and therefore the authentication will follow until the 
end cipher suite negotiation can be verified.  We think it is simpler and we 
can get rid of a bad request. Does it sound reasonable?

[GS] Sounds OK to me.



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Dan Garcia Carrillo]

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


[authors] Yes, it is correct.  Having qualified the names, the message 
that is sent in the EAP success, would be using the Sender ID of the 
Controller -- Recipient-ID of the IoT device.



---

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


[authors] Yes, we agree. We can remove that part from the sentence to 
avoid any confusion. Nevertheless, after your comment, it would be worth 
stating that if the access to any other resource requires OSCORE 
protection can use the generated OSCORE context. Does it sound reasonable?


Also I find the expression "new (re)authentication" confusing - what 
is the the difference between "re-authentication" and "new 
re-authentication"?


[authors] Yes, just saying re-authentication is enough. In any case, 
that sentence will be removed as per your suggestion above.



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?



 [authors] Solved now using qualifies RID-I and RID-C.


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.


[authors] That’s right. However, after your comments, we believe this 
could be improved. The reason is that by default we can assume that at 
least cipher suite 0. AES-CCM-16-64-128, SHA-256 is implemented in both 
entities. As such, if the controller includes option 0 in the list of 
cipher suites, the controller will not receive a bad request since at 
least the IoT device can select cipher suite 0 and therefore the 
authentication will follow until the end cipher suite negotiation can be 
verified.  We think it is simpler and we can get rid of a bad request. 
Does it sound reasonable?



Best regards

Göran

*From: *Ace  on behalf of John Mattsson 


*Date: *Monday, 25 October 2021 at 17:03
*To: *Dan Garcia Carrillo , a...@ietf.org 
, EMU WG 
*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), wil

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

[Dan Garcia Carrillo]

ot;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  on behalf of Dan Garcia Carrillo 


*Date: *Monday, 25 October 2021 at 13:27
*To: *a...@ietf.org , EMU WG 
*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, internet-dra...@ietf.org 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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Dan Garcia Carrillo]

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.

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"

- 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  on behalf of Dan Garcia Carrillo 


*Date: *Monday, 25 October 2021 at 13:27
*To: *a...@ietf.org , EMU WG 
*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, internet-dra...@ietf.org 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

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

[Dan Garcia Carrillo]

cation 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  on behalf of John Mattsson 


*Date: *Monday, 25 October 2021 at 17:03
*To: *Dan Garcia Carrillo , a...@ietf.org 
, EMU WG 
*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  on behalf of Dan Garcia Carrillo 


*Date: *Monday, 25 October 2021 at 13:27
*To: *a...@ietf.org , EMU WG 
*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 

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

[Dan Garcia Carrillo]

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  on behalf of John Mattsson
    
    *Date: *Monday, 25 October 2021 at 17:03
*To: *Dan Garcia Carrillo , a...@ietf.org
, EMU WG 
*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

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

[Daniel Migault]

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  on behalf of John Mattsson
> 
> *Date: *Monday, 25 October 2021 at 17:03
> *To: *Dan Garcia Carrillo , a...@ietf.org <
> a...@ietf.org>, EMU WG 
> *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 suc

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

[Göran Selander]

, 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  on behalf of John Mattsson 

Date: Monday, 25 October 2021 at 17:03
To: Dan Garcia Carrillo , a...@ietf.org , 
EMU WG 
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  on behalf of Dan Garcia Carrillo 

Date: Monday, 25 October 2021 at 13:27
To: a...@ietf.org , EMU WG 
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, internet-dra...@ietf.org escribió:
> A new version of I-D, draft-ietf-ace-wg-coap-eap-04.txt
> has been successfully submitted by Dan Garcia-Carril

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

[John Mattsson]

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  on behalf of Dan Garcia Carrillo 

Date: Monday, 25 October 2021 at 13:27
To: a...@ietf.org , EMU WG 
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, internet-dra...@ietf.org 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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Dan Garcia Carrillo]

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, internet-dra...@ietf.org 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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu