Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Mar 11, 2019, at 12:52 PM, John Mattsson wrote: > There seems to be agreement on the list to add security considerations on > authorization and resumption. With the text from Alan as a basis (thanks > again Alan!), I have added the sections below to draft-ietf-emu-eap-tls13. > > Some high level changes from Alas text: > - Some considerations also cover the EAP peer > - Description of encapsulation protocols moved from resumption to > authorization > - Added that revocation status and authorization may change before resumption Sounds good. > Discussing with me co-author, we agreed that cross-method resumption may be > best to discuss in Alans document that talks about various TLS-based EAP > methods. That document is expected to go into the various methods in more > detail. It may be worth mentioning it here, and saying that the implementations should be aware of it, and take steps to address it. > 2.2. Identity Verification > > The identity provided in the EAP-Response/Identity is not > authenticated by EAP-TLS. Unauthenticated information SHALL NOT be > used for accounting purposes or to give authorization. The > authenticator and the EAP server MAY examine the identity presented > in EAP-Response/Identity for purposes such as routing and EAP method > selection. They MAY reject conversations if the identity does not > match their policy. Note that this also applies to resumption, see > Sections 2.1.2, 5.6, and 5.7. That looks good. > 5.6. Authorization > > EAP-TLS may be encapsulated in other protocols, such as PPP > [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. > Systems implementing those protocols interact with EAP-TLS and can > make policy decisions and enforce authorization based on information > from the EAP-TLS exchange. The encapsulating protocols can also > provide additional, non-EAP information to the EAP server. This > information can include, but is not limited to, information about the > authenticator, information about the EAP peer, or information about > the protocol layers below EAP (MAC addresses, IP addresses, port > numbers, WiFi SSID, etc.). > > As noted in Section 2.2, the identity presented in EAP-Response/ > Identity is not authenticated by EAP-TLS and therefore trivial for an nit: "therefore is trivial", or "is therefore trivial" > attacker to forge, modify, or replay. Authorization and accounting > MUST be based on authenticated information such as information in the > certificate or the PSK identity and cached data provisioned for > resumption as described in Section 5.7. Note that the requirements > for Network Access Identifiers (NAIs) specified in Section 4 of > [RFC7542] still apply and MUST be followed. > > Policy decisions are often based on a mixture of information from > TLS, EAP, and encapsulating protocols. EAP servers MAY reject > conversations based on unauthenticated information such as an unknown nit: I'd say "based on examining unauthenticated information" Otherwise it could be seen as rejecting the session if unauthenticated information *exists*. > MAC address or an identity provided in in EAP-Response/Identity that > do not match a certain policy. > > 5.7. Resumption > > There are a number of security issues related to resumption that are > not described in [RFC5216]. The problems, guidelines, and > requirements in this section therefore applies to all version of TLS. > > When resumption occurs, it is based on cached information at the TLS > layer. As described in Section 2.2, the identity provided in the > EAP-Response/Identity is not authenticated by EAP-TLS. > > To perform resumption in a secure way, the EAP peer and EAP server > need to be able to securely retrieve information such as certificate > chains, revocation status, and other authorization information from > the initial full handshake. We use the term "cached data" to > describe such information. Any authorization applied during > resumption MUST be done using this cached data. It might be worth mentioning the unauthenticated data here, too. > There are two ways to retrieve the needed information. The first > method is that the TLS server and client caches the information > locally, identified by an identifier and secured by the other party > showing proof-of-position of a key obtained from the initial full > handshake. For TLS versions before 1.3, the identifier can be the > session ID, for TLS 1.3, the identifier is the PSK identity. The > second method is via [RFC5077], where the TLS server encapsulates the > information into a ticket and forwards it to the client. The client > can subsequently do resumption using the obtained ticket. Note that > the client still need to cache the information locally. The nit: "needs" > following requirements apply to both methods. > > If the EAP server or EAP clie
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Hi, There seems to be agreement on the list to add security considerations on authorization and resumption. With the text from Alan as a basis (thanks again Alan!), I have added the sections below to draft-ietf-emu-eap-tls13. Some high level changes from Alas text: - Some considerations also cover the EAP peer - Description of encapsulation protocols moved from resumption to authorization - Added that revocation status and authorization may change before resumption Discussing with me co-author, we agreed that cross-method resumption may be best to discuss in Alans document that talks about various TLS-based EAP methods. That document is expected to go into the various methods in more detail. The text below is what I plan to submit at midnight UTC time. I there are comments before that, I can try to update the text, otherwise we can work on the text in the coming weeks before Prague. Cheers, John 2.2. Identity Verification The identity provided in the EAP-Response/Identity is not authenticated by EAP-TLS. Unauthenticated information SHALL NOT be used for accounting purposes or to give authorization. The authenticator and the EAP server MAY examine the identity presented in EAP-Response/Identity for purposes such as routing and EAP method selection. They MAY reject conversations if the identity does not match their policy. Note that this also applies to resumption, see Sections 2.1.2, 5.6, and 5.7. 5.6. Authorization EAP-TLS may be encapsulated in other protocols, such as PPP [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. Systems implementing those protocols interact with EAP-TLS and can make policy decisions and enforce authorization based on information from the EAP-TLS exchange. The encapsulating protocols can also provide additional, non-EAP information to the EAP server. This information can include, but is not limited to, information about the authenticator, information about the EAP peer, or information about the protocol layers below EAP (MAC addresses, IP addresses, port numbers, WiFi SSID, etc.). As noted in Section 2.2, the identity presented in EAP-Response/ Identity is not authenticated by EAP-TLS and therefore trivial for an attacker to forge, modify, or replay. Authorization and accounting MUST be based on authenticated information such as information in the certificate or the PSK identity and cached data provisioned for resumption as described in Section 5.7. Note that the requirements for Network Access Identifiers (NAIs) specified in Section 4 of [RFC7542] still apply and MUST be followed. Policy decisions are often based on a mixture of information from TLS, EAP, and encapsulating protocols. EAP servers MAY reject conversations based on unauthenticated information such as an unknown MAC address or an identity provided in in EAP-Response/Identity that do not match a certain policy. 5.7. Resumption There are a number of security issues related to resumption that are not described in [RFC5216]. The problems, guidelines, and requirements in this section therefore applies to all version of TLS. When resumption occurs, it is based on cached information at the TLS layer. As described in Section 2.2, the identity provided in the EAP-Response/Identity is not authenticated by EAP-TLS. To perform resumption in a secure way, the EAP peer and EAP server need to be able to securely retrieve information such as certificate chains, revocation status, and other authorization information from the initial full handshake. We use the term "cached data" to describe such information. Any authorization applied during resumption MUST be done using this cached data. There are two ways to retrieve the needed information. The first method is that the TLS server and client caches the information locally, identified by an identifier and secured by the other party showing proof-of-position of a key obtained from the initial full handshake. For TLS versions before 1.3, the identifier can be the session ID, for TLS 1.3, the identifier is the PSK identity. The second method is via [RFC5077], where the TLS server encapsulates the information into a ticket and forwards it to the client. The client can subsequently do resumption using the obtained ticket. Note that the client still need to cache the information locally. The following requirements apply to both methods. If the EAP server or EAP client do not apply any authorization policies, they MAY allow resumption where no cached data is available. In all other cases, they MUST cache data during the initial full authentication to enable resumption. The cached data MUST be sufficient to make authorization decisions during resumption. If cached data cannot be retrieved in a secure way, resumption MUST NOT be done. The ab
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Mar 10, 2019, at 1:27 PM, Michael Richardson wrote: > > If there is no legit use case for TLS resumption, then it seems that EAP > servers SHOULD disable TLS resumption. There are very many use-cases for TLS resumption. The point is that all of these use-cases require additional information. i.e. the credentials from the original authentication. As such, this document needs to give guidance on this topic. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
If there is no legit use case for TLS resumption, then it seems that EAP servers SHOULD disable TLS resumption. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
I would totally agree that this type of guidance needs to be added to this document. Jim > -Original Message- > From: Alan DeKok > Sent: Sunday, March 10, 2019 5:58 AM > To: Jim Schaad > Cc: Michael Richardson ; EMU WG > > Subject: Re: [Emu] Notes on session resumption with TLS-based EAP > methods > > On Mar 9, 2019, at 7:46 PM, Jim Schaad wrote: > > Yes - The resumption credential is on the user's device and on the TLS > > server. If the user's device moves then things are just fine. Again, > > the TLS server would need to check the credentials from the cached > > session > > My point is that neither RFC 5216 nor this document gives any guidance > here. They don't even mention checking cached authentication data. > > Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Mar 9, 2019, at 7:46 PM, Jim Schaad wrote: > Yes - The resumption credential is on the user's device and on the TLS > server. If the user's device moves then things are just fine. Again, the > TLS server would need to check the credentials from the cached session My point is that neither RFC 5216 nor this document gives any guidance here. They don't even mention checking cached authentication data. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
> -Original Message- > From: Emu On Behalf Of Michael Richardson > Sent: Saturday, March 9, 2019 3:51 PM > To: 'EMU WG' > Subject: Re: [Emu] Notes on session resumption with TLS-based EAP > methods > > > Jim Schaad wrote: > > I am finally getting caught up on this thread and I have found it to be very > > frustrating because it appears to make an assumption which I do not > believe > > is warranted. > > > I do not see any problems with allowing TLS session to be used across > > different types of EAP assuming that EAP correctly checks the output of > TLS > > before continuing. When a session ticket is issued for a TLS session it > > contains the authentication done by that TLS authentication session. It > > does not contain any of the containing EAP authentication information > that > > has been done. > > I have been following along the discussion, and I think that I missed the use > case. > Why are we having this discussion? > > alan> i.e. a user starts with EAP-TLS, and then tries to "resume" his > alan> session, but this time uses TTLS. It's not clear that anything in > alan> the spec forbids or prevents this. > > What's in it for the user? For the user, the win is that the TLS handshake is much smaller and therefore runs both faster and more reliably. > Is this an attack? Depends on what you think session resumption gives you. From my point of view there is absolutely no attack as the server still needs to check that the client certificate credentials are acceptable. Whether this is none or specific trust anchors. > Does it avoid an interaction with a human? Yes - this would be cached locally in some way. The assumption is that you would not do this on a kiosk type situation or make sure that they are strongly protected to the user. > Does it enable mobility between different networks? Yes - The resumption credential is on the user's device and on the TLS server. If the user's device moves then things are just fine. Again, the TLS server would need to check the credentials from the cached session against the new network to make sure that nothing bad is happening and the client can operate on that new network. > Does this avoid some interaction with a two-factor authenticator? That depends on how the two-factor authentication is being done. If both factors are some how bound up in the TLS protocol itself, then it boils down to single factor authentication. If the two factors are a client certificate - using TLS - and some type of pass phrase which is being passed in EAP or over the application protocol - then there is nothing that is being released. One assumes that the same type of access to the private key is still needed for running TLS and then the second factor is going to be required to be entered in some manner and sent as part of EAP or the application. Jim > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Mar 9, 2019, at 6:50 PM, Michael Richardson wrote: > I have been following along the discussion, and I think that I missed the use > case. > Why are we having this discussion? It's good to understand the edge conditions of the protocol. Otherwise, it might have designed-in flaws. Or, implementations might be vulnerable to attacks which aren't discussed in the specification. > alan> i.e. a user starts with EAP-TLS, and then tries to "resume" his > alan> session, but this time uses TTLS. It's not clear that anything in the > alan> spec forbids or prevents this. > > What's in it for the user? s/user/attacker/ Answer: lots. Systems may have different policies for different EAP types. Being able to undetectably change EAP types seems bad. The issue is larger than just resumption with different EAP types. It's the whole set of information around the authentication. All of that data is unsecured, and can be forged. > Is this an attack? Yes. If the user changes the unauthenticated data associated with the EAP session (MAC address, switch port, etc), it may be possible to bypass poorly designed policies. e.g. changing the EAP-Request / Identity field. > Does it avoid an interaction with a human? > Does it enable mobility between different networks? > Does this avoid some interaction with a two-factor authenticator? It bypasses security policies. That seems bad. The other huge issue is how do we enforce policies with TLS resumption? The EAP-Request / Identity is insecure and can be forged. So that can't be relied on. Maybe the EAP server doesn't associate *any* policy data or authentication credentials with that TLS session. In that case, you can "resume", but we have no idea *who* is being "resumed", or what policies should be applied to that user. That seems like a rather enormous security issue. Since nothing in the protocol prevents people from playing games with it, attackers *will* play games, with unknown consequences. It therefore seems prudent to discuss these issues. Also to give guidance on the possible attacks. And, to give guidance on good practices. I think the issue of "resumption across EAP methods" is a minor one, but it has opened up a series of additional issues which need addressing. The previous EAP-TLS spec was written largely to describe EAP-TLS and nothing more. Realistically, EAP-TLS is almost always used inside of a larger ecosystem. It is therefore also prudent to discuss how these systems can interact, and what security issues may arise from this interactions. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Jim Schaad wrote: > I am finally getting caught up on this thread and I have found it to be very > frustrating because it appears to make an assumption which I do not believe > is warranted. > I do not see any problems with allowing TLS session to be used across > different types of EAP assuming that EAP correctly checks the output of TLS > before continuing. When a session ticket is issued for a TLS session it > contains the authentication done by that TLS authentication session. It > does not contain any of the containing EAP authentication information that > has been done. I have been following along the discussion, and I think that I missed the use case. Why are we having this discussion? alan> i.e. a user starts with EAP-TLS, and then tries to "resume" his alan> session, but this time uses TTLS. It's not clear that anything in the alan> spec forbids or prevents this. What's in it for the user? Is this an attack? Does it avoid an interaction with a human? Does it enable mobility between different networks? Does this avoid some interaction with a two-factor authenticator? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
I am finally getting caught up on this thread and I have found it to be very frustrating because it appears to make an assumption which I do not believe is warranted. I do not see any problems with allowing TLS session to be used across different types of EAP assuming that EAP correctly checks the output of TLS before continuing. When a session ticket is issued for a TLS session it contains the authentication done by that TLS authentication session. It does not contain any of the containing EAP authentication information that has been done. Example: Run EAP where you do TLS anonymous followed by a password and get the session ticket. This session ticket is associated with ZERO client authentication information, not even the password because the session ticket would be issued before the password was obtained. Take that session ticket and run it in an EAP-TLS session. The TLS would check to see if there was client authentication associated with the session ticket and either a) say that the ticket is not valid or b) validates the ticket and then does a post handshake client authentication for the client certificate. It could then issue a new ticket which contained the client authentication information obtained in TLS. A similar analysis can be done for all EAP methods. The session ticket only has the information that is discovered by TLS and as such any new TLS session that is created needs to look a the client authentication that was done when the ticket was issued. Jim > -Original Message- > From: Emu On Behalf Of Alan DeKok > Sent: Thursday, March 7, 2019 5:41 PM > To: Arran Cudbard-Bell > Cc: EMU WG > Subject: Re: [Emu] Notes on session resumption with TLS-based EAP > methods > > On Mar 6, 2019, at 9:40 PM, Arran Cudbard-Bell > wrote: > > 'session tickets for TLS versions 1.2 and below, and [RFC 8446] session > tickets in TLS 1.3.' > > > > I know it's pedantic, but RFC 8446 obsoletes RFC 5077. > > Sure. > > >> Any authorization applied during resumption MUST be done using the > >> cached data, > > > > 'or data resolved or obtained using that cached data.' > > > > authorization doesn't need to performed in a sandboxed environment with > only the cached data. > > True. It can be used to look up data in a database, or to do something else. > > > Cross resumption between VPNs and Wired/Wireless infrastructure could > be a big issue. > > It might be worth mentioning that explicitly as I think it'll be a blind spot for > implementors. > > > > Out of the box, if someone used our EAP server implementation for > > authenticating VPN users and wired/wireless users, we would allow > > cross resumption, because the EAP server doesn't allocate session tickets > based in different contexts by default. > > That depends on the deployment, too. > > To be strictly technical, an HTTPS server and EAP server could share TLS > session tickets. It would then be possible for users to authenticate via > HTTPS, and "resume" via EAP-TLS. > > The only reason resumption works across media types in EAP is that there's > generally one common EAP server for all media types. If instead there are > multiple EAP servers, or the TLS implementations don't share data, then > cross-method resumption won't work. > > >> When EAP servers make policy decisions based on unauthenticated > >> information, they MUST then add that information to the cached data > > > > maybe 'then it MUST be used in combination with the cached data > described above' > > Perhaps. > > > Took a couple of readings to understand exactly what you meant there. > > It's a difficult subject to explain properly. > > > The cached data isn't being updated, but it's being used together with > > the unauthenticated information, right? > > Yes. > > Alan DeKok. > > ___ > 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
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Mar 6, 2019, at 9:40 PM, Arran Cudbard-Bell wrote: > 'session tickets for TLS versions 1.2 and below, and [RFC 8446] session > tickets in TLS 1.3.' > > I know it's pedantic, but RFC 8446 obsoletes RFC 5077. Sure. >> Any authorization applied during resumption MUST be done using the >> cached data, > > 'or data resolved or obtained using that cached data.' > > authorization doesn't need to performed in a sandboxed environment with only > the cached data. True. It can be used to look up data in a database, or to do something else. > Cross resumption between VPNs and Wired/Wireless infrastructure could be a > big issue. > It might be worth mentioning that explicitly as I think it'll be a blind spot > for implementors. > > Out of the box, if someone used our EAP server implementation for > authenticating VPN users > and wired/wireless users, we would allow cross resumption, because the EAP > server > doesn't allocate session tickets based in different contexts by default. That depends on the deployment, too. To be strictly technical, an HTTPS server and EAP server could share TLS session tickets. It would then be possible for users to authenticate via HTTPS, and "resume" via EAP-TLS. The only reason resumption works across media types in EAP is that there's generally one common EAP server for all media types. If instead there are multiple EAP servers, or the TLS implementations don't share data, then cross-method resumption won't work. >> When EAP servers make policy decisions based on unauthenticated >> information, they MUST then add that information to the cached data > > maybe 'then it MUST be used in combination with the cached data described > above' Perhaps. > Took a couple of readings to understand exactly what you meant there. It's a difficult subject to explain properly. > The cached data isn't being updated, but it's being used together with the > unauthenticated > information, right? Yes. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
> The solution to this conundrum is to associate authentication > credentials and authorization information with the original > authentication. That information can then be obtained and applied > during resumption. > > There are two ways to make this association. The first method is via > [RFC5077], 'session tickets for TLS versions 1.2 and below, and [RFC 8446] session tickets in TLS 1.3.' I know it's pedantic, but RFC 8446 obsoletes RFC 5077. > Any authorization applied during resumption MUST be done using the > cached data, 'or data resolved or obtained using that cached data.' authorization doesn't need to performed in a sandboxed environment with only the cached data. > * MAC address of the EAP peer * IP address of the EAP peer * > Informtion about the ethernet switch to which the EAP peer is > connecting > * MAC address of the switch > * IP address of the switch > * switch port used by the EAP peer > * Wifi SSID > * Information about the ethernet layer used by the EAP peer * Media-Type Cross resumption between VPNs and Wired/Wireless infrastructure could be a big issue. It might be worth mentioning that explicitly as I think it'll be a blind spot for implementors. Out of the box, if someone used our EAP server implementation for authenticating VPN users and wired/wireless users, we would allow cross resumption, because the EAP server doesn't allocate session tickets based in different contexts by default. > The EAP server also has access to the cached EAP-Response / Identity > from the original authentication. > > None of these fields are authenticated or secured. As a result, any > or all of these fields can change between the original > authentication, and resumption. This change creates a "Time of > check, time of use" (TOCTOU) security vulnerability. A malicious > user could supply one set of data during authentication, and a > different set of data during resumption. The malicious user could > then obtain different authorization during resumption, potentially > leading to them obtaining access that they should not have. > > When EAP servers make policy decisions based on unauthenticated > information, they MUST then add that information to the cached data maybe 'then it MUST be used in combination with the cached data described above' Took a couple of readings to understand exactly what you meant there. The cached data isn't being updated, but it's being used together with the unauthenticated information, right? The majority of this sounds great though. -Arran signature.asc Description: Message signed with OpenPGP ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Thanks for the suggested security consideration Alan! This helps a lot! I'll will work with updating the draft during the next days. Your suggested text look very good at a first readthrough. Cheers, John ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Here's my $0.02 on updates to the "Security Considerations" section. --- 5.9. Authorization We note that EAP-TLS may be encapsulated in other protocols, such as PPP [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. Systems implementing those protocols can make policy decisions, and can enforce authorization based on information from the EAP-TLS exchange. As such, we need to discuss interactions between those protocols and EAP-TLS. For generality, we state requirements on EAP servers, instead of updating those other protocols. As noted in Section 2.2, above, the EAP-Response / Identity is unauthenticated. EAP servers therefore MUST NOT make policy decisions based on that identity. Instead, where they make policy decisions, EAP servers MUST base those decisions on authenticated identities, such as information from the client certificate, or from the PSK identity provisioned for resumption, or from other cached information as described in the next section. We note that this requirement does not over-ride the requirements given in [RFC7542] Section 4. EAP servers which use the NAI format necessarily also MUST follow the requirements of the NAI specification. In order to implement the requirements of [RFC7542], EAP servers MAY examine the EAP-Response / Identity field, and reject authentication if they determine that the field is in any way unsuitable. In short, EAP servers MUST NOT authorize sessions based the EAP- Response / Identity field. The field is untrusted, and may be trivially forged. 5.10. Resumption There are a number of security issues related to resumption. [RFC516] is unfortunately silent on this topic, so we discuss this issue in detail here. We note that the problems outlined here are also relevant to earlier versions of TLS. The solutions are also similar. When resumption occurs, it largely occurs based on the cached TLS data, at the TLS layer. The only credentials supplied during this resumption are the EAP-Response/Identity. However, as noted above in Section 2.2, the identity presented in the EAP-Response/Identity is unauthenticated information, and SHALL NOT be used for access control or accounting purposes. Note that this also applies to resumption. This requirement gives us a conundrum. We have a successful resumption, but we have no idea what identity is being used in that resumption. We are thus unable to apply any authorization to that authentication request. Since we have no way to authorize the user, the only secure step we can take is to reject the session. This rejection removes any possibility of resumption. The solution to this conundrum is to associate authentication credentials and authorization information with the original authentication. That information can then be obtained and applied during resumption. There are two ways to make this association. The first method is via [RFC5077], where the TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. The second method is where the TLS server caches information about the TLS session, based on a unique key. For TLS versions before 1.3, this key can be the session ID. For TLS 1.3, this key is the unique PSK identity. The following requirements apply to both methods of associating additional data with the TLS session. For simplicity, we use the term "cached data" to mean any authentication credentials or authorization information that has been associated with the TLS session via either session tickets, or via caching on the TLS server. Where the EAP server applies no authorization policies to TLS sessions, it MAY allow resumption where no cached data is available. That is, if no policies are applied during the original authentication, it is acceptable to not apply policies during any resumption. In all other cases, the EAP server MUST cache data during the original authentication. This cached data MUST be sufficient to make authorization decisions during session resumption. Where this cached data is unavailable, the resumption MUST be rejected, as no policies can be meaningfully applied. Any authorization applied during resumption MUST be done using the cached data, and MUST NOT be done by examining the EAP-Response / Identity that was supplied during resumption. As noted earlier, that identity is unauthenticated and therefore insecure. The above requirements also apply if the EAP server expects some system to perform accounting for the session. Since accounting must be tied to an authenticated identity, and resumption does not supply such an identity, accounting is impossible without access to cached data. As discussed in the previo
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 22, 2019, at 7:47 PM, Arran Cudbard-Bell wrote: > > >> In my opinion, the document MUST give guidance for implementors and site >> administrators: >> >> * if resumption is used, the implementation MUST cache sufficient >> information for the system to make appropriate policy decisions on resumption > > Maybe something about not relying on the outer identity to apply any kind of > autz policies? Administrators may assume some kind of binding between the > outer identity, the original session, and the resumed session, and assume > it'll be consistent. In reality the user can provide any outer identity they > like. Yes. The NAI document discusses this situation: https://tools.ietf.org/html/rfc7542#section-4.2 That discussion unfortunately doesn't discuss resumption. > I know this is covered by the above point, but I feel it's worth documenting > this case explicitly. Yes. An explicit reference to the above section would help. >> * resumption MUST be rejected if no cached information is available, as we >> have no idea what policies to apply > > I'd argue if cached information is expected and non is available, resumption > MUST be rejected. For the majority of cases the security policies applied to > the different TLS based EAP methods will be identical. Yes, that has to happen, too. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
> In my opinion, the document MUST give guidance for implementors and site > administrators: > > * if resumption is used, the implementation MUST cache sufficient information > for the system to make appropriate policy decisions on resumption Maybe something about not relying on the outer identity to apply any kind of autz policies? Administrators may assume some kind of binding between the outer identity, the original session, and the resumed session, and assume it'll be consistent. In reality the user can provide any outer identity they like. I know this is covered by the above point, but I feel it's worth documenting this case explicitly. > * resumption MUST be rejected if no cached information is available, as we > have no idea what policies to apply I'd argue if cached information is expected and non is available, resumption MUST be rejected. For the majority of cases the security policies applied to the different TLS based EAP methods will be identical. I agree with the rest of the points. -Arran signature.asc Description: Message signed with OpenPGP ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 22, 2019, at 2:46 AM, John Mattsson wrote: > > I think Section 2.2 of RFC 5216 do discuss this issue, but it does not > explicitly mention resumption. The text is also too soft. I think that section discusses an entirely different issue, that has nothing to do with resumption. > Suggestion to add to Section 2.2 of EAP-TLS 1.3 > > "The identity presented in the EAP-Response/Identity is unauthenticated > information, and SHALL NOT be used for access control or accounting purposes. > Note that this also applies to resumption." This text means that resumption is impossible in all practical networks. Why? Because the user was originally authenticated via the credentials they provide: the certificate. As per Section 2.2, any policies applied to that user are applied based on those credentials. When resumption happens, those credentials are not supplied. The only ID provided is the EAP-Response/Identity, which systems are forbidden from trusting. So we now have resumption where we don't know the identity of who is resuming. We don't know what policies were applied to them previously. We don't know what policies to apply to them now. Therefore, any *practical* resumption is impossible. In my opinion, the document MUST give guidance for implementors and site administrators: * if resumption is used, the implementation MUST cache sufficient information for the system to make appropriate policy decisions on resumption * resumption MUST be rejected if no cached information is available, as we have no idea what policies to apply * the document MUST discuss the use of EAP-TLS in other protocols such as PPP, PANA, RADIUS, and Diameter. Just a mention that they exist is fine. * These protocols MAY carry additional information about the user and/or the machine involved.e.g. MAC, switch IP, port, etc. * When systems make policy decisions on that additional information, the systems MUST be aware that the additional information can be different between the original authentication and any resumption * This difference creates a "Time of check, time of use" (TOCTOU) security issue with the policies. i.e. The user can leverage the TOCTOU issue to get one policy applied for the original authentication, and a different policy applied for resumption. * That difference allows users to exploit the system, and get access that they should not have. * Implementations SHOULD add such information to the above cache for the session, so they can look for discrepancies between the original authentication and resumption * where there are discrepancies, the resumption SHOULD be rejected. I don't understand why there's so little concern about people being able to PWN your network. It's a disaster. We can't just paper over this issue. It's a major security flaw that's designed into the protocol. It needs to be addressed. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Alan DeKok ;; wrote: >This security bug was completely missed in RFC 5216. This new draft should >rectify that error. > >i.e. using an NAI of "example.org" in the first session, and "example.com" in >the second session. > >Not only is this entirely permitted by the current spec, it's not even >discussed as an issue. And it means that the protocol is open to a large >number of time of use, time of check" security bugs which could cause serious >breaches of networks. I think Section 2.2 of RFC 5216 do discuss this issue, but it does not explicitly mention resumption. The text is also too soft. 2.2. Identity Verification As noted in Section 5.1 of [RFC3748]: It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use. EAP Methods SHOULD include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response. As part of the TLS negotiation, the server presents a certificate to the peer, and if mutual authentication is requested, the peer presents a certificate to the server. EAP-TLS therefore provides a mechanism for determining both the peer identity (Peer-Id in [KEYFRAME]) and server identity (Server-Id in [KEYFRAME]). For details, see Section 5.2. Since the identity presented in the EAP-Response/Identity need not be related to the identity presented in the peer certificate, EAP-TLS implementations SHOULD NOT require that they be identical. However, if they are not identical, the identity presented in the EAP- Response/Identity is unauthenticated information, and SHOULD NOT be used for access control or accounting purposes. Suggestion to add to Section 2.2 of EAP-TLS 1.3 "The identity presented in the EAP-Response/Identity is unauthenticated information, and SHALL NOT be used for access control or accounting purposes. Note that this also applies to resumption." /John ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Agree 100% Alan. Now is the time to fix this.
-Original Message-
From: Emu on behalf of Alan DeKok
Date: Wednesday, February 20, 2019 at 9:03 AM
To: John Mattsson
Cc: "emu@ietf.org"
Subject: Re: [Emu] Notes on session resumption with TLS-based EAP methods
> On Feb 20, 2019, at 8:53 AM, John Mattsson wrote:
> draft-ietf-emu-eap-tls13 is actually very careful to not talk about "session
> resuption", it talks about "resumption". The reason is that "session" is not
> well defined and probably not the same in TLS and EAP. In TLS 1.2 or earlier,
> "session resumption" clearly resumed a session. TLS 1.3 partly uses "session
> resumption" as something depracated:
>
> "Session resumption with and without server-side state as well as the
> PSK-based cipher suites of earlier TLS versions have been replaced by a
> single new PSK exchange."
>
> As well as slang for the new resumption mechanism:
>
> "Although TLS PSKs can be established out of band, PSKs can also be
> established in a previous connection and then used to establish a new
> connection ("session resumption" or "resuming" with a PSK)."
>
> And according to RFC 8446, resumption in TLS 1.3 creates a new session
>
> "The PSK binder value forms a binding between a PSK and the current
> handshake, as well as between the session where the PSK was established and
> the current session"
>
> "NewSessionTicket"
OK, but that's still resuming a user session. Even if the name of the thing
changed.
> My understanding is that
>
> - session resumption with EAP-TLS 1.2 would resume the same TLS session
> (same TLS SessionID) but create a new EAP session (different EAP Session-Id).
>
> - resumption with EAP-TLS 1.3 would create a new TLS session (SessionID is
> depracated) and create a new EAP session (different EAP Session-Id)
That's nice, but really misses my point.
Whatever it's called in EAP-TLS 1.3, resumption *does not* use the same
authentication credentials as the first session. This creates a "time of use,
time of check" security bug that's welded into the protocol.
This security bug was completely missed in RFC 5216. This new draft should
rectify that error.
i.e. using an NAI of "example.org" in the first session, and "example.com" in
the second session.
Not only is this entirely permitted by the current spec, it's not even
discussed as an issue. And it means that the protocol is open to a large
number of time of use, time of check" security bugs which could cause serious
breaches of networks.
We can't paper over security issues by saying "it's not session resumption,
it's a new session". Well, whatever. The NEW session should get the same
authorization as the OLD session, but the information used to do that
authorization doesn't exist in the NEW session! Or if it does exist, it can be
different!
That's a show-stopper, TBH.
Alan DeKok.
___
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
Re: [Emu] Notes on session resumption with TLS-based EAP methods
> On Feb 20, 2019, at 8:53 AM, John Mattsson wrote:
> draft-ietf-emu-eap-tls13 is actually very careful to not talk about "session
> resuption", it talks about "resumption". The reason is that "session" is not
> well defined and probably not the same in TLS and EAP. In TLS 1.2 or earlier,
> "session resumption" clearly resumed a session. TLS 1.3 partly uses "session
> resumption" as something depracated:
>
> "Session resumption with and without server-side state as well as the
> PSK-based cipher suites of earlier TLS versions have been replaced by a
> single new PSK exchange."
>
> As well as slang for the new resumption mechanism:
>
> "Although TLS PSKs can be established out of band, PSKs can also be
> established in a previous connection and then used to establish a new
> connection ("session resumption" or "resuming" with a PSK)."
>
> And according to RFC 8446, resumption in TLS 1.3 creates a new session
>
> "The PSK binder value forms a binding between a PSK and the current
> handshake, as well as between the session where the PSK was established and
> the current session"
>
> "NewSessionTicket"
OK, but that's still resuming a user session. Even if the name of the thing
changed.
> My understanding is that
>
> - session resumption with EAP-TLS 1.2 would resume the same TLS session
> (same TLS SessionID) but create a new EAP session (different EAP Session-Id).
>
> - resumption with EAP-TLS 1.3 would create a new TLS session (SessionID is
> depracated) and create a new EAP session (different EAP Session-Id)
That's nice, but really misses my point.
Whatever it's called in EAP-TLS 1.3, resumption *does not* use the same
authentication credentials as the first session. This creates a "time of use,
time of check" security bug that's welded into the protocol.
This security bug was completely missed in RFC 5216. This new draft should
rectify that error.
i.e. using an NAI of "example.org" in the first session, and "example.com" in
the second session.
Not only is this entirely permitted by the current spec, it's not even
discussed as an issue. And it means that the protocol is open to a large
number of time of use, time of check" security bugs which could cause serious
breaches of networks.
We can't paper over security issues by saying "it's not session resumption,
it's a new session". Well, whatever. The NEW session should get the same
authorization as the OLD session, but the information used to do that
authorization doesn't exist in the NEW session! Or if it does exist, it can be
different!
That's a show-stopper, TBH.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Alan DeKok ; wrote:
>The issue with session resumption is much larger than just the EAP method.
>This subject should ideally be discussed in the "Security Considerations"
>section of the new EAP-TLS draft.
I agree
>i.e. We should define precisely what a "session" is.
>
>Right now, the draft talks about "session resumption", without clearly
>defining it. The *implicit* definition is a TLS session. But the issue of
>resuming with different EAP methods shows there's more to it than that.
draft-ietf-emu-eap-tls13 is actually very careful to not talk about "session
resuption", it talks about "resumption". The reason is that "session" is not
well defined and probably not the same in TLS and EAP. In TLS 1.2 or earlier,
"session resumption" clearly resumed a session. TLS 1.3 partly uses "session
resumption" as something depracated:
"Session resumption with and without server-side state as well as the
PSK-based cipher suites of earlier TLS versions have been replaced by a single
new PSK exchange."
As well as slang for the new resumption mechanism:
"Although TLS PSKs can be established out of band, PSKs can also be
established in a previous connection and then used to establish a new
connection ("session resumption" or "resuming" with a PSK)."
And according to RFC 8446, resumption in TLS 1.3 creates a new session
"The PSK binder value forms a binding between a PSK and the current
handshake, as well as between the session where the PSK was established and the
current session"
"NewSessionTicket"
My understanding is that
- session resumption with EAP-TLS 1.2 would resume the same TLS session
(same TLS SessionID) but create a new EAP session (different EAP Session-Id).
- resumption with EAP-TLS 1.3 would create a new TLS session (SessionID is
depracated) and create a new EAP session (different EAP Session-Id)
/John
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 18, 2019, at 1:49 AM, Arran Cudbard-Bell wrote: >> I can't think of any deployment which allows unauthenticated EAP-TLS. Or >> authenticated only via the NAI. > > HS 2.0 Release 2 section 7.7 (Anonymous EAP-TLS) Ah... I had forgotten about that. > Regarding anonymous outer identities and re-authorization, the real-world > solution I've seen and implemented, is to associate the session ticket ID > with the user's NAI using a datastore when using stateful tickets, or to > include the user's NAI in the opaque data portion of sateless tickets. > Similar methods could be used to prevent cross-method resumption if local > policies require it. The issue with session resumption is much larger than just the EAP method. This subject should ideally be discussed in the "Security Considerations" section of the new EAP-TLS draft. i.e. We should define precisely what a "session" is. Right now, the draft talks about "session resumption", without clearly defining it. The *implicit* definition is a TLS session. But the issue of resuming with different EAP methods shows there's more to it than that. The following is a short list of "session identification" fields which could change from session to session. Some of these are EAP specific, others are in the encapsulating AAA protocol: * outer NAI e.g. auth with "@example.org", resume with "@example.com", or even "@sales.example.org". Is that OK? If so, why? If not, why not * SSID e.g. auth with "eduroam", resume with "harvardU". * MAC address is swapping MAC addresses OK? The protocols actually don't forbid it right now.. * switch / AP IP address auth with wired, "resume" with Wifi? * switch port auth at your desk with personal credentials, and then "resume" on the printers port. Hey, you're a printer! It goes on. The EAP-TLS draft should discuss these issues. Which attributes can change across auth/resumption? Should they be allowed to change? Which attributes should be checked by the authentication server? The issue is made worse by site-dependent policies. If certain policies are applied to the initial authentication, I would hope that the same policies are applied to the resumption. The alternative could be bad. i.e. if we have a "secure" SSID and an "open" one, where both use EAP-TLS. One SSID only allows "secure" users, and the other SSID allows anyone with a valid certificate. In theory, a user can authenticate against the "open" SSID, and then resume against the "secure" SSID. If the authentication server allows resumed sessions, then the security policy can be bypassed. In large part, because the session resumption can use an anonymous NAI, and does not include anything identifying the user. i.e. "@example.com" is resuming a session on the "secure" SSID. Is it OK? There's really only one way around these issues. The authentication server should check which policy was *originally* applied to the user. And then refuse to apply a *different* policy for the session resumption. This can be done by caching user identity, policy, and anything else that is relevant. The draft doesn't say much about these topics, which I think should be addressed. The issue of "auth with TTLS and resume with TLS" is just a tiny part of the iceberg. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
> On Feb 9, 2019, at 1:17 AM, Alan DeKok wrote:
>
> On Feb 8, 2019, at 7:21 AM, John Mattsson wrote:
>> (Everything below is from a pure EAP-TLS (0x0d) perspective without
>> considering any cross-method things)
>>
>> - From an EAP-TLS perspective, I think these two cases ("not authenticated"
>> and "authenticate via some other means") are the same, the peer is not
>> authenticated as far as EAP-TLS is concerned. I read the sentence "other
>> means" as outside of TLS.
>>
>> - RFC 5216 allows deployments with only server authentication:
>>
>> RFC 5216: "While the EAP server SHOULD require peer authentication, this is
>> not mandatory, since there are circumstances in which peer authentication
>> will not be needed (e.g., emergency services, as described in [UNAUTH]), or
>> where the peer will authenticate via some other means."
>>
>> I don't know if there exists EAP-TLS (0x0d) deployments where the "peer
>> authentication will not be needed" or "peer will authenticate via some other
>> means", but if they do exist, we should probably not forbid them to do
>> resumption unless we have good reasons.
>
> I agree.
>
> I can't think of any deployment which allows unauthenticated EAP-TLS. Or
> authenticated only via the NAI.
HS 2.0 Release 2 section 7.7 (Anonymous EAP-TLS)
This specification defines a WFA Vendor specific EAP method, WFA Anonymous
EAP-TLS, which can be used for OSU access. WFA Anonymous EAP-TLS is a profile
of EAP-TLS (specified in [25]), in which the supplicant authenticates the AS,
but the AS does not authenticate the client. WFA Anonymous EAP-TLS shall only
be used for the OSU ESS; it shall not be used for the production ESS (see
section 5.4.2)
It's used to allow access to the OSU (Online Sign Up) network to allow initial
provisioning.
Yes, if the same AS server were used for both OSU ESS and production ESS a user
could theoretically leverage cross-method resumption to gain access to the
production ESS. Arguably, the same issue could occur with any two SSIDs using
the same AS irrespective of whether the EAP method was the same or not. This
isn't a fundamental issue with cross-method resumption or session resumption in
general, but a lack of appropriate binding between session tickets and the
context in which they're being used.
Regarding anonymous outer identities and re-authorization, the real-world
solution I've seen and implemented, is to associate the session ticket ID with
the user's NAI using a datastore when using stateful tickets, or to include the
user's NAI in the opaque data portion of sateless tickets. Similar methods
could be used to prevent cross-method resumption if local policies require it.
-Arran
signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 8, 2019, at 7:21 AM, John Mattsson wrote:
> (Everything below is from a pure EAP-TLS (0x0d) perspective without
> considering any cross-method things)
>
> - From an EAP-TLS perspective, I think these two cases ("not authenticated"
> and "authenticate via some other means") are the same, the peer is not
> authenticated as far as EAP-TLS is concerned. I read the sentence "other
> means" as outside of TLS.
>
> - RFC 5216 allows deployments with only server authentication:
>
> RFC 5216: "While the EAP server SHOULD require peer authentication, this is
> not mandatory, since there are circumstances in which peer authentication
> will not be needed (e.g., emergency services, as described in [UNAUTH]), or
> where the peer will authenticate via some other means."
>
> I don't know if there exists EAP-TLS (0x0d) deployments where the "peer
> authentication will not be needed" or "peer will authenticate via some other
> means", but if they do exist, we should probably not forbid them to do
> resumption unless we have good reasons.
I agree.
I can't think of any deployment which allows unauthenticated EAP-TLS. Or
authenticated only via the NAI.
> - Looking at e.g. emergency services (RFC 7406), the peer would indicate
> emergency by forming a specific NAI, the network access would then have to be
> restricted based on the fact that the peer is unauthenticated. With this
> functionality in place, I do not see that resumption as such is the problem.
I agree.
> I think draft-ietf-emu-eap-tls13 needs some sentence about the peer can use
> specific NAIs to affect the server's behaviour. Emergency services being one.
> Was there anything in the discussion between Alan DeKok and Dr. Pala about
> identities that should be added to draft-ietf-emu-eap-tls13? I need to get
> back to that thread.
There wasn't any discussion about that use-case.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Mohit Sethi M ; wrote:
>
>For me, an EAP-TLS server should not only refuse resumption if a client
>was not authenticated, it should also refuse resumption if the client
>was authenticated with other methods than certificates (such as passwords).
>Do you agree?
(Everything below is from a pure EAP-TLS (0x0d) perspective without considering
any cross-method things)
- From an EAP-TLS perspective, I think these two cases ("not authenticated" and
"authenticate via some other means") are the same, the peer is not
authenticated as far as EAP-TLS is concerned. I read the sentence "other means"
as outside of TLS.
- RFC 5216 allows deployments with only server authentication:
RFC 5216: "While the EAP server SHOULD require peer authentication, this is not
mandatory, since there are circumstances in which peer authentication will not
be needed (e.g., emergency services, as described in [UNAUTH]), or where the
peer will authenticate via some other means."
I don't know if there exists EAP-TLS (0x0d) deployments where the "peer
authentication will not be needed" or "peer will authenticate via some other
means", but if they do exist, we should probably not forbid them to do
resumption unless we have good reasons.
- Looking at e.g. emergency services (RFC 7406), the peer would indicate
emergency by forming a specific NAI, the network access would then have to be
restricted based on the fact that the peer is unauthenticated. With this
functionality in place, I do not see that resumption as such is the problem.
I think draft-ietf-emu-eap-tls13 needs some sentence about the peer can use
specific NAIs to affect the server's behaviour. Emergency services being one.
Was there anything in the discussion between Alan DeKok and Dr. Pala about
identities that should be added to draft-ietf-emu-eap-tls13? I need to get back
to that thread.
Cheers,
John
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 7, 2019, at 4:26 AM, Mohit Sethi M wrote: > > Hi Alan, John, > ... > For me, an EAP-TLS server should not only refuse resumption if a client > was not authenticated, it should also refuse resumption if the client > was authenticated with other methods than certificates (such as passwords). > > Do you agree? You already asked that question, and my answer was "no". Asking again won't change that answer. If the server decides that a particular user is authenticated, the server can choose to allow session resumption. I fail to see how changing octet 5 of the EAP packet changes any of the security properties. And the explanations so far don't address any of my questions about this topic. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Hi Alan, John, On 2/6/19 2:44 PM, Alan DeKok wrote: > On Feb 6, 2019, at 3:54 AM, John Mattsson wrote: >> I think this is a very good discussion to have. Any problems with peer >> authentication would (at least in theory) affect pure EAP-TLS as well. RFC >> 5216 states that: >> >> RFC 5216: "While the EAP server SHOULD require peer authentication, this is >> not mandatory, since there are circumstances in which peer authentication >> will not be needed (e.g., emergency services, as described in [UNAUTH]), or >> where the peer will authenticate via some other means." >> >> So even for EAP-TLS to EAP-TLS resumption, the EAP/TLS server needs to store >> information about if the peer/client was authenticated or not. If client >> authentication was done, I assume the EAP/TLS server stores information >> about who the peer was, or? >Yes. Typically the peer information is cached locally, and keyed via the > TLS session ID. > >Or, the information is encrypted and placed into the TLS session ticket, > and handed to the client. The client uses the ticket to resume the session, > and the server can decrypt it. > >This practice goes back to the first implementations of session > resumption. Because the alternative is to "resume" a session, when you have > no idea if the person resuming the session is the same one you originally > authenticated. Which seems an obvious security hole. > >For EAP-TLS, it's likely worth making a note that the server MUST track > the authenticated status of a session, and refuse to resume a session when > authentication had not completed. For me, an EAP-TLS server should not only refuse resumption if a client was not authenticated, it should also refuse resumption if the client was authenticated with other methods than certificates (such as passwords). Do you agree? --Mohit > >Alan DeKok. > > ___ > 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
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 6, 2019, at 3:54 AM, John Mattsson wrote: > > I think this is a very good discussion to have. Any problems with peer > authentication would (at least in theory) affect pure EAP-TLS as well. RFC > 5216 states that: > > RFC 5216: "While the EAP server SHOULD require peer authentication, this is > not mandatory, since there are circumstances in which peer authentication > will not be needed (e.g., emergency services, as described in [UNAUTH]), or > where the peer will authenticate via some other means." > > So even for EAP-TLS to EAP-TLS resumption, the EAP/TLS server needs to store > information about if the peer/client was authenticated or not. If client > authentication was done, I assume the EAP/TLS server stores information about > who the peer was, or? Yes. Typically the peer information is cached locally, and keyed via the TLS session ID. Or, the information is encrypted and placed into the TLS session ticket, and handed to the client. The client uses the ticket to resume the session, and the server can decrypt it. This practice goes back to the first implementations of session resumption. Because the alternative is to "resume" a session, when you have no idea if the person resuming the session is the same one you originally authenticated. Which seems an obvious security hole. For EAP-TLS, it's likely worth making a note that the server MUST track the authenticated status of a session, and refuse to resume a session when authentication had not completed. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
I think this is a very good discussion to have. Any problems with peer authentication would (at least in theory) affect pure EAP-TLS as well. RFC 5216 states that: RFC 5216: "While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances in which peer authentication will not be needed (e.g., emergency services, as described in [UNAUTH]), or where the peer will authenticate via some other means." So even for EAP-TLS to EAP-TLS resumption, the EAP/TLS server needs to store information about if the peer/client was authenticated or not. If client authentication was done, I assume the EAP/TLS server stores information about who the peer was, or? /John ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 5, 2019, at 11:16 AM, Mohit Sethi M wrote: > > Peer/Client authentication in stage 1 of EAP-TTLS is optional. So there > is probably no difference if you do EAP-TLS first and then possibly use > EAP-TTLS resumption. OK. > But the other way, EAP-TTLS/EAP-PEAP first and then > EAP-TLS resumption is not the okay. That is because you can't know how > and when the client was authenticated with EAP-TTLS/EAP-PEAP. Presumably it's the same authentication server for all authentication methods. Which means that the authentication server is already allowing session resumption. So by your argument, allowing session resumption for TTLS may be OK. Allowing session resumption for EAP-TLS is not OK, because octet 5 is different, and authentication with EAP-TLS is different than authentication with TTLS. I think we're going in a loop here. I just don't see how there's any quantitative difference, and your examples aren't really convincing me. > I think we are in agreement that there is not good reason to allow such > cross method resumption and that this should be forbidden as such. No that is *not* what I said. I don't see an issue with cross-method session resumption. I'm happy to allow it. I was pretty clear on that. What I'm saying is that if there's no consensus that it should be allowed, then I'm fine with forbidding it. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Hi Alan, On 2/5/19 5:48 PM, Alan DeKok wrote: > On Feb 5, 2019, at 10:18 AM, Mohit Sethi M wrote: >> But session resumption is not simply about changing one byte in the EAP >> conversation. If you look at Figure 2 of draft-ietf-emu-eap-tls13-03 >> (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-03), a server is >> issuing a NewSessionTicket only after receiving the TLS Finished from >> the client, at which point it has authenticated the client identity. >Yes... > >> What you are suggesting is that the server should issue a >> NewSessionTicket even before the client has been authenticated (which is >> the case for other TLS based EAP methods) and then only use that for >> resumption. This is significant difference. >No, that's not what I'm saying. I'm not sure why there's confusion. > >I'm saying this: > > 1) user is authenticated via EAP-TLS as normal > > 2) user gets a session ticket for fast session resumption > > 3) user tries to resume the session using the session ticket. > >My questions here are about (3). > > a) Can the user resume via EAP-TLS? Clearly, yes. > > b) Can the user resume via TTLS? In practice, very likely, yes > >OK... so should we disallow (b)? If so, why? If not, why not? > >> Also, client authentication with an easy-to-guess password inside a TLS >> tunnel is different than client authentication with a certificate. Which >> is why I stated the difference in security properties and proofs. >That's true, but is only one part of the situation. > >What about doing an EAP-TLS session, and then resuming via TTLS? That is > a strong authentication with a certificate. How is that resumption > *quantitatively different* from resuming via EAP-TLS? Peer/Client authentication in stage 1 of EAP-TTLS is optional. So there is probably no difference if you do EAP-TLS first and then possibly use EAP-TTLS resumption. But the other way, EAP-TTLS/EAP-PEAP first and then EAP-TLS resumption is not the okay. That is because you can't know how and when the client was authenticated with EAP-TTLS/EAP-PEAP. > >In that situation, the difference *is* exactly octet 5 of the EAP packet. > So again, what *other* difference would forbid that kind of session > resumption? > >We also PEAP with inner MS-CHAP, versus TTLS with inner MS-CHAP. In that > case, both methods have similar data for inner authentication. So why forbid > cross-method session resumption? > >Or authenticating via TTLS with client certs, and resuming via EAP-TLS. > For that situation, they have similar security properties. > >In the end, if a site administrator says "I allow passwords and session > resumption", that should work. I still don't see any quantitative difference > when session resumption is done while changing octet 5 of the EAP packet. > Saying "security properties" when only octet 5 has changed isn't a convincing > argument. > >Maybe the answer here is "we have no idea what cross-method session > resumption means, and therefore we forbid it". > >That's a good answer. But if there are reasons for doing so, I wish to > understand those reasons. I think we are in agreement that there is not good reason to allow such cross method resumption and that this should be forbidden as such. --Mohit > >Alan DeKok. > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 5, 2019, at 10:18 AM, Mohit Sethi M wrote: > > But session resumption is not simply about changing one byte in the EAP > conversation. If you look at Figure 2 of draft-ietf-emu-eap-tls13-03 > (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-03), a server is > issuing a NewSessionTicket only after receiving the TLS Finished from > the client, at which point it has authenticated the client identity. Yes... > What you are suggesting is that the server should issue a > NewSessionTicket even before the client has been authenticated (which is > the case for other TLS based EAP methods) and then only use that for > resumption. This is significant difference. No, that's not what I'm saying. I'm not sure why there's confusion. I'm saying this: 1) user is authenticated via EAP-TLS as normal 2) user gets a session ticket for fast session resumption 3) user tries to resume the session using the session ticket. My questions here are about (3). a) Can the user resume via EAP-TLS? Clearly, yes. b) Can the user resume via TTLS? In practice, very likely, yes OK... so should we disallow (b)? If so, why? If not, why not? > Also, client authentication with an easy-to-guess password inside a TLS > tunnel is different than client authentication with a certificate. Which > is why I stated the difference in security properties and proofs. That's true, but is only one part of the situation. What about doing an EAP-TLS session, and then resuming via TTLS? That is a strong authentication with a certificate. How is that resumption *quantitatively different* from resuming via EAP-TLS? In that situation, the difference *is* exactly octet 5 of the EAP packet. So again, what *other* difference would forbid that kind of session resumption? We also PEAP with inner MS-CHAP, versus TTLS with inner MS-CHAP. In that case, both methods have similar data for inner authentication. So why forbid cross-method session resumption? Or authenticating via TTLS with client certs, and resuming via EAP-TLS. For that situation, they have similar security properties. In the end, if a site administrator says "I allow passwords and session resumption", that should work. I still don't see any quantitative difference when session resumption is done while changing octet 5 of the EAP packet. Saying "security properties" when only octet 5 has changed isn't a convincing argument. Maybe the answer here is "we have no idea what cross-method session resumption means, and therefore we forbid it". That's a good answer. But if there are reasons for doing so, I wish to understand those reasons. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Hi Alan, On 2/5/19 3:13 PM, Alan DeKok wrote: > On Feb 5, 2019, at 12:19 AM, Mohit Sethi M wrote: >> Do you have experience with such cross method resumption? Are there any >> deployments that make use of this? >There are no deployments that make use of it. It's worked in my testing. > >> My initial reaction is that such cross method session resumption should >> be forbidden. That is because EAP-TLS has different security properties >> where both the peer and server are mutually authenticated with TLS and >> certificates. Mixing it with other EAP methods that use TLS only for >> server authentication complicates the security properties and proofs. >I'm not sure how. > >Cross-method session resumption is essentially just changing byte 5 (type) > of the EAP conversation. Pretty much everything else remains the same. > >In the implementations I've seen, that really *is* the difference. No one > is going to implement TLS over EAP 5 times: once for EAP-TLS, then TTLS, > PEAP, TEAP, FAST, ... > >Instead, they use a common EAP layer, and a common TLS layer. Only once > the TLS session has been established is there any method-specific (i.e. > inner-tunnel) code run, and data exchanged. > >So it's not clear to me how doing session resumption with byte 5 == 0x0d > (EAP-TLS) is fine, but doing it with byte 5 == 0x15 (TTLS) is insecure. Indeed, TLS based EAP method implementations typically use a common underlying TLS implementation. But session resumption is not simply about changing one byte in the EAP conversation. If you look at Figure 2 of draft-ietf-emu-eap-tls13-03 (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-03), a server is issuing a NewSessionTicket only after receiving the TLS Finished from the client, at which point it has authenticated the client identity. What you are suggesting is that the server should issue a NewSessionTicket even before the client has been authenticated (which is the case for other TLS based EAP methods) and then only use that for resumption. This is significant difference. Also, client authentication with an easy-to-guess password inside a TLS tunnel is different than client authentication with a certificate. Which is why I stated the difference in security properties and proofs. I still maintain my initial position that such cross-method resumption should be forbidden. --Mohit > >> Also, EAP methods that only use TLS for the outer tunnel (TTLS, PEAP, >> etc.) typically begin with an anonymous NAI for privacy. What NAI would >> such peers use if they rely solely on TLS based resumption? >The answer here is one of two things: > > a) the authentication server caches user information bases on the TLS session > ID > > b) the authentication server encrypts user information, and sends it to the > client as part of the session ticket. > >Either method allows the authentication server to resume the session based > on the *real* NAI of the user. > >This has *always* been the problem with TLS-based session resumption. > > My concern here is that this practice has been implemented and widely > deployed for many years. The problem of (and solution for) the anonymous NAI > and TLS-based session resumption has been known for a long time. > >> As a co-author of draft-ietf-emu-eap-tls13, I don't think we should >> support such cross method resumption. If anything, this should be >> discouraged/forbidden. >I'm happy to do that, I'd just like to understand the reasons behind doing > it. > >Alan DeKok. > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 5, 2019, at 12:19 AM, Mohit Sethi M wrote: > Do you have experience with such cross method resumption? Are there any > deployments that make use of this? There are no deployments that make use of it. It's worked in my testing. > My initial reaction is that such cross method session resumption should > be forbidden. That is because EAP-TLS has different security properties > where both the peer and server are mutually authenticated with TLS and > certificates. Mixing it with other EAP methods that use TLS only for > server authentication complicates the security properties and proofs. I'm not sure how. Cross-method session resumption is essentially just changing byte 5 (type) of the EAP conversation. Pretty much everything else remains the same. In the implementations I've seen, that really *is* the difference. No one is going to implement TLS over EAP 5 times: once for EAP-TLS, then TTLS, PEAP, TEAP, FAST, ... Instead, they use a common EAP layer, and a common TLS layer. Only once the TLS session has been established is there any method-specific (i.e. inner-tunnel) code run, and data exchanged. So it's not clear to me how doing session resumption with byte 5 == 0x0d (EAP-TLS) is fine, but doing it with byte 5 == 0x15 (TTLS) is insecure. > Also, EAP methods that only use TLS for the outer tunnel (TTLS, PEAP, > etc.) typically begin with an anonymous NAI for privacy. What NAI would > such peers use if they rely solely on TLS based resumption? The answer here is one of two things: a) the authentication server caches user information bases on the TLS session ID b) the authentication server encrypts user information, and sends it to the client as part of the session ticket. Either method allows the authentication server to resume the session based on the *real* NAI of the user. This has *always* been the problem with TLS-based session resumption. My concern here is that this practice has been implemented and widely deployed for many years. The problem of (and solution for) the anonymous NAI and TLS-based session resumption has been known for a long time. > As a co-author of draft-ietf-emu-eap-tls13, I don't think we should > support such cross method resumption. If anything, this should be > discouraged/forbidden. I'm happy to do that, I'd just like to understand the reasons behind doing it. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Hi Alan, Do you have experience with such cross method resumption? Are there any deployments that make use of this? My initial reaction is that such cross method session resumption should be forbidden. That is because EAP-TLS has different security properties where both the peer and server are mutually authenticated with TLS and certificates. Mixing it with other EAP methods that use TLS only for server authentication complicates the security properties and proofs. Also, EAP methods that only use TLS for the outer tunnel (TTLS, PEAP, etc.) typically begin with an anonymous NAI for privacy. What NAI would such peers use if they rely solely on TLS based resumption? As a co-author of draft-ietf-emu-eap-tls13, I don't think we should support such cross method resumption. If anything, this should be discouraged/forbidden. --Mohit On 2/1/19 7:49 PM, Alan DeKok wrote: >This question isn't directly applicable to EAP-TLS, but it is related. > >There are multiple EAP methods that use TLS, and presumably all of them > will enable session resumption. The question is, what do we do with > cross-method session resumption? > > i.e. a user starts with EAP-TLS, and then tries to "resume" his session, > but this time uses TTLS. It's not clear that anything in the spec forbids or > prevents this. > >It's not clear if this resumption is an issue, but it should be > highlighted. > >The issue is made more difficult by the fact that session resumption is > usually done at the TLS layer. This means there is minimal ability for the > EAP layer to cross-check method types. > >If we do allow it, it should be called out explicitly in the EAP-TLS > document. If we don't allow it, we should find a way to forbid it. > >Alan DeKok. > > ___ > 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
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 2, 2019, at 12:03 PM, John Mattsson wrote: > Good suggestion, I'll add something like that to the resumption section in > draft-ietf-emu-eap-tls13 Thanks. >> e.g. TTLS and PEAP both allow session resumption, and when done, skip the >> phase 2 / inner-tunnel authentication. > > That seems like it could be a security problem in some implementations as > cross-method resumption is not discussed anywhere and TTLS and PEAP says that > inner-tunnel authentication is skipped for TLS resumption... I'm not sure what security problems there are. If a user authenticates via TTLS/PEAP, and resumes via PEAP/TTLS, the protocol flow is almost exactly the same. i.e. the only real difference between the resumed sessions is that one is encapsulated in PEAP, and the other in TTLS. They're otherwise identical. > Your planned document on TLS 1.3 for other EAP methods should have some text > describing this. Rather that forbidding cross-method resumption for TTLS and > PEAP, I assume one could just specify that inner-tunnel authentication must > be done after cross-method resumption. Or? I think it's fine to skip inner authentication. If the EAP server needs to do additional *authorization*, it can always refuse to resume the session. But if there's no additional authorization, I don't see any issue here. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Alan DeKok ; wrote: >I would suggest then referencing or duplicating the above text, and saying >something like: > >--- >Implementations SHOULD be capable of session resumption across different >TLS-based EAP types. This recommendation is made for a few reasons. It is >recommended by [RFC7301], there appears to be no compelling reason to forbid >it, and implementations can always choose to reject session resumption based >on local policies. > >Some EAP types have complex state and negotiation. For this EAP types, >session resumption across different EAP types may not be possible, and if not >possible, MUST be forbidden by both specifications and implementations. >Additional discussion of this topic is outside of the scope of this document. >--- Good suggestion, I'll add something like that to the resumption section in draft-ietf-emu-eap-tls13 > e.g. TTLS and PEAP both allow session resumption, and when done, skip the > phase 2 / inner-tunnel authentication. That seems like it could be a security problem in some implementations as cross-method resumption is not discussed anywhere and TTLS and PEAP says that inner-tunnel authentication is skipped for TLS resumption... Your planned document on TLS 1.3 for other EAP methods should have some text describing this. Rather that forbidding cross-method resumption for TTLS and PEAP, I assume one could just specify that inner-tunnel authentication must be done after cross-method resumption. Or? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
On Feb 2, 2019, at 6:50 AM, John Mattsson wrote: > Very good that this is discussed and highlighted. > > My understanding is that TLS itself clearly allows a resumed connection to be > used for a completely different purpose. The ALPN specification (RFC 7301) > says that: > > "When session resumption or session tickets [RFC5077] are used, the previous > contents of this extension are irrelevant, and only the values in the > new handshake messages are considered." > > I don't know how important this feature is in EAP, but if it is useful and do > not cause security problems, we should probably not forbid it. I would suggest then referencing or duplicating the above text, and saying something like: --- Implementations SHOULD be capable of session resumption across different TLS-based EAP types. This recommendation is made for a few reasons. It is recommended by [RFC7301], there appears to be no compelling reason to forbid it, and implementations can always choose to reject session resumption based on local policies. Some EAP types have complex state and negotiation. For this EAP types, session resumption across different EAP types may not be possible, and if not possible, MUST be forbidden by both specifications and implementations. Additional discussion of this topic is outside of the scope of this document. --- e.g. TTLS and PEAP both allow session resumption, and when done, skip the phase 2 / inner-tunnel authentication. In contrast, FAST and TEAP both still require phase2 to occur after session resumption. The session resumption there is just used to skip the TLS negotiation. And the MSK / EMSK depends on the inner tunnel authentication methods, so the TLS-Exporter() function needs more than just the TLS parameters. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Hi Alan, Very good that this is discussed and highlighted. My understanding is that TLS itself clearly allows a resumed connection to be used for a completely different purpose. The ALPN specification (RFC 7301) says that: "When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered." I don't know how important this feature is in EAP, but if it is useful and do not cause security problems, we should probably not forbid it. Cheers, John ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Notes on session resumption with TLS-based EAP methods
This question isn't directly applicable to EAP-TLS, but it is related. There are multiple EAP methods that use TLS, and presumably all of them will enable session resumption. The question is, what do we do with cross-method session resumption? i.e. a user starts with EAP-TLS, and then tries to "resume" his session, but this time uses TTLS. It's not clear that anything in the spec forbids or prevents this. It's not clear if this resumption is an issue, but it should be highlighted. The issue is made more difficult by the fact that session resumption is usually done at the TLS layer. This means there is minimal ability for the EAP layer to cross-check method types. If we do allow it, it should be called out explicitly in the EAP-TLS document. If we don't allow it, we should find a way to forbid it. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
