Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods
On Aug 21, 2020, at 3:27 AM, Mohit Sethi M wrote: > 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. Some minor nit picking here... In practice, EAP servers are tightly coupled with RADIUS servers. At least for ones which implement non-trivial EAP methods. But I agree that they need to be treated as independent components. FWIW, I've looked for EAP server implementations. As best I can tell for Open Source, it's just hostap and FreeRADIUS. Everything else is either dead, or implements only a tiny subset of EAP, such as EAP-MD5. > 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 I'm wary of the word "proxy". Proxying implies some kind of transport, as with RADIUS proxying. The public implementations of RADIUS+EAP have the two components in the same process, using shared libraries. The interaction between the two is just API calls. > 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 The RADIUS side of hostap doesn't inject the EAP Failure. The underlying EAP implementation injects it. The eap_sm_Policy_getDecision() function returns failure if there are no compatible EAP methods. The calling function then returns EAP Failure. https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server.c#n1722 The EAP server implementation in FreeRADIUS also returns an EAP Failure packet if there are no compatible EAP methods. The underlying principle here is that silently dropping packets is considered bad. Therefore, no matter what happens inside of the EAP state machine, the outcome is one of 3 things: * more EAP negotiation * Success * Failure The only time the RADIUS side injects an EAP Failure is if the session is rejected for administrative reasons. And, the EAP state machine is bypassed. e.g. deny this particular user on this particular device, even if their EAP credentials are OK. In that case, the EAP stack is bypassed. The Access-Reject handler checks for an EAP-Message in the Access-Request. If found, the RADIUS layer synthesizes an EAP Failure inside of an EAP-Message. Since hostap doesn't really have policies in it's RADIUS server implementation, it doesn't implement this check. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods
Hi Terry, On 8/20/20 5:41 PM, Terry Burton wrote: > On Thu, 20 Aug 2020 at 14:54, Mohit Sethi M > 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 >>> 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
