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

From: Arran Cudbard-Bell <[email-masked]>
Date: Thu, 7 Mar 2019 10:40:08 +0800

>   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

---

From: Alan DeKok <[email-masked]>
Date: Thu, 7 Mar 2019 20:41:16 -0500

> I know it's pedantic, but RFC 8446 obsoletes RFC 5077.

  Sure.

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

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

> 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

  Yes.

  Alan DeKok.

---

From: Jim Schaad <[email-masked]>
Date: Fri, 8 Mar 2019 17:17:17 -0800

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 <[email-masked]> On Behalf Of Alan DeKok
> Sent: Thursday, March 7, 2019 5:41 PM
> To: Arran Cudbard-Bell <[email-masked]>
> Cc: EMU WG <[email-masked]>
> Subject: Re: [Emu] Notes on session resumption with TLS-based EAP
> methods
> 
> > 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.
> 
>   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.
> 
> > The cached data isn't being updated, but it's being used together with
> > the unauthenticated information, right?
> 
>   Yes.
> 
>   Alan DeKok.
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Michael Richardson <[email-masked]>
Date: Sat, 09 Mar 2019 18:50:30 -0500

> does not contain any of the containing EAP authentication information that

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alan DeKok <[email-masked]>
Date: Sat, 9 Mar 2019 19:21:47 -0500

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

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

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

---

From: Jim Schaad <[email-masked]>
Date: Sat, 9 Mar 2019 16:46:58 -0800

> From: Emu <[email-masked]> On Behalf Of Michael Richardson
> Sent: Saturday, March 9, 2019 3:51 PM
> To: 'EMU WG' <[email-masked]>
>     > different types of EAP assuming that EAP correctly checks the output
of
> TLS
>     > 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.
> alan> session, but this time uses TTLS.  It's not clear that anything in
> alan> the spec forbids or prevents this.
> 
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

---

From: Alan DeKok <[email-masked]>
Date: Sun, 10 Mar 2019 08:58:19 -0400

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

---

From: Jim Schaad <[email-masked]>
Date: Sun, 10 Mar 2019 07:42:32 -0700

I would totally agree that this type of guidance needs to be added to this
document.

Jim

> From: Alan DeKok <[email-masked]>
> Sent: Sunday, March 10, 2019 5:58 AM
> To: Jim Schaad <[email-masked]>
> Cc: Michael Richardson <[email-masked]>; EMU WG
> <[email-masked]>
> > 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.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 10 Mar 2019 13:27:40 -0400

If there is no legit use case for TLS resumption, then it seems that EAP
servers SHOULD disable TLS resumption.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 10 Mar 2019 14:32:33 -0400

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