On Oct 4, 2024, at 12:46 PM, Heikki Vatiainen <h...@radiatorsoftware.com> wrote: > For me it seems section 3.4.1 title should be 'EAP Peers' and section 3.4.2 > 'EAP Servers'. This would also require carefully updating some instances of > 'peer' to 'server' and all mentions of 'supplicant' to 'peer'. I don't think > there is an intention to make a difference between 'EAP peer' and > 'supplicant', or is there?
Yes, I'll fix it up to be "peer" for supplication, and "server". > EAP method negotiation > +++++++++++++++++ > If the EAP peer (client) attempts provisioning with an identity ending with > eap.arpa and gets back an EAP request for a method for which it has > credentials, should it stop the provisioning and restart the link to start a > completely new EAP authentication? Or even if the request is for an EAP > method that supports provisioning, the client shouldn't proceed because it > would be provisioning for method X while it's identity indicates method Y I'd argue that should be forbidden. Either the server agrees to the provisioning method, or rejects it. Some of the new text I'm adding explains that there's no negotiation possible for provisioning methods. So that negotiation needs to be done in each individual EAP method. > That is, switching to a non-provisioning fully credentialed authentication > with a NAK shouldn't be done when the initial EAP-Response/Identity contains > an eap.arpa domain. Also, when provisioning is done, the EAP method must > match the eap.arpa domain. > > My main concern is that the EAP identity could easily end up in logs with > eap.arpa domain while the EAP authentication and network access was granted > after a non-provisioned authentication. I'm not sure how that would work. The eap.arpa domain should result in limited network access. Any credentials with get provisioned are just normal credentials, and will get whatever network access is appropriate. How is " network access was granted after a non-provisioned authentication" ? > A client that doesn't mind doing method switching with a EAP server that > knows nothing about eap.arpa could still do it, but a server that knows about > eap.arpa probably shouldn't allow this to happen. Agreed. > There's more about NAKs on the list in messages discussing > draft-ietf-emu-bootstrapped-tls-06 comments, including comments Alan is > considering for this draft. I'll try to publish a new draft early next week. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
