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.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|