"Jim Schaad" <[email protected]> wrote
Mon, 24 Feb 2014 09:12:32 -0800:
| > | Section 2.2 - Passive observers may also be able to fingerprint the
| > | client based on TLS restart information.
| >
| > What does "TLS restart" mean in this context? Do you mean a RadSec client
| > re-establishing a torn down connection? Or maybe TLS renegotiation? Or,
| > most probably, something third that I'm not familiar with?
|
| Something else - TLS Session Resumption using server State or PAC (see
| sections 3.2.1 and 3.2.2 of draft-ietf-emu-eap-tunnel-method)
Good point. I added the following to upcoming -01.
--8<---------------cut here---------------start------------->8---
In cases where a TLS-based EAP method is used, a passive observer may
be able to fingerprint the client based on TLS session resumption, for
example as described in {{RFC5077}} section 5.8.
--8<---------------cut here---------------end--------------->8---
| > | Section 2.3 - This should include exposing the realm of the user (or
| > | the full user name in bad implementations).
| >
| > Do you refer to the "Mechanism Name", as described in RFC7055 section 3.1.
| > or is user realm (and possibly name) carried somewhere else?
|
| I was referring to exposing the user name, for those cases where people
| don't either tunnel it or don't truncate it to just the realm in the initial
| EAP message sent to the acceptor.
This is mentioned in 2.1. One could indeed argue that it should go here
instead, or both there and here.
| > | [ maybe expand on how TEAP [draft-ietf-emu-eap-tunnel-method
| > | <http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method> ] could
| > | solve the problem of AAA proxies learning the MSK, impersonating the
| > | RP ]
| > |
| > | I would be very interested in seeing how you think there could
| > | possibly be a solution in this space. I can't see one.
I still haven't worked this through really. Please let me know what's
wrong with the following sketch.
If an EAP peer and server (i.e. ABFAB client and IdP) establish a TLS
session using TEAP with a DHE key exchange, they will share an ephemeral
key which is not known to any intermediaries. The question is how peer
and server authenticate each other. In an ABFAB setting, client and IdP
share a secret in the user pass phrase and can use that as a PSK using a
TLS_DHE_PSK cipher suite.
An alternative authentication method might be TEAP password
authentication (Basic-Password-Auth-Req/Resp). Unless it isn't.
| > | There probably needs to be a nod to using an application level tunnel
| > | as well. While I think that it might be nice to have this in the
| > | GSS-EAP layer, we cannot ignore this as an option.
What about something like this, as an addition to section 3.1.?
--8<---------------cut here---------------start------------->8---
An alternative place to protect ABFAB authentication with a short
lived key would be in the application level protocol. While some
applications are using protocols already able to protect the GSS-API
traffic using a TLS session with an ephemeral key (XMPP, IMAP, SMTP)
it's not mandatory to use such a tunnel. Other applications use
protocols which might be hard to protect in a tunnel (NFS, SSH).
--8<---------------cut here---------------end--------------->8---
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
