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

The document is currently intended for standards track publication. But 
both the abstract and the introduction mention "describes a service".  
You don't describe a standards specification. You define it? Moreover, I 
find the entire tone of the document to be somewhat lacking for a 
standards track publication. For example, there is text in the document 
which says "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. What if the URI is something different? How are 
devices supposed to interoperate? I would recommend to either make the 
language more precise or publish this as informational. However, I leave 
the final decision to the chairs and the AD. I don't want to be an 
impediment to the publication of this document.

Please expand eap, coap, and IoT on first usage in abstract. It's not 
great to have bullet lists in abstracts. Also, the capitalization of 
some words looks odd. For example, why "Security Associations" is 
capitalized?

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 also wonder if CoAP-EAP reflects the correct sequence of protocols. 
EAP is encapsulated in CoAP. Shouldn't it be called EAP-CoAP? Maybe it's 
too late to change that now.

"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.

Expand OSCoRE to Object Security for Constrained RESTful Environments.

Section 2:  "The rationale behind this decision, as we will expand 
later, is that EAP requests go always from the EAP authenticator to the 
EAP peer.". I think the more correct terminology here is that EAP 
requests are always sent from the EAP server to the EAP peer.

CoAP-EAP service CAN be set to "/b" to save bytes over the air. Wouldn't 
it make sense to standardize this. For example: /.well-known/bootstrap? 
You'll need to define URI scheme syntax and semantics but it would go a 
long way in helping interoperability.

Language issue: " signalling the intention the EAP peer"

Section 3.1: "In any case," -> Not clear. Please rephrase. For example: 
Regardless of whether a No-response option is used, the CoAP client 
sends ....

"This CoAP server can select this value as pleased, as long as, it 
serves to process the following message adequately."  -> Hard to parse 
this sentence. Which server? which value?

have an ongoing authentication -> one authentication session?

I don't fully understand the logic behind having separate resources for 
each request. 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."?

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)?

Section 3.3: casuistics -> interesting choice of words. At least I had 
to lookup the meaning.

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.

"unauthorized communications from the IoT device towards the Controller 
within the security domain." -> I think the more likely repercussion is 
that there will be no access to the network, services, and resources for 
the IoT device.

Not clear which message is lost in Figure 4. I also don't know if EAP-X 
MSG 1 is best representation in the figure. Perhaps EAP-X-Req 1 and 
EAP-X-Res 1?

Please explain what is meant by "due to internal tracking"

Perhaps rename Master Key Session (MSK) to Main Session Key (MSK)

AS -> never expanded before or introduced properly? what is it referring 
to? Is AS the authenticator or backend server?

Key material needed to derive the OSCORE Security Context, from the MSK 
can be done as follows:? What if it is not done as follows?

KDF can be AES-CMAC-PRF-128? What if some other KDF is used? Shouldn't 
labels be registered with IANA somehow? What if my implementation uses 
"IETF_MASTER_SECRET_FOR_OSCORE"

"The ID Context can be set to the identity of the EAP peer"? Is it the 
NAI? Is it the identity associated with the EAP peer credentials 
(example: PSK identity or the identity in the TLS client certificate)? 
Is it the Peer-Id? Not all EAP methods export Peer-Id?

Do you mind adding a reference to EAP-NOOB in the list of lightweight 
methods? For full disclosure: I am a co-author of EAP-NOOB. I think it 
is a reasonable example to add given that an implementation with 
CoAP-EAP already exists : https://www.youtube.com/watch?v=rPuFKoihl5E

"Cryptographic suite is not negotiated". I think this is wrong. Many EAP 
methods inherently include cryptographic suite negotiation. I guess what 
you intend to say here is that the KDF used on the MSK is fixed. Why 
AES-CMAC-PRF-128 is the best choice here for IoT devices?

KMF? I guess you are referring to the Key Management Framework. But the 
original RFC 5247 does not use this acronym so I recommend you avoid it 
as well.

IANA Considerations section only says TBD.?? I would have thought that 
it would be complete before issuing the working group last call? At the 
very least you should consider registering CoAP-EAP as a lower layer : 
https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-lower-layers.

--Mohit

On 6/17/21 8:25 PM, Loganaden Velvindron wrote:
> Dear All,
>
> After a quick check with the other working group chair, we are ready
> to proceed to WGLC for:
>
> https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/
>
> Please send your comments to the list.
> The WGLC period will end on the 1st of July.
>
> Kind regards,
> Daniel and Logan.
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace