Re: [Emu] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt
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 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
Re: [Emu] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt
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
