Subject: Re: [Ace] WGLC for draft-ietf-ace-wg-coap-eap-02

From: Dan Garcia Carrillo <[email-masked]>
Date: Thu, 1 Jul 2021 19:21:50 +0200

Hi Carsten,

Thank you very much for contributing to the discussion.

El 6/20/2021 a las 1:50 PM, Carsten Bormann escribió:
> Hi Mohit,
>
> great review!
>
> There are a few places where I think you might be overcompensating, or where we actually have found good solutions previously that could be applied here.
>
> […]
>> "The URI of the CoAP-EAP service CAN be set to "/b"? First,
>> "CAN" is capitalized but it is not in the list of keywords defined by
>> RFC 2119/RFC 8174.
> Right.  As per BCP190, “/b” should really be qualified as an example (and it would be weird to choose an example that cannot actually be used, so that choice implies that it “can” be used).
> See https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/
> for an example how this can be worded (this uses “/rd” for its examples).
>
> Note that the resource directory also defines /.well-known/rd, to aid clients to operate on it *before* discovery has been completed.  Here this is different from the lookup interface that is shown to be under “/rd” in the examples.
>
> I have no idea whether EAP over CoAP needs such a well-known path; that depends on whether the discovery that leads to operating on this resource provides a full URI (in which case the server can freely choose the path, no need for a well-known one) or just the IP address (in which case the client needs to be able to construct a URI from just that IP address).

To ease the access to the service for both entities we will set up 
the///URI /(to be established definitely after consensus) for example 
//.well-known/b /for the start of the process. After that, as already 
shown in the document, the CoAP server will establish the resources to 
which the client has to access to continue the authentication process.

>> Add a reference to RFC 8174 in section 1.1. Besides, you already use
>> "MAY"/"MUST" in section 1. For example, the text says: "The CoAP client
>> MAY contact with a backend AAA infrastructure to complete the EAP
>> negotiation as described in the EAP specification [RFC3748]" but "MAY"
>> is defined as a keyword only later?
> I don’t think this is a problem for a brief section that precedes the terminology.
>
>> "The assumption is that" -> instead just say EAP methods used in this
>> specification MUST generate key.". Standards specifications don't make
>> assumptions and rather dictate what implementations/deployments should do.
> I would be careful with restating a MUST from a base standard.  Sometimes semantic differences creep in, and this creates a special flavor of the base standard, even if that is not intended.  Here, it is probably best to factually state that EAP methods generate a key.  Or, if that is meant, that this specification MUST NOT be used with EAP methods that do not generate a key.

Thank you, we will change the wording to avoid issues.

>
>> I don't fully understand the logic behind having separate resources for
>> each request.
> The idea is to separate protocol runs.  Allowing the attacker to confuse the parties about their protocol runs is one of the leading sources of vulnerabilities.
>
>> I read Christian Amsüss's CoAP FAQ on this. It helped a
>> bit but I am not sure why this is needed since RFC 3748 says: "EAP
>> provides its own support for duplicate elimination and retransmission."?
> Well, EAP over CoAP replaces that part of EAP, so indeed the functionality needs to be provided here.

Just to clarify something that may cause confusion, we are not replacing 
or altering the EAP state machine.  Just we consider we are using a 
reliable EAP lower layer.

>> Why can't you send the identity already in the first POST message from
>> the device. AFAIK, a separate Identity request and response is not
>> necessary. You'll save on one round trip? This will also help the
>> authenticator to decide already on the first message if it should
>> continue or not (depending on the domain name in the NAI)?
> I think that reducing round-trips may be a valid way to optimize EAP, but I’m not sure that what you propose is always possible.

Indeed, as we commented in the anser to Mohit, while we looked into this 
possibility of sending the NAI in the first message in an LPWAN 
deployment. (https://www.mdpi.com/1424-8220/17/11/2646).

We agree with you in that we might find implementations that will send 
by default the EAP Request and Response Identity and we would be forcing 
to change this behaviour to fit our lower layer impelentation.

>> Section 3.3: casuistics -> interesting choice of words. At least I had
>> to lookup the meaning.
> It is best to avoid words that most people have to look up…
I agree, best to keep it simple.
>> MSG-ID -> Not used in RFC 7252 so I recommend that you should not use it
>> either. Also, perhaps adding a bit more context would not hurt. For
>> example, Message Id in CoAP is used for....... In CoAP-EAP, the Message
>> Id can be used for ..... You have also used MSGID (vs. MSG-ID) in the
>> document.

We will use the same  nomenclature for this.

> The message-id is not available at the service interface of CoAP.  But it may be useful to say that CoAP itself will make use of message-IDs to do deduplication etc.
>
>> IANA Considerations section only says TBD.?? I would have thought that
>> it would be complete before issuing the working group last call?
> Indeed!  It is important to see what registries/extension points EAP-CoAP uses and what it provides.

We will add this to the document.

> Grüße, Carsten
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace