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

From: John Mattsson <[email-masked]>
Date: Fri, 8 Feb 2019 12:21:26 +0000

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

Mohit Sethi M <[email-masked]>; 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

---

From: Alan DeKok <[email-masked]>
Date: Fri, 8 Feb 2019 12:17:12 -0500

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

  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…

  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 betwee…

  There wasn't any discussion about that use-case.

  Alan DeKok.

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Mon, 18 Feb 2019 14:49:09 +0800

> On Feb 9, 2019, at 1:17 AM, Alan DeKok <[email-masked]> wrote:
> 

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Feb 2019 10:38:21 -0500

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

  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.