Hi Terry, It would be a misinterpretation to say that everything from the authenticator is an EAP-Request hence EAP-Failure is also a Request. It's an EAP packet with a different Code. Thus, it is wrong to say that text "the authenticator SHOULD NOT send another Request" also implies that the authenticator SHOULD NOT send an EAP-Failure.
Also, Section 5 of RFC 3748 says that NAK is response only. So I don't understand what you mean by 'NAK is just a "Type" of Request / Response (depending on direction)'. NAKs are only sent by the peer to the authenticator/server. Sending a NAK in the other direction would be a violation of RFC 3748 and is not supported or implemented. --Mohit On 8/20/20 4:26 PM, Terry Burton wrote: > On Thu, 20 Aug 2020 at 13:34, Mohit Sethi M > <[email protected]> wrote: > <...snip...> >> It's also contrary to... >> >> Type zero (0) is used to indicate that the sender has >> no viable alternatives, and therefore the authenticator SHOULD NOT >> send another Request after receiving a Nak Response containing a >> zero value. >> >> .... unless the language is loose and we say that an EAP-Failure >> request isn't actually a "Request", but that's hard to argue due to >> capital "R"equest. >> >> Why is EAP-Failure a request? It's an EAP packet with a different Code? So >> the SHOULD NOT doesn't forbid the server from sending an EAP-Failure. RFC >> 3748 even calls Failure as a response: "An authenticator MAY wish to issue >> multiple Requests before sending a Failure response in order to allow for >> human typing mistakes." > That's a small "r"esponse and I'd dare to say that even that usage > isn't particularly helpful! :-) > > I think it's well established that any message from the authenticator > to the peer (Code = 1) is an "R"equest and that any message from the > peer to the authenticator (Code = 2) is an EAP "R"esponse. NAK is just > a "Type" of Request / Response (depending on direction). So when the > above text mentions "R"equest it actually refers to EAP packets with > Code = 1, i.e. it says (seemingly erroneously as Alan points out) that > no further messages of any type should be sent from the authenticator > to the peer within the conversation. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
