Hi Alan,
Thank you very much for your time to review the document and for the
clarifications.
On 5/7/23 15:36, Alan DeKok wrote:
On Jul 5, 2023, at 4:09 AM, Eliot Lear via Datatracker <nore...@ietf.org> wrote:
3. The terminology is a problem. On the one hand, some people like
to use the terms "IoT Device" and "Controller". In the EAP world,
this term is meaningless. We use "peer", "authenticator", and
"authentication server". I would suggest that those implementing this
work will be from the EAP world, and that this document will be far
more accessible to them if those terms are used.
I agree. My $0.02 is that there are very few stand-alone EAP authentication
libraries suitable for integration into CoAP. I suspect that most use-cases
will proxy the EAP packets to an AAA server.
Some more nit-picks on text:
Section 2:
The IoT device will act as a CoAP server for this service, and the EAP
authenticator as a CoAP client. The rationale behind this decision, as expanded
later, is that EAP requests go always from the EAP server to the EAP peer.
Accordingly, the EAP responses go from the EAP peer to the EAP server.
I don't know that this issue of "who gets the request or response" matters.
In RADIUS, the Access-Request packet contains the EAP response. That's fine.
i.e. the EAP layer shouldn't change the role of the parties in a CoAP
conversation. If the IoT device is normally the CoAP client, then just keep it
as the CoAP client for EAP. it's fine.
This design choice was part of an initial discussion, and we considered
this possibility.
https://mailarchive.ietf.org/arch/msg/ace/5PkNSpcWm-5U9bTRGwB96Uk7xcc/
The reasons for this choice were, basically, 1) reduce the complexity of
the EAP client, leaving the responsibility for re-transmitting EAP
requests to the CoAP client. 2) Reduce the complexity of the security
association exchange.
In any case, we understand that having an initial message as a trigger
is not new. We have a similar case for EAPOL-Start. In the CoAP-EAP case
is the simplest message possible, without having to confirm nor
acknowledge the first message.
It is worth noting that the CoAP client (EAP authenticator) MAY interact with a
backend AAA infrastructure when EAP pass-through mode is used, which will place
the EAP server in the AAA server that contains the information required to
authenticate the EAP peer.
When the EAP packets are proxied to an AAA server, the keying material comes
back in the attributes MS-MPPE-(Send/Recv)-Key. RFC 5216 Section 2.3 defines
those attributes as containing the MSK. This document should explain that
connection, reference 5216, and explain how to derive the MSK from the MS-MPPE
keys.
Reading the document shows an unclear discussion of what is meant by "keying
material". Perhaps the text could be updated to explain this:
EAP methods transported in CoAP MUST generate cryptographic material [RFC5247]
in an MSK for this specification. The MSK is used as the basis for further
cryptographic derivations.
And later:
For this specification, the EAP method MUST be able to derive keying material
(MSK).
Thank you for this comment, we will review the explanation of the key
derivation in the document.
Section 3:
In CoAP-EAP, the IoT device (EAP peer/CoAP server) will only have one
authentication session with a specific Controller (EAP authenticator/ CoAP
client) and it will not process any other EAP authentication in parallel (with
the same Controller)
It may be worth noting that the controller may have parallel EAP sessions
with multiple IoT devices. Just to make it very clear that the limitation on
the IoT device is not a limitation on the Controller.
Yes, you are correct. This should be better explained, thank you.
Section 3.2:
The message also includes a URI in the payload of the message to indicate to
what resource (e.g. '/a/x'
It would be good to give guidance here on choosing the URI. The examples of "a/x" and
then "a/y" are generic, but could give insufficient guidance to implementors.
Perhaps it is worth suggesting that the implementors choose a URI with a
common format, which can aid with implementation and administrator debugging.
The resource could be "path/eap/counter". e.g.
* "path" is some local path on the device to make the path unique. This could
be omitted if desired.
* "eap" îs the name which indicates that the URI is for the EAP peer. This has
no meaning for the protocol, but helps with debugging.
* "counter' which is an incrementing unique number for every packet.
So the examples can use "path/eap/1", and then "path/eap/2", etc.
Without such a suggestion, there is a temptation for implementors to come up
with their own schemes, which are likely to be worse that this one. e.g. just
using the same URI every time, or deriving the URI from some kind of hash, etc.
Thank you for this suggestion, we will incorporate this clarification as
well to the document.
Section 3.3:
When the CoAP-EAP state is close to expiring, the IoT device MAY want to start
a new authentication process
Nit: I don't think MAY needs to be uppercase here.
Thank you, we will lowercase it.
Section 6.1:
Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 octets or
greater. CoAP assumes an upper bound of 1024 for its payload which covers the
requirements of EAP
To address Eliots comments this should be fine. But it should be highlighted
more strongly.
I would also suggest adding a note that when EAP is proxied over an AAA
framework, the Access-Request packets MUST contain a Framed-MTU attribute with
value 1024. This attribute signals the AAA server that it should limit is
responses to 1024 octets.
If the Framed-MTU attribute isn't included, then the AAA server could assume
that the EAP packets are going over Ethernet, and assume an MTU ion 1536
octets. Which will cause this specification to silently break.
It's also worth discussing AAA issues in more detail. e.g. what to do when
the AAA server doesn't reply. Does the Controller silently drop the EAP
session? Does it send a notification to the IoT device that this has happened?
Thank you for the clarification and for bringing the discussion about
the possible issues. We will address them as well in the next version of
the document.
Regarding the behavior of the Controller in case the AAA server does not
answer, we try to cover the situation in the section 3.5.2.
Non-responding endpoint, but we will add the AAA not responding to the
possible reasons why the devices may become non-responding.
Section 6.2:
On the other hand, when taking into account the EAP method overload, this
reduction is less but still significant if the EAP method generates large EAP
messages. If the EAP method is very taxing, the impact of the reduction in the
size of the EAP lower layer is less significant.
I'm not clear what this discussion means.
Sorry about this, we should re-write this for clarity.
The basic idea here was to relativize the EAP lower layer overhead. If
the EAP method has a lot and very large messages, using an EAP lower
layer that saves 10-40 bytes may not matter very much. On the other hand
if EAP methods have few and short messages, this becomes more relevant.
This becomes more relevant in very constrained networks.
Given that the EAP packets can be forced to be no more than 1024 octets, the
only difference between EAP methods is the number of packets exchanged, and the
total amount of data exchanged. Current EAP supplicants and authenticators
limit the total number of exchanges to 50 or 100, depending on various factors.
Is there a similar limit for CoAP? i.e. will CoAP go fail if there is 64K
of data being exchanged in EAP?
We tried not to go there in the document, just to acknowledge that CoAP
fits the requirements for an EAP lower layer. In any case, EAP messages
larger than 1024 could be sent using CoAP Block-wise transfer, that will
seamlessly take care of sending payloads larger than CoAP Minimum MTU.
This leads to the conclusion that possible next steps in this field could be
designing new EAP methods that can be better adapted to the requirements of IoT
devices and networks.
I'm wary of such a suggestion. EAP is widely used outside of CoAP. Adding
new EAP methods also means that those EAP methods can be used in other
circumstances, which don't have the transport security / reliability provided
by CoAP.
Other EAP methods which may be suitable for CoAP include EAP-PWD, which is
also small and has few exchanged. Even EAP-TLS may not be that bad, as EAP-TLS
provides for PSK authentication.
You are correct. we will remove this statement from the document to
avoid limiting the applicability.
Even when certificates are used, the total packet exchanges are ~18 rounds,
and maybe 20K or so. Session resumption is reduces that to maybe 4 rounds, and
a few K of data.
Would that be too much for this use-case?
This should be fine, as with CoAP block-wise transfers would manage this.
Thank you.
Alan DeKok.
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
