Dear Eliot,
Thank you again for your review.
After your e-mail we think we can consider the following cases:
A) The node does not have an IPv6 address (non IPv6 connectivity)
B) The node does have an IPv6 address (e.g. link-local IPv6 link-local
or IPv6 global address)
It is important to mention that if EAP over a particular link-layer
(e.g. IEEE 802.1X) is already in place for network access, CoAP-EAP can
be used for a secondary authentication for other services, as commented
in C.5.2. (that would be an example of B with IPv6 global address)
In the case of A), we will need support for the transport of CoAP-EAP at
link-layer. For example, in IEEE 802.15.4 networks, a new KMP ID can be
defined in IEEE 802.15.9 to add such support.
In the case of B) we can assume that the device has at least a
link-layer IPv6 address to run CoAP-EAP, be it directly with the
Controller or through an intermediary entity such as proxy, as we
mention in 3.6. Proxy operation in CoAP-EAP. Once the authentication is
completed, we can assign a global IPv6 address to the device. This would
follow a similar model as 6TiSCH Join Protocol or Zigbee IP.
Regarding the case where we intend to add support for CoAP-EAP in mesh
networks, we would follow the same process we either have connectivity
with the Controller, or through an intermediary entity (proxy) that is
already authenticated and can aid in running CoAP-EAP, as discussed in
section 8.3 and in the new text of section C.5.1
To make this possible, as expressed in 8.3. Allowing CoAP-EAP traffic to
perform authentication. "This link MUST authorize exclusively
unprotected IP traffic to be sent between the EAP peer and the EAP
authenticator (or the CoAP proxy) during the authentication with
CoAP-EAP." . We have also added the following text to highlight the
possibility of link-layer support for CoAP-EAP:
"
Alternatively, the link-layer MAY provide support to transport CoAP-
EAP without a IP address by using link-layer frames (e.g. by defining
a new Key Management Protocol ID in IEEE 802.15.9 [ieee802159]).
"
For admission and removal, text in section C.5.1 incorporates now this
discussion.
The resulting added text is the following:
"In the process of joining a network, we may find two cases: 1) the
node does not have an IPv6 address; 2) the node does have an IPv6
address (e.g., link-local IPv6 or IPv6 global address).
In networks where the device is placed and no IP support is available
until the EAP peer is authenticated, specific support for this EAP
lower layer has to be defined to allow CoAP-EAP messages to be
exchanged between the EAP peer and the EAP authenticator. For
example, in IEEE 802.15.4 networks, a new KMP ID can be defined to
add such support in the case of IEEE 802.15.9 [ieee802159]. Where we
can assume that the device has at least a link-layer IPv6 address.
When the EAP peer intends to be admitted into the network, it would
search for an entity that offers the CoAP-EAP service, be it the EAP
authenticator directly, or through the intermediary (i.e., proxy).
See Section 3.1.
CoAP-EAP will run between the EAP peer and the EAP authenticator or
through an intermediary entity such as a proxy, as happens in a mesh
network, where the EAP authenticator could be placed to 1 or more
hops from the EAP peer. In the case a proxy participates in CoAP-
EAP, it will be because it is already a trustworthy entity within the
domain, which communicates through a secure channel with the EAP
authenticator, as illustrated by Figure 11.
Thus, the EAP peer follows the same process described in
Appendix C.5.1 to perform the authentication. As mentioned, we
either have direct link to the EAP authenticator, or through an
intermediary entity (proxy) that is already part of the network
(already shares key material and communicate through a secure channel
with the authenticator) and can aid in running CoAP-EAP.
When CoAP-EAP is completed, and the OSCORE security association is
established with the EAP authenticator, the EAP peer receives the
local configuration parameters for the network (e.g. a network key)
and can configure a global IPv6 address. Moreover, there is no need
of a CoAP proxy after a successful authentication.
For removal, if the EAP authenticator decides to remove a particular
EAP peer from the network or the peer itself intends to leave, either
EAP peer or EAP authenticator can directly send a DELETE command to
explicitly express that the network access state is removed, and the
device will no longer belong to the network. Thus, any state related
to the EAP peer is removed in the EAP authenticator. Forced removal
can be done by sending new specific key material to the devices that
still belong to the network, excluding the removed device, following
a similar model as 6TiSCH Join Protocol [RFC9031] or Zigbee
IP[ZigbeeIP]. The specifics on how this process is to be done, is
out of scope of this document.
+----------+ +----------+ +--------------+
| EAP | | CoAP | | EAP |
| peer |<------>| Proxy |<------------------------->|
authenticator|
+----------+ CoAP +----------+ CoAP +--------------+
OSCORE/DTLS
<--(Security Association)-->
Figure 11: CoAP-EAP through CoAP proxy
Given that EAP is also used for network access authentication, we can
adapt this service to other technologies. For instance, to provide
network access control to very constrained technologies (e.g., LoRa
network). Authors in [lo-coap-eap] provide a study of a minimal
version of CoAP-EAP for LPWAN networks with interesting results. In
this specific case, we could leverage the compression by SCHC for
CoAP [RFC8824]."
Best regards.
El 19/10/24 a las 19:42, Eliot Lear via Datatracker escribió:
Reviewer: Eliot Lear
Review result: Ready with Issues
This is a follow-up to my earlier IoT directorate review. In that review I
raised four issues:
1. Proper illustration of EMSK key derivation (this is somewhat optional)
2. Terminology alignment
3. MTU issues
4. A difference between how EAP is used (e.g., without IP connectivity) and
this work.
All four points have (mostly) been addressed, although I have comments on the
last one. There is a key deployment aspect missing that I would suggest the WG
consider:
When dealing with EAP at the 802.1X layer, since the device doesn't have an IP
address, in effect from the application point of view, and even at certain
kernel layers, the interface is down. That means that no address has been
assigned, and from the network edge standpoint, no IEEE 802.1q VLANs assigned
either.
One complication that remains is this: if the network enables access based on
VLAN assignments, then the L3 address may need to change. Upper layers in the
client need to be prepared for that, and address plans may need to take it into
account. I suggest that some operational cautions be added to address these
points.
In addition, and without going into a whole lot of detail, if this method is
being made use of by a mesh network for permitting access, it must be clear how
both admission and removal are handled; or an applicability statement should be
added that until someone does that work, this document should not be
recommended for such networks.
--
Dan García Carrillo
---------------------
Departamento de Informática, Área de Telemática, Universidad de Oviedo
2.7.8 - Escuela Politécnica de Ingeniería, 33204, Campus de Viesques, Gijón
Tel.: +34 985182654 (Ext. 2654) | email: garciadan@xxxxxxxxx
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
