On Tue, 1 Oct 2024 at 16:26, Alan DeKok <al...@deployingradius.com> wrote:
> Perhaps:
>
> # EAP Peers
>
> An EAP session begins with the peer receiving an initial
> EAP-Request/Identity message. An EAP peer supporting this
> specification MUST examining the identity to see if it uses the eap.arpa
> realm. If not, the EAP peer MUST process the request normally.
>
These paragraphs look good, but I'd use 'EAP server' instead of 'EAP peer'
and 'EAP peer' instead of 'EAP supplicant'. I have a similar suggestion
for draft-ietf-emu-eap-arpa too. This is to match the EAP RFC's use of
'peer', 'server', 'supplicant' and 'auhenticator'.
> The EAP peer MUST check that the NAI matches an EAP method which is
> current supported. If the EAP peer receives a malformed NAI in the
>
s/current/currently/ or simply s/current//
> eap.arpa domain, it MUST reply with an EAP Failure, as per {{RFC3748,
> Section 4.2}}. If the EAP peer receives an NAI for an EAP method
> which the peer does not support, it MUST reply with a NAK as per
> {{RFC3748, Section 5.3}}.
>
Above 'EAP peer' seems correct since it's the EAP peer (client) that sends
NAKs.
> However, the situation is more difficult if the EAP supplicant signals
> an NAI for an EAP method which is supported by the peer, but which
> contains a provisioning method which the peer does not support. The
> normal EAP NAK signalling allows selection only of a different EAP
> method, but offers no way to signal that a different provisioning
> method should be used.
>
Request routing based on NAI's username component might help here. For
example, varia...@method.eap.arp gets routed to a different EAP server than
varia...@method.eap arpa.
> Specifications which define provisioning for an EAP method therefore
> SHOULD provide a process by which implementations can negotiate a
> mutually acceptable provisionng method.
>
> Once the peer accepts the provisioning method, it then replies with an
> EAP method which matches the one proposed by the supplicant in the
> NAI. The EAP process then proceeds as per the EAP state machine
> outlined in {{RFC3748}}.
>
> ...
>
>
--
Heikki Vatiainen
h...@radiatorsoftware.com
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
