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

From: John Mattsson <[email-masked]>
Date: Wed, 6 Feb 2019 08:54:25 +0000

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 6 Feb 2019 07:44:22 -0500

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

  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.

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 7 Feb 2019 09:26:49 +0000

Hi Alan, John,

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

---

From: Alan DeKok <[email-masked]>
Date: Thu, 7 Feb 2019 07:06:21 -0500

On Feb 7, 2019, at 4:26 AM, Mohit Sethi M <[email-masked]> wrote:
> ...

  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.