On Feb 8, 2019, at 7:21 AM, John Mattsson <john.matts...@ericsson.com> wrote:
> (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.
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 unauthenticated. With this
> functionality in place, I do not see that resumption as such is the problem.
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 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.
There wasn't any discussion about that use-case.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
