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.
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
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}}.
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.
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}}.
...
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
