Re: [SECMECH] Are EAP-Methods RFIDs ?

["T. Charles Clancy" <clancy at cs.umd.edu>]

On Thu, 10 Nov 2005, Pascal Urien wrote:

> The TLS resume mode (RFC 2246, section 7.3) is a nice candidate for the 
> PSK authentication class. The pre shared key is equal to the master 
> secret, and is associated to a session-id that works like a login 
> (EAP-ID,...).
>
> ...
>
> So what is wrong with EAP-TLS, with resume mode as PSK EAP method ?

Perhaps TLS-PSK would be a more conventional way of doing about the same 
thing?

http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-09.txt

> In EAP-TLS, EAP-SIM or EAP-AKA it's very easy to get, with no 
> protection, the user ID, for example its permanent EAP-ID, certificates 
> or full identity. It's mean that even when these protocols claim 
> anonymity properties, it's possible to collect user's identities, which 
> in many case is an issue for privacy. concerns.
>
> ...
>
> Are EAP methods really dealing today with user's privacy (from its 
> identity protection point of view)? It seems that many EAP methods work 
> like RFIDs.

EAP-TLS does not provide identity protection.  SIM and AKA use 
pseudonym-based approaches which have known faults.

The tunneling methods PEAP, TTLS, and FAST all provide secure identity 
protection via public-key approaches, as does PAX.

> It doesn't look easy to conciliate mutual authentication and identity 
> protection. On the peer side this should imply the secure storage of 
> some information (like next identity, next EAP-ID, next protection 
> key,...) computed during the last EAP session.
>
> ...
>
> In my opinion there is strong need to ensure anonymity in EAP context. 
> Do we intend to work on that subject ?

I don't see what the issue is... we have several methods already that 
accomplish mutual authentication and identity protection.

If you want to do secure identity protection *without* public key 
computations, it gets a little tricker.  You'll have to use a 
pseudonym-type scheme, which has desynchronization problems.  I don't see 
how adding smartcards really changes anything.  In the IETF we're focused 
on protocols, not secure data storage.  Distinguising smartcard use would 
be like having a different EAP method depending on whether you were 
authenticating from a laptop vs a desktop.

[ t. charles clancy ]--[ tcc at umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

_______________________________________________
SECMECH mailing list
SECMECH at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech