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 protected]
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
