Subject: [eap] Are EAP-Methods RFIDs ?

From: Pascal Urien <[email-masked]>
Date: Thu, 10 Nov 2005 12:18:50 +0100

Hi Everybody,

   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,...).

    From a cryptographic point of view, some security proof are available, 
see for example
   http://www.cl.cam.ac.uk/users/lcp/papers/Auth/tls.pdf  (4.6 Session 
Resumption)

    According to TLS properties many crypto suites can be used in order to 
proof the knowledge
    of the PSK (e.g the master secret), like RC4, DES, 3xDES, AES, ECC, .

    Because no certificates are used,.the number of exchanged bytes is 
quite small, around 200 bytes

    So what is wrong with EAP-TLS, with resume mode as PSK EAP method ?

    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.

    In 
http://www.ietf.org/internet-drafts/draft-badra-eap-double-tls-04.txt we 
propose to re-used the TLS
    resume mode, and we are focused on anonymity rather than introducing a 
new cryptographic issues.

    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.

    As an illustration this secure storage could be assumed by smartcards, 
like described in
    http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-09.txt

    In my opinion there is strong need to ensure anonymity in  EAP context. 
Do we intend to work
    on that subject ?

  Pascal

_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap