Hi Terry >In practise: > >* FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure. >* hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message / EAP-Failure. >* A commercial RADIUS server implementation sends nothing.
Cisco Identity Services Engine RADIUS also returns RADIUS Access-Reject / EAP-Message / EAP-Failure in this case. Not sure that if AAA server will send a list of his allowed protocols in reply to NAK - the EAP client would be able to use it. Usually credentials are configured per protocol and not always interchangeable. So if the client wants EAP-GTC as an inner method in PEAP and claims this in an inner EAP NAK message and the server will reply that it has EAP-MSCHAPv2 and EAP-TLS inner methods - client can be unable to leverage this info. -Oleg On Thu, Aug 20, 2020 at 3:39 AM Terry Burton <terry.bur...@gmail.com> wrote: > > Hi, > > I'm unable to find the authoritative source that state exactly how the > following conversation continues (TL;DR; the peer NAKs the original > method and the AAA doesn't support any of the peer's proposals): > > 1. NAS --> Peer : EAP-Request / Identity > 2. Peer --> NAS : EAP-Response / Identity ( ID ) > 3. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response / > Identity ( ID ) > 4. AAA --> NAS: RADIUS Access-Challenge / EAP-Message / EAP-Request / > Method Foo > 5. NAS --> Peer: EAP-Request / Method Foo > 6. Peer --> NAK: EAP-Response / EAP-Type=NAK (Methods [Bar]) > 7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response / > NAK ( Methods [ Bar ] ) > (* Let's assume that the AAA does not support Method Bar so we have > derived that there are no overlapping methods.) > 8. AAA: Now what? > > I've reviewed RFC 3748 (EAP) and RFC 3579 (RADIUS Support For EAP) and > neither seems to be explicit about what the AAA should do in response > to a NAK in the event of no overlapping methods. > > In practise: > > * FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure. > * hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message / > EAP-Failure. > * A commercial RADIUS server implementation sends nothing. > > It seems right to indicate an EAP-Failure to the peer in the case of > no overlapping methods (as well as to terminate the NAS's outstanding > RADIUS Access-Request with an Access-Reject), as is the case for a > number of other failure conditions, e.g. authentication failure > *within* an EAP method (Appendix A by way of example), invalid packets > leading to a fatal error within an EAP method (section 2.2). > > RFC 3748 section 4.2 on Success and Failure introduces these messages > within the context of finalising an ongoing EAP method: > > The Success packet is sent by the authenticator to the peer after > completion of an EAP authentication method (Type 4 or greater) to > indicate that the peer has authenticated successfully to the > authenticator. The authenticator MUST transmit an EAP packet with > the Code field set to 3 (Success). If the authenticator cannot > authenticate the peer (unacceptable Responses to one or more > Requests), then after unsuccessful completion of the EAP method in > progress, the implementation MUST transmit an EAP packet with the > Code field set to 4 (Failure). > > Perhaps one can argue that a NAK is an unacceptable response to an > ongoing method and therefore the method is unsuccessfully completed so > a Failure should be generated? That's not entirely clear, if that is > the case. > > RFC 3748 section 5.3.1 throws in some more doubt, having the following > text that deals explicitly with the peer sending a NAK containing "no > desired alternative" method: > > 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. > > That's specific to one case for which a strict reading would indicate > that the EAP server should remain quiet and consider the EAP > conversation to be complete. It's tempting to think that the same > response (i,e. no response!) should apply more broadly as none of the > AAA implementations I've tested actually differentiate between a NAK > with no desired alternative method vs a NAK with an incompatible list > of alternative methods. (A subtle difference might be relevant: In the > case of NAK / method = [] the peer knows that the EAP conversion can > go no further, whereas in the case that it sends a list of methods > that the AAA happens to not support it does not know this unless it is > subsequently told.) > > If I've not missed something then this looks an omission (or lack of > clarity) and the intended AAA response to no overlapping methods (and > indeed "no desired alternative") should be decided and codified. > > > Thanks, > > Terry > > _______________________________________________ > 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
