Dear Göran,
Thank you for taking the time to review the document. We found your
comments very helpful to improve the text.
Please find the responses to your comments inline.
Best Regards,
CoAP-EAP authors.
On 25/11/21 10:09, Göran Selander wrote:
Hello authors of draft-ietf-ace-wg-coap-eap,
Thanks for working with this draft. Here is a mix of nits/editorials
and more substantial comments in the order as they appear in the draft.
Abstract
OLD
One of the primer goals is to
NEW
One of the main goals is to
[authors] Fixed.
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?
[authors] Yes, we agree on this. We will use “keying material” instead.
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.
[authors] This is a very good point. Thank you for the suggestion. We
will do that for the next version.
* 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.
[authors] This could indeed improve the text, we will simplify this in
the figure and explain it in the text. In fact, Fig. 2 does not show the
CoAP role.
* 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/”.
[authors] Yes, that’s right. We will apply this change..
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?
[authors] Yes, your suggestion makes sense. We will apply it.
---
OLD
The article [eap-framework], highlights the benefits of the EAP
framework.
NEW
The benefits of the EAP framework are highlighted in [eap-framework].
[authors] Thank you. We will rephrase it that way.
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
[authors] Thank you. We will rephrase it that way.
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.
[authors] Yes, we will add this to the security considerations section
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.
[authors] Yes, we understand this might be confusing and we agree with
you that using RID-I and RID-C is the right way of expressing it to
avoid this confusion.
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.
[authors] We believe that with your suggestion this ambiguity will
disappear.
---
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.
[authors] Thank you. We will rephrase it that way.
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]).
[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 <[email protected]> on behalf of John Mattsson
<[email protected]>
*Date: *Monday, 25 October 2021 at 17:03
*To: *Dan Garcia Carrillo <[email protected]>, [email protected]
<[email protected]>, EMU WG <[email protected]>
*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 protected]> on behalf of Dan Garcia Carrillo
<[email protected]>
*Date: *Monday, 25 October 2021 at 13:27
*To: *[email protected] <[email protected]>, EMU WG <[email protected]>
*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 protected] 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 protected]
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
