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 protected]> wrote: > Hello authors of draft-ietf-ace-wg-coap-eap, > > > > Thanks for working with this draft. Here is a mix of nits/editorials and > more substantial comments in the order as they appear in the draft. > > > > > > Abstract > > > > OLD > > One of the primer goals is to > > NEW > > One of the main goals is to > > > > > > Section 1. > > > > "EAP methods transported in CoAP MUST generate cryptographic material > > [RFC5247] for this specification. " > > > > The term “cryptographic material” is used multiple times in this document > but is not defined. RFC 5247 uses “keying material”, does that match the > intended meaning? > > > > > > Section2. > > > > Figure 1 is perhaps too informative containing endpoints, stacks, what is > CoAP, and scope of this document. There is no line/arrow between IoT Device > and Controller, presumably because there is too much other information. > Section 2 don’t talk about the stack at all. > > > > * Proposal: Make two figures: one with nodes and lines/arrows > (“architecture”); another with the stack, which is essentially the same in > the two nodes in scope of this document. > > > > * It is confusing that CoAP role allocation is shown in the figure since > those only apply to one step of the operation in section 3.2. In all other > steps the roles are reversed. Proposal: omit the CoAP roles in the figure, > and/or provide an explanation in section text or caption. The section text > talking about CoAP client also needs to be modified accordingly. > > > > * Nit: RFC8323 calls the layer between request/response and reliable > transport “message framing”. Perhaps you want to have a common layer > renaming the "Messages" layer with “Message /framing/”. > > > > > > > > Section 3. > > > > "It is RECOMMENDED a light EAP method for the case of constrained link and > constrained IoT devices." > > > > If this will remain a normative recommendation, then there needs to be a > definition (reference) of "light EAP method". Perhaps consider just explain > the intention of "light" ("lightweight"?) and remove the normative > recommendation? > > > > --- > > > > OLD > > The article [eap-framework], highlights the benefits of the EAP > > framework. > > NEW > > The benefits of the EAP framework are highlighted in [eap-framework]. > > > > > > 3.1 > > > > "resource directory" > > Provide a reference or at least as an example, like > draft-ietf-core-resource-directory, > > > > --- > > > > OLD > > Example of this protocols > > NEW > > Example of such protocols > > > > > > > > 3.2 > > > > Step 0 > > > > "The message also includes an URI in the payload of the message to > indicate to what resource (e.g. '/a/x') the Controller MUST send the first > message with the EAP authentication" > > > > The DoS issues with requiring the Controller to send a message to an > unknown URI need to be considered. > > > > > > Step 1 > > > > "the Sender ID for OSCORE selected by the Controller" > > > > Is this the Sender ID *of the IoT device* selected by the Controller? In > other words, is it the Recipient ID of the Controller selected by the > Controller? That would correspond to how OSCORE identifiers are chosen in > EDHOC: > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#section-3.3.2 > > > > Best not to use the terms "SID" or "RID" unqualified in message fields > since they are reversed on the IoT device and Controller. Better use > terminology like e.g. RID-I and RID-C for RID of IoT device and Controller, > respectively. > > > > > > Step 2 > > > > "the EAP response, the Recipient ID and the selected ciphersuite for > OSCORE are in the payload." > > > > Is this the Recipient ID *of the IoT device*? See comment above. > > > > --- > > > > OLD > > In this step, the IoT device MAY create a OSCORE security context with the > Sender ID and Recipient ID. > > NEW > > In this step, the IoT device MAY create a OSCORE security context with its > Sender ID and Recipient ID. > > > > > > Step 7 > > > > OLD > > The reception of the POST message protected with OSCORE using the Sender > ID sent in Step 1 is considered by the IoT device as an alternate > indication of success ([RFC3748]). > > > > The unqualified "Sender ID" is confusing here. Why does the ID sent in > step 1 indicate success to the IoT device? I would expect the ID selected > by the IoT device itself and sent in step 2, if used by the Controller to > derive the OSCORE security context to protect the message in step 7 would > be a stronger indication of success. Proposal (check if this is correct): > > > > NEW > > The reception of the POST message protected with an OSCORE security > context derived using the Recipient ID of the IoT device sent in Step 2 is > considered by the IoT device as an alternate indication of success > ([RFC3748]). > > > > --- > > > > "The communication with the last resource (e.g. '/a/w') from this point > MUST be protected with OSCORE except during a new (re)authentication (see > Section 3.3)." > > > > I don't understand why there is an exception. OSCORE seems to be applied > to communication with the last resource in all cases: > > > > * In the case of new authentication the procedure explained in Section 3.2 > applies protection with OSCORE in communication with the last resource. > > * In the case of re-authentication, the procedure is explained in Section > 3.3 to be "exactly the same" as in Section 3.2. > > > > Also I find the expression "new (re)authentication" confusing - what is > the the difference between "re-authentication" and "new re-authentication"? > > > > > > Section 4. > > > > " 1. SID: It contains the Identifier for the Sender ID to be used in > > the OSCORE security context. > > > > 2. RID: It contains the Identifier for the Recipient to be used in > > the OSCORE security context." > > > > Same comment as above to qualify SID and RID: is SID the Sender ID of the > IoT device or of the Controller? > > > > > > > > Section 5.1 > > > > "If the Controller sends a restricted list > > of ciphersuites that is willing to accept, and the ones supported by > > the IoT device are not in that list, the IoT device will respond with > > a '4.00 Bad Request', expressing in the payload the ciphersuites > > supported. " > > > > > > Make clear (here or in a security consideration) that in case of an error > message containing a cipher suite, the exchange of cipher suites between > EAP authenticator and EAP peer cannot be verified. For example, a > man-in-the-middle could replace cipher suites in either message which would > not be noticed if the protocol is ended after step 2. > > > > > > Best regards > > Göran > > > > > > *From: *Ace <[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 > -- Daniel Migault Ericsson
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
