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). > 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. > 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. > 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. > 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… > 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. 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. Grüße, Carsten _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
