On Thu, 20 Aug 2020 at 14:54, Mohit Sethi M <mohit.m.sethi=40ericsson....@dmarc.ietf.org> wrote: > 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.
You're right. Thanks. > 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. I was probably thrown because RFC 3579 section 2.6.2 on Role Reversal has this: Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time. However, role reversal is not supported by this specification. A RADIUS server MUST respond to an Access-Request encapsulating an EAP-Request with an Access-Reject. In order to avoid retransmissions by the peer, the Access-Reject SHOULD include an EAP-Response/Nak packet indicating no preferred method, encapsulated within EAP-Message attribute(s). Notionally that's an "EAP-Response/NAK" sent in the "wrong" direction: AAA --> NAS --> Peer However I believe that this is considering the case where the peer contains an EAP server that is trying to initiate an authentication of the NAS (not allowed), and therefore the AAA tells the peer to go away. > On 8/20/20 4:26 PM, Terry Burton wrote: > > On Thu, 20 Aug 2020 at 13:34, Mohit Sethi M > > <mohit.m.sethi=40ericsson....@dmarc.ietf.org> 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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
