On Feb 18, 2019, at 1:49 AM, Arran Cudbard-Bell <[email protected]>
wrote:
>> I can't think of any deployment which allows unauthenticated EAP-TLS. Or
>> authenticated only via the NAI.
>
> 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 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.
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.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
