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

Hi Mohit:

First of all, thank you very much for review. It is really appreciated 
and will help to improve the document.

Please see our comments inline

El 6/20/2021 a las 11:14 AM, Mohit Sethi M escribió:
> 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.

[Authors] Following your advice, we will polish the document in order to 
make the language more precise.

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

[Authors] Correct.

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

[Authors]  Let’s change this as you suggest.

> Add a reference to RFC 8174 in section 1.1.
[Authors] Ok
> 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?
[Authors] We will  change the text so it is consistent.
> 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.

[Authors] We believe that EAP-CoAP may cause some confusion because:

- Typically EAP methods names start with EAP-X hence, therefore it could 
be considered as EAP-CoAP method instead of  a lower layer

- Regarding the encapsulation order, if we take as an example an EAP 
method, EAP-TLS for instance, EAP encapsulates the TLS  method and EAP 
goes before in the name. This would still apply for CoAP-EAP as CoAP 
encapsulates EAP.

> "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.
[Authors] Ok, let us rephrase this as:

"The CoAP client has the option of contactinga backend AAA 
infrastructure to complete the EAP

negotiation as described in the EAP specification [RFC3748]"

> Expand OSCoRE to Object Security for Constrained RESTful Environments.

[Authors] Ok, done.

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

[Authors] Yes. We mentioned EAP authenticator based on this text in RFC 
3748:

"Within this document, authenticator requirements apply regardless of

    whether the authenticator is operating as a pass-through or not.

    Where the requirement is meant to apply to either the authenticator

    or backend authentication server, depending on where the EAP

    authentication is terminated, the term "EAP server" will be used."

But we also agree with you that it is clearer to say EAP server.

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

[Authors] We tend to agree here. Taking into Carsten’s comments and 
yours, it is important to have a well-known path because the controller 
needs to start the process to a well known URI.

Perhaps, we could have something as /.well-known/b would save bytes.

We need to consider having the same value in both Controller and IoT 
device, since the first message goes from the IoT device to the 
Controller acting as CoAP client and server respectively. All the 
following exchanges after that the Controller asumes the role of CoAP 
client.

So, in order to allow both entities to access to this service in the 
first message they would need to resort to a pre-establish URI like 
//.well-known/b/

After that, the CoAP server would continue as explained in the general 
flow of operation, telling the CoAP client the localtion path to use in 
the next exchange.

> Language issue: " signalling the intention the EAP peer"

[Authors] How about this …

"The use of this option will indicate to the EAP authenticator that the 
EAP peer is ready to start the authentication process."

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

[Authors]Thank you for the suggestion. Let us rephrase it as follows:

"Once the EAP authenticatior is aware of the intention of the EAP peer 
of starting an authentication process, The EAP authenticator acting as 
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?
[Authors] How about this:

"This CoAP server can select this value as pleased. The only condition 
is that both end points have to correctly process the following message 
based on the selected value."

> have an ongoing authentication -> one authentication session?

[Authors] Yes, we only consider one. We will rephrase this aswell.

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

[Authors] Yes, RFC 3748 says this however there is also another 
important aspect related with this. In first place, that text also mentions:

EAP provides its own support for duplicate elimination and 
retransmission, but is reliant on lower layer ordering guarantees.

Then the RFC talks about “reliable lower layer”. CoAP is reliable and it 
is used as lower layer in our document. In fact, we have:

"Possible duplication.  Where the lower layer is reliable, it will

        provide the EAP layer with a non-duplicated stream of packets.

        However,  while it is desirable that lower layers provide for

        non-duplication, this is not a requirement.

CoAP is providing non-duplicated stream of packets and accomplish 
“desirable” non-duplication.

"Ordering guarantees.  EAP does not require the Identifier to be

        monotonically increasing, and so is reliant on lower layer

        ordering guarantees for correct operation. “

CoAP is providing this in the way we have describe CoAP-EAP.

Regarding retransmission is also said:

When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as

    within [PIC]), the authenticator retransmission timer SHOULD be set

    to an infinite value, so that retransmissions do not occur at the EAP

    layer.

In our specific case, we specifically use the reliability mechanisms of 
CoAP, which requires the use Confirmable requests. Furthermore, to save 
bytes and reduce the number of messages we also specify that we expect 
to receive piggybacked responses, which requires that the request was 
carried in a Confirmable request.

By using the reliabilty mechanisms, we can set the EAP retransmissions 
to infinte which delegates the responsibility of the retransmissions 
onto the 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)?

[Authors] This in fact is something that we evaluated in a different 
implementation of the protocol for LPWAN which has very high constraints 
(https://www.mdpi.com/1424-8220/17/11/2646 
<https://www.mdpi.com/1424-8220/17/11/2646>) .

We agree with you in this case that would be useful, but I think it is 
would be good to have the opportunity of forcing the exchange of these 
two messages at the Controller's discrection at least. So avoing an IoT 
device blindly sending POST messages that require the creation of a 
CoAP-EAP state in the EAP authenticator as well as an EAP state machine 
state in the EAP server without knowing if the EAP peer is capable of 
engaging in a minimal conversation.

> Section 3.3: casuistics -> interesting choice of words. At least I had
> to lookup the meaning.
[Authors]  Sorry about that, as Carsten said, it is not good to use 
language that needs to be looked at in the dictionary.
> 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.
[Authors]  We will correct this and provide additional context.
> "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?

[Authors]  Sure, lets change it as you suggest, it might help make the 
example more clear.

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

[Authors]  We will clarify that in the text. By internal tracking it was 
intended to conve the idea is that the CoAP messaging layer takes care 
of retransmissions without sending the information the the application 
if not needed.

> Perhaps rename Master Key Session (MSK) to Main Session Key (MSK)
[Authors]  We are referring to the Master Session Key derived from the 
EAP Key Management Framework.
> AS -> never expanded before or introduced properly? what is it referring
> to? Is AS the authenticator or backend server?
[Authors]  We refer to the  Authorization Server (AS) of the ACE 
framework. we will elaborate more in the text.
> 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?

[Authors]  You are right. The text  should establish how the process is 
done.

> KDF can be AES-CMAC-PRF-128? What if some other KDF is used?

[Authors]  This is a good point.

Given the fact that we are using OSCORE as Security Association we will 
change the specification to the same crypto suites used in OSCORE.

Understanding that IoT devices can be limited, we intended  to have no 
negotiation, going for the default crypto suites algorithms.

If negotiation is something we really want, we should add to the first 2 
messages carrying EAP, an additional Option to exchange the list of 
prefered cryptosuites by the Controller in the first one, and the chosen 
cryptosuite by the IoT device in the second one.

This could contrast with the initial discussion that was had regarding 
the definition of additional CoAP options, and if they were necessary.

A possible solution for this would be to have this information available 
in the AAA server alongside the credentials of the device, making the 
negotiation unnecessary for this case.

What do you think?

>   Shouldn't
> labels be registered with IANA somehow? What if my implementation uses
> "IETF_MASTER_SECRET_FOR_OSCORE"
[Authors]  That is a good point. I have looked in other RFCs but no 
explicit mention of labels are done for IANA. We will check this.
> "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?
[Authors] Good point here. The peer-id in this case would be the NAI.
> 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
[Authors]  Sorry about that, It should be in the list.
> "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?
[Authors]  Yes, indeed. In fact, we ought to change the cryptosuites to 
the ones specified by OSCORE as we are explicitly saying we are 
establishing an OSCORE security association after a successful 
authentication. The choice is based on the requirement of the use of 
OSCORE.
> 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.

[Authors] We will do that, thank you.

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

[Authors] We will change this.

Thank you again,

Best Regards.

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