On Thu, 20 Aug 2020 at 10:00, Mohit Sethi M <mohit.m.sethi=40ericsson....@dmarc.ietf.org> wrote: > I surely must be missing something here: > > Packet 6 is an EAP-Response from the peer. Packet 7 contains another > EAP-Response inside a RADIUS Access-Request? That doesn't make sense. EAP is > lock-step request-response protocol. The conversation you describe is > incorrect.
Hi, Maybe you were thrown by my typo (to make sure readers were awake). It should have read "6. Peer --> NAS", i.e.: 6. Peer --> NAS: EAP-Response / EAP-Type=NAK (Methods [Bar]) 7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response / NAK ( Methods [ Bar ] ) Packet 7 is just the NAS encapsulating the Peer's NAK within RADIUS for the AAA, not a separately originating request. The language is the same as the fourth example in RFC 3579 Appendix A, however that example skips the identity phase and goes on to successfully negotiate a method. > My reading of RFC 3748 is clear that after receiving a NAK from the peer, the > server should send another EAP-Request with a different EAP method if its > policy allows or then send a failure. The server should also send a failure > if the peer NAK Type-Data was 0 (indicating no proposed alternative). I'm still not seeing a clear reference for what to send in the event of no overlapping methods from the text in these RFCs. > FYI: RFC 4137 says: > > o Sending a NAK to the authenticator after the authenticator first > proposes an EAP authentication method to the peer. When the > methodState variable has the value PROPOSED, the authenticator is > obliged to process a NAK that is received in response to its first > packet of an EAP authentication method. > > so the commercial RADIUS server is in violation if it doesn't respond to a > NAK from the peer with either another EAP-Request or failure. That's relevant in the sense that it restates that it is appropriate for a peer to NAK the server's original method selection and that the server must process the NAK. It doesn't state what happens on the wire (specifically that an EAP-Failure is sent to the peer, as seems to be the case in practise) as a result of this processing. 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. Nevertheless, RFC 4137 Appendix A.2. and A.3. is clear on what to do: * When the peer sends a NAK with no alternatives we are in RECEIVED. * In RECEIVED: respMethod == NAK therefore we transition to NAK. * In NAK: We update the policy to exclude the NAKed method and transition to SELECT_ACTION. * In SELECT_ACTION: the result of Policy.getDecision() is presumably FAILURE for no overlapping methods. Transition to FAILURE. * In FAILURE: We build a failure response. I note that both receiving a NAK (RECEIVED -> NAK -> SELECT_ACTION -> FAILURE transition) and receiving an unacceptable method response (RECEIVED -> INTEGRITY_CHECK -> METHOD_RESPONSE -> SELECT_ACTION transition) ultimately arrive at the same FAILURE state that builds a EAP-Failure packet. It appears that the agreed upon behaviour is codified here. Its behaviour also does not differentiate between a peer NAK of "type 0" and one containing a list of alternative methods. Terry > On 8/20/20 3:39 AM, Terry Burton 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
