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
- [SECMECH] Are EAP-Methods RFIDs ? Pascal Urien
- Re: [SECMECH] Are EAP-Methods RFIDs ? T. Charles Clancy