Subject: [Emu] Notes on session resumption with TLS-based EAP methods

From: Alan DeKok <[email-masked]>
Date: Fri, 1 Feb 2019 12:49:33 -0500

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.

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 5 Feb 2019 05:19:34 +0000

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:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Feb 2019 08:12:55 -0500

> deployments that make use of this?

  There are no deployments that make use of it.  It's worked in my testing.

> 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.

> 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.

> support such cross method resumption. If anything, this should be 

  I'm happy to do that, I'd just like to understand the reasons behind doing it.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 5 Feb 2019 15:18:47 +0000

Hi Alan,

>    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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Feb 2019 10:47:57 -0500

> the client, at which point it has authenticated the client identity.

  Yes...

> 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?

> 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.

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 5 Feb 2019 16:16:12 +0000

Hi Alan,

>    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.
>    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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Feb 2019 14:59:10 -0500

On Feb 5, 2019, at 11:16 AM, Mohit Sethi M <[email-masked]> wrote:
> EAP-TTLS resumption.

  OK.

> But the other way, EAP-TTLS/EAP-PEAP first and then 

  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.

> 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.