Hi Terry, On 8/20/20 5:41 PM, Terry Burton wrote: > 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.
Sorry for nitpicking here. But it is important to distinguish the two components that comprise a AAA server: RADIUS server and EAP server. RFC 3579 briefly alludes to this difference and uses different terms for a RADIUS server and an EAP server. Sure, they will likely run on the same machine and are tightly integrated, yet they are independent components. The text you point to in RFC 3579 doesn't imply that the NAK is sent from the EAP server. It only says that to avoid retransmissions, a RADIUS server should generate an Access-Reject containing a EAP-Response/Nak on its own (without involving the EAP server). So technically, this NAK is still not sent by the EAP server in the so-called 'wrong direction'. In common realistic implementations, RADIUS servers only proxy data to/from the EAP server and do not generally inject EAP packets on their own. Which is why I suspect that this is not implemented in the radius server of hostap: https://w1.fi/cgit/hostap/tree/src/radius/radius_server.c#n1437 --Mohit >> 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
