eap Mailing List: Interoperability Issues with RFC 3748 Expanded Type Methods

[Bernard Aboba (bernard_aboba]

Recently, a number of questions have arisen with respect to the state 
machine and protocol behavior of RFC 3748 Expanded Types.  Below are listed 
some of the questions that I've seen, along with some (potential) answers.  
As far as I can tell, neither RFC 3748 nor RFC 4137 specify the behavior for 
these cases.

1.  What should a conformant EAP peer that supports Expanded Types do if it 
receives an EAP-Request in Expanded Format (Type = 254) specifying a type 
code < 254?

RFC 3748 Section 4.1 says:

     The Type field of a Response MUST either match that of the
     Request, or correspond to a legacy or Expanded Nak (see Section
     5.3) indicating that a Request Type is unacceptable to the peer.

Based on this, I believe the correct behavior is either to send back an 
Expanded NAK (if the proposed method is not supported) or an Expanded EAP 
Response with a type code < 254.

2. What should a conformant EAP server do if it receives an Expanded 
Response in response to an EAP Request with Type Code < 254?

RFC 3748 Section 4.1 says:

     A peer MUST NOT send a Nak (legacy or expanded) in response to a
     Request, after an initial non-Nak Response has been sent.  An EAP
     server receiving a Response not meeting these requirements MUST
     silently discard it.

Based on this, I believe the correct behavior is silent discard.

3. What should a conformant EAP server do if it receives an Expanded NAK in 
response to an EAP Request with Type Code < 254?

RFC 3748 Section 5.3.2 says:

     The Expanded Nak Type is valid only in Response messages.  It MUST
     be sent only in reply to a Request of Type 254 (Expanded Type)
     where the authentication Type is unacceptable.

Based on this, I believe the correct behavior is silent discard.