Hi Terry, On 8/20/20 3:02 PM, Terry Burton wrote:
On Thu, 20 Aug 2020 at 10:00, Mohit Sethi M <mohit.m.sethi=40ericsson....@dmarc.ietf.org><mailto: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.: Indeed. I misread the packet sequence to imply that the server was sending an EAP-Response (which is why I had a disclaimer at the beginning :)). 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. 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." 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. This seems to be the correct behavior (at least for me). --Mohit 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<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
