On Feb 6, 2019, at 3:54 AM, John Mattsson <john.matts...@ericsson.com> 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
