[SECMECH] Are EAP-Methods RFIDs ?

Pascal Urien <urienp@tele2.fr> Thu, 10 November 2005 11:26 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaAZU-0007vL-QA; Thu, 10 Nov 2005 06:26:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaAZS-0007sG-Mv for secmech@megatron.ietf.org; Thu, 10 Nov 2005 06:26:22 -0500
Received: from swip.net (mailfe08.tele2.fr [212.247.154.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25608 for <secmech@lists.ietf.org>; Thu, 10 Nov 2005 06:25:52 -0500 (EST)
X-T2-Posting-ID: TlrHmwDFCX01iQZd0Fm6v3T8FBlCqve5GwI1mWaefYU=
Received: from [80.170.70.45] (HELO DELL.tele2.fr) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.1) with ESMTP id 5920392 for secmech@lists.ietf.org; Thu, 10 Nov 2005 12:25:49 +0100
Message-Id: <5.2.1.1.0.20051110122529.03731388@pop.tele2.fr>
X-Sender: eu968071@pop.tele2.fr
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Thu, 10 Nov 2005 12:25:50 +0100
To: secmech@ietf.org
From: Pascal Urien <urienp@tele2.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc:
Subject: [SECMECH] Are EAP-Methods RFIDs ?
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org

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 


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