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