Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods
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. > 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
Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods
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
Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods
On Thu, 20 Aug 2020 at 10:00, Mohit Sethi M 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
[Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods
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
Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption
On Wed, 12 Aug 2020 at 07:17, Mohit Sethi M wrote: > Thank you again for the feedback. I have updated the text in github: > https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.html#rfc.section.5.7 > > Here is the diff for your convenience: > https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt Thanks Mohit. I believe that update successfully addresses the issues that I raised. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption
ginal handshake information. I think this emphasises that the ticket is opaque to the client yet clear to the server, and that it is the blob itself that is used by the client to lookup the information in its cache. This gives the correct intuition for why the scheme works without needing to understand the detail in the aforementioned RFCs to read between the lines. Terry > On 8/10/20 6:58 PM, Terry Burton wrote: > > Hi, > > > > Reading "Using EAP-TLS with TLS 1.3" I find the text potentially > > misleading when it comes to resumption within TLS 1.3, specifically > > for the case where the peer wishes to re-validate the certificate > > originally provided by the server during the initial handshake using > > only its locally cached data and without redoing the handshake, e.g. > > to determine that the original certificate hasn't expired or been > > revoked. > > > > > > 5.7. Resumption > > ... > > To perform resumption in a secure way, the EAP-TLS peer and > > EAP-TLS server need to be able to securely retrieve authorization > > information such as certificate chains from the initial full > > handshake. > > ... > > There are two ways to retrieve the cached information from the > > original full handshake. > > ... > > The second method for retrieving cached information is > > via [RFC5077] or [RFC8446], where the TLS server encapsulates the > > information into a ticket and sends it to the client. The client can > > subsequently do resumption using the obtained ticket. Note that the > > client still needs to cache the information locally. > > > > > > In TLS 1.3, the PSK ticket is defined as being encrypted using a key > > that only the server knows. Even without encryption, the format for > > the ticket is opaque to the client with only a suggested format > > presented in RFC 8446. > > > > How is the original handshake data determined? A casual reading of the > > text seems to imply that the client performs some verification using > > the encapsulated information within the ticket. > > > > However I believe that the intent is to use the full PSK blob, or some > > digest thereof, as a key to lookup the corresponding cached handshake > > data. > > > > Perhaps this could be made clearer? > > > > > > Thanks, > > > > Terry ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption
Hi, Reading "Using EAP-TLS with TLS 1.3" I find the text potentially misleading when it comes to resumption within TLS 1.3, specifically for the case where the peer wishes to re-validate the certificate originally provided by the server during the initial handshake using only its locally cached data and without redoing the handshake, e.g. to determine that the original certificate hasn't expired or been revoked. 5.7. Resumption ... To perform resumption in a secure way, the EAP-TLS peer and EAP-TLS server need to be able to securely retrieve authorization information such as certificate chains from the initial full handshake. ... There are two ways to retrieve the cached information from the original full handshake. ... The second method for retrieving cached information is via [RFC5077] or [RFC8446], where the TLS server encapsulates the information into a ticket and sends it to the client. The client can subsequently do resumption using the obtained ticket. Note that the client still needs to cache the information locally. In TLS 1.3, the PSK ticket is defined as being encrypted using a key that only the server knows. Even without encryption, the format for the ticket is opaque to the client with only a suggested format presented in RFC 8446. How is the original handshake data determined? A casual reading of the text seems to imply that the client performs some verification using the encapsulated information within the ticket. However I believe that the intent is to use the full PSK blob, or some digest thereof, as a key to lookup the corresponding cached handshake data. Perhaps this could be made clearer? Thanks, Terry ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
