Subject: RE: EAP-SRP and identity privacy

From: [email-masked]
Date: Wed, 20 Jun 2001 18:05:36 +0300

Jacques,

> Or, even better, two sets of keys should actually be derived, 
> one for each 
> application. One set would be kept on the EAP endpoints only, 
> while the 
> other could be sent (via Radius, Diameter or any other 
> protocol) to the NAS/AP.

That's true. The key that is used to send data securely
from the authenticator to the authenticatee should be
separate from the keys that are sent to the NAS/AP
so that the pseudonyms won't become linkable to the NAS/AP.
We could use a pseudo random function to derive 
session keys for each application from the "master" 
session key.

> More specifically to your proposal:
> - I don't understand why it would be the authenticator which 
> would generate 
> the pseudonym? I would rather think it should be the 
> authenticatee that 
> would send an encrypted version of its "real" username?

The problem is what key the authenticatee should use to
encrypt the username. There is a chicken-egg problem:
you can't have a key to protect the user-name until you've provided 
the user-name so as to enable the key exchange.
So we need to use a pseudonym obtained in a previous 
authentication.

The pseudonym _can_ be an encrypted version of the real username,
but it needs to be encrypted by the authenticator, with an internal
(private) key it uses for all clients. Then the authenticator 
can recover the real username by decrypting the pseudonym.

> - what identity should be used in the first request, that 
> would not reveal 
> the identity of the user? Some share identity (and password)?

It is hard not to reveal the identity, so I think the real cleartext 
client name can be used. We need to transmitit the very 
first time the user uses the terminal. After that the 
authentication software on the terminal should have a cached 
pseudonym available for the user.

Regards,
Henry

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Jun 2001 11:28:10 -0400 (EDT)

> session keys for each application from the "master" 

The problem with separating the authenticator function from the NAS
itself is that I don't see a good way for the NAS to get *any* sort of
key out of the exchange.

That problem is why I punted on the whole issue.

> So we need to use a pseudonym obtained in a previous 

More than that, it has to be picked by the authenticator side so that
there's no possibility of collisions with other clients.  If the
authenticatee picks it, and it somehow duplicates the name that
someone else uses (imagine a bad implementation that just gives the
pseudonym as the constant string "foo"), then the authenticator is in
trouble.

> pseudonym available for the user.

An implementation option would be to have an "always use pseudonym, if
available" flag.  The semantics would be that, if set, the client
would establish a connection using the real name.  If that connection
resulted in a pseudonym (i.e., the authenticator supports this
feature), then the client would disconnect and reconnect.  On this
(and subsequent) connections, only the pseudonym would be used, and
network data transfer would then be enabled.

What we're really talking about here are nonces.  So here's an
alternative implementation: server generates random value P, and
includes this in the Server Validator message.  Both client and server
calculate SHA1(P | K) and save this value in stable storage.  On a
subsequent authentication sessions, the client offers SHA1(P | K) as
its identity.

This avoids having to do any sort of encryption.

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Jacques Caron <[email-masked]>
Date: Wed, 20 Jun 2001 17:54:04 +0200

>itself is that I don't see a good way for the NAS to get *any* sort of

That's something that is supposed to be dealt with in Diameter (and maybe 
Radius). Cisco APs using 802.1x/EAP already get the session keys back via 
Radius, if I'm not mistaken.

The idea is simply that the auth server will send (encrypted) session keys 
to the NAS/AP upon completion of the EAP auth. But to still be able to have 
private communications between the authenticator and the authenticatee, 
there should be another set of keys.

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com