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

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 17 Jun 2021 21:25:22 +0400

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.

---

From: Mohit Sethi M <[email-masked]>
Date: Sun, 20 Jun 2021 09:14:26 +0000

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

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 20 Jun 2021 13:50:33 +0200

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

> is defined as a keyword only later?

I don’t think this is a problem for a brief section that precedes the terminology.

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

> 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 

Well, EAP over CoAP replaces that part of EAP, so indeed the functionality needs to be provided here.

> 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 

It is best to avoid words that most people have to look up…

> Id can be used for ..... You have also used MSGID (vs. MSG-ID) in the 

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.

> 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

---

From: Dan Garcia Carrillo <[email-masked]>
Date: Fri, 25 Jun 2021 20:16:40 +0200

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ó:
> 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
> Please expand eap, coap, and IoT on first usage in abstract.

[Authors] Correct.

>   It's not

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

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

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

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

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

> Regardless of whether a No-response option is used, the CoAP client

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

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

> 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
[Authors]  Sorry about that, as Carsten said, it is not good to use 
language that needs to be looked at in the dictionary.
> Id can be used for ..... You have also used MSGID (vs. MSG-ID) in the
[Authors]  We will correct this and provide additional context.
> MSG 1 is best representation in the figure. Perhaps EAP-X-Req 1 and

[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.
> 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.
> 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
[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.
> 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.
> CoAP-EAP already exists :https://www.youtube.com/watch?v=rPuFKoihl5E
[Authors]  Sorry about that, It should be in the list.
> 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.
> original RFC 5247 does not use this acronym so I recommend you avoid it

[Authors] We will do that, thank you.

> https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-lower-layers.

[Authors] We will change this.

Thank you again,

Best Regards.