Re: [SECMECH] Are EAP-Methods RFIDs ?

"T. Charles Clancy" <clancy@cs.umd.edu> Thu, 10 November 2005 16:41 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 1EaFUn-0007WV-KW; Thu, 10 Nov 2005 11:41:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFUl-0007Ts-Ly for secmech@megatron.ietf.org; Thu, 10 Nov 2005 11:41:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15370 for <secmech@ietf.org>; Thu, 10 Nov 2005 11:41:22 -0500 (EST)
Received: from ringding.cs.umd.edu ([128.8.129.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFl0-0007bt-BB for secmech@ietf.org; Thu, 10 Nov 2005 11:58:39 -0500
Received: from wonka.cs.umd.edu (wonka.cs.umd.edu [128.8.128.198]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id jAAGfc1q018974; Thu, 10 Nov 2005 11:41:39 -0500 (EST)
Date: Thu, 10 Nov 2005 11:41:38 -0500
From: "T. Charles Clancy" <clancy@cs.umd.edu>
To: Pascal Urien <urienp@tele2.fr>
Subject: Re: [SECMECH] Are EAP-Methods RFIDs ?
In-Reply-To: <5.2.1.1.0.20051110122529.03731388@pop.tele2.fr>
Message-ID: <Pine.GSO.4.61.0511101129140.27331@wonka.cs.umd.edu>
References: <5.2.1.1.0.20051110122529.03731388@pop.tele2.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: secmech@ietf.org
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

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@umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

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