Sections '3.4.1. EAP Supplicants' and '3.4.2. EAP Peers'
+++++++++++++++++++++++++++++++++++++++
The section title use term 'supplicant' which is not used much by the EAP
RFC 3748. To quote RFC 3748:
peer
The end of the link that responds to the authenticator. In
[IEEE-802.1X], this end is known as the Supplicant.
Supplicant
The end of the link that responds to the authenticator in [IEEE-
802.1X]. In this document, this end of the link is called the
peer.
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?
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.
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.
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.
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.
--
Heikki Vatiainen
h...@radiatorsoftware.com
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
