Subject: Re: EAP-SRP and identity privacy

From: Jacques Caron <[email-masked]>
Date: Wed, 20 Jun 2001 16:21:56 +0200

Hi,

This raises the issue of the real privacy of sessions keys. As I pointed 
out to James earlier, it is quite necessary to make sure that the 
authenticatee knows whether the derived keys are kept by the authenticator 
and authenticatee only, or if the authenticator will then send them to the 
link-layer endpoint (NAS, Access point...) for link encryption purposes 
(PPP ECP, WEP...).

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.

Otherwise the authenticatee might be tricked into sending information using 
a derived key, which it thinks only the authenticator knows, while the 
NAS/AP actually also knows it.

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

I mucht have miched chomeching here...

Jacques.

At 16:09 20/06/01, [email-masked] wrote:

>Hi all,
>
>Here is a proposal how to include identity privacy
>support in the EAP-SRP draft.
>
>We could add a new (optional?) field called "next pseudonym"
>in the EAP-Request/SRP-SHA1/Server Validator message. A "pseudonym"
>would be recoverable from this field using the session key K, so
>it would be available to the authenticatee only. Eavesdroppers are
>not able to recover the pseudonym.
>
>In the next EAP authentication, the authenticatee can use the
>pseudonym obtained during the previous authentication as the client
>name C, hence making consecutive authentications unlinkable to everyone
>else but the authenticator. The cleartext client name needs to be
>send only if a pseudonym is not available (in the very first
>authentication).
>
>Note that the authenticator would not need to maintain state in
>order to generate pseudonyms. Pseudonyms could be
>obtained by encrypting the client name with random salt,
>using a key that is known to the authenticator only.
>
>Regards,
>Henry

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Jun 2001 12:12:48 -0700 (PDT)

> NAS/AP actually also knows it.

The keys are ONLY for use at the link layer, right? They MUST NOT be
used for anything else! I'd note that the client doesn't really know who
he's talking to -- with L2TP compulsory tunneling, it might be a tunnel
server halfway around the world, not the NAS. So all the client really
knows is that the other side of the link has obtained the keys it
previously negotiated.

---

From: Jacques Caron <[email-masked]>
Date: Wed, 20 Jun 2001 23:08:44 +0200

>knows is that the other side of the link has obtained the keys it

Actually, the "standard" is rather the opposite. At the end of EAP 
negociation, the only two machines to hold the derived session key are the 
two EAP endpoints, i.e. the authenticatee (the dialup/wireless/whatever 
client) and the authenticator (the Radius/Diameter server, unless the 
NAS/AP/whatever is actually the EAP endpoint).

Now, the obvious application of this session key is encryption, which is 
done between the two link-layer endpoints (PPP ECP, 802.11 WEP, PPTP or 
L2TP ECP...). One the "client" side, no problem, since the endpoints for 
EAP and encryption are the same. On the other side, they are most probably 
different. So we need to have the auth server send the key to the 
NAS/AP/whatever.

On the other hand, there might be other mechanisms (such as the one exposed 
by Henry) that require the key to remain secret between the two EAP 
endpoints. And in still other scenarios, you might need both:
- a key that is only known by the two EAP endpoints (client & auth server)
- a key that is known by the two link-layer endpoints (client & NAS/AP), as 
well as the auth server as a side effect of the process of obtaining those.

At the least, the client should be able to know whether the key was derived 
purely locally by the remote endpoint (i.e. the EAP peer == the encryption 
peer) or has travelled across a network, encrypted or not. At best, there 
should be two keys, and the client should be told which one to use for the 
purposes of link-layer encryption.

Note that another application of a key known only by the EAP endpoints 
would be a "quick reauth"... EAP/SRP is quite heavy, both in terms of 
network roundtrips and CPU usage, you might not want to run that every 
minute or so. So, a "simpler" reauth, e.g. server sends a challenge, client 
sends back the challenge encrypted with the session key, would be nice. But 
you need to make sure the NAS doesn't know that key, if you want to avoid 
accounting settlement issues (in a roaming environment).

Jacques.

---

From: James Carlson <[email-masked]>
Date: Thu, 21 Jun 2001 07:31:02 -0400 (EDT)

Jacques Caron writes:
[...]
> So we need to have the auth server send the key to the 
> NAS/AP/whatever.

I'm not really comfortable with that notion.  I don't like the idea of
simply transporting session keys from box to box.  It rather defeats
the purpose of doing this nifty DH-style key exchange in the first
place.

Fortunately, this doesn't appear to me to really be an issue for the
PPP wg.  It's a generic issue for NASREQ/AAA: "if an authentication
mechanism produces an encryption session key as a side-effect, is this
transported from the server to the NAS and, if so, how?"

> purposes of link-layer encryption.

OK.  How about this?  We add a flag to the Server and Client Validator
messages.  If this flag is set, then that peer intends to use the
session key with any ECP that may be negotiated.  If it's not, then
the peer won't use the session key.

There's no need to negotiate this; merely informing the peer of intent
does the job.  If either doesn't agree, then the key won't be used.

This mechanism solves the problem for systems that can't access the
key for some reason (those with some sort of proxy authentication),
and those that expect some other keying mechanism (external).

> accounting settlement issues (in a roaming environment).

Also an interesting idea, though it may leak key material into the
data stream.  As long as it's limited in use on both ends, it sounds
ok.

How about this?  Authenticator generates a random number (R) and
computes H1 = SHA1(R | <id-number> | "server" | <server-name-if-any> |
K).  Authenticator sends Request {R, H1} using a new subtype 4.
Authenticatee validates H1 and disconnects in an implementation-
dependent way if H1 is invalid.  Otherwise, it responds either with
Response subtype 4 or, if it doesn't wish to participate in this type
of rechallenge for any reason (too many in a row, for instance), EAP
Nak with hint of SRP-SHA1 in order to restart full EAP SRP-SHA1
authentication.  The Response subtype 4, if given, would contain just
H2, calculated as SHA1(R | <id-number> | "client" | <true-client-name>
| K).

(This assumes the <server-name-if-any> is present in the original
challenge [subtype 1 request], as it will be in the next rev of the
draft.  I inadvertently left that out even though it's in the code
I've got.)

-- 
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