Subject: RE: EAP-SRP and identity privacy

From: [email-masked]
Date: Thu, 28 Jun 2001 17:34:19 +0300

> From: ext James Carlson [mailto:[email-masked]]
> 
> There are two issues here.  One is the generation of the pseudonym,
> which ought to be just a local implementation matter on the
> authenticator as far as EAP is concerned.  The only problem is that if
> there's proxy authentication going on (AAA), and the determination of
> the AAA server itself depends on a portion of the identity (e.g.,
> "[email-masked]"), then the NAS needs to recover enough of the real
> name to direct the query.

We could use cleartext domain portions in the pseudonyms,
so that a pseudomyn of "[email-masked]" would be something like
"[email-masked]". In other
words pseudonyms could be valid NAI's.
A drawback would be that the organization of the user would be
revealed to observers. But the operation of PPP, 802.1X, Radius 
proxies etc. wouldn't need to be modified.

>  What I'm going to recommend is that for
> proxy environments, the server use a long-term configured password
> (which MAY be the same password as used for AAA access), and hash this
> with the date (to the nearest day), and then use this as the key for a
> DES encryption of the real client ID.  This allows all NASes within a
> group to be able to decode the identity in a consistent manner.
> (Since the AAA server doesn't necessarily know that this decoding is
> going on, and DIAMETER at least just copies the EAP messages, it seems
> like this is a requirement on the generation of the pseudonym by the
> AAA server itself.)
> 
> Including the date in the hash above has two benefits.  The pseudonym
> for a given client changes unpredictably over time (frustrating the
> efforts of long-term traffic analysis) and the NAS can statelessly
> recover prior decoding keys to allow for graceful pseudonym encryption
> key change without dropping back to cleartext identity.

If we want to hide the organization, then I guess something like that
is required. Here the NAS must know how to decrypt the pseudonym or
the mechanism won't work. So this could cause interoperability problems. 
At least the client should be able to detect if the NAS doesn't support 
this feature, and then drop back to cleartext identity.

I'm inclined to think the solution should be conservative in what
it expects NAS'es to implement. Making the pseudonyms valid NAI's
by using cleartext domain names would be a backward compatible way 
to do this.

> I'm not wild about the EAP Failure approach because it will cause the
> authenticatee to disconnect and reconnect on most implementations.  On
> some common media, this can be an unnecessarily expensive proposition,
> and I don't see that it has any advantage.
> 
> Since the mechanism (pseudonym support) is brand new, I see no reason
> we can't overload the ID number semantics in a manner compatible with
> the spirit of RFC 2284.  That is, if the ID number is the same, then
> the authenticatee should assume that it's seeing a retransmission.
> The authenticator is required to do that anyway by section 2.2.1.  If
> the ID number is different, then the authenticator is clearly
> requesting a "new" identity which, in this context, means dropping
> back to the real client name.

You're right, disconnecting could be too expensive, and I also don't
see any reasons why your propsal wouldn't work. I guess even
current EAP implementations should have no problems with a second
EAP Identity Request.

> This exposes another problem.  You don't want to allow the
> authenticatee to be able to probe for valid real names using its EAP
> Identity Response messages.  This means that the use of the pseudonym
> must be clearly identifiable, and not just assumed on the
> authenticator's part merely because it doesn't match a known
> authenticatee name.  Prepending the text "Pseudonym" to the name in
> the EAP Identity Response message and requiring the EAP server to
> accept only one failed pseudonym per session does the trick.

That sounds like a good idea.

Regards,
Henry

---

From: James Carlson <[email-masked]>
Date: Thu, 28 Jun 2001 10:55:26 -0400 (EDT)

> proxies etc. wouldn't need to be modified.

It also means that the pseudonym has to be converted to some kind of
text representation.  I had been planning to use raw binary data for
it, but this is obviously friendlier and less troublesome.  If it's
bigger than the default MTU, then you probably have other identity
problems.  :-/

One sticking point is that the AAA server itself might not be aware of
the domain extension.  If so, then it can't add the appropriate
"@domain.org" to the pseudonym that it sends back through the NAS.
Either the NAS must be able to do this (meaning that the NAS rewrites
the EAP message arriving from the DIAMETER server on the fly ... yuck)
or the authenticatee must know to tack this string back on when using
the pseudonym.

Given that the client sent its real name with "@domain.org" in the
first place, I'm inclined to move the issue there.  This implies a
user interface change, since most clients are blissfully ignorant of
the domain portion; they just cough up a string configured by a user.
Since we're requiring that clients implement stable storage in order
to have this new feature, I think the additional burden of isolating
the domain value (if any) belongs there as well.

We'll need to recommend that clients should be implemented such that
they have two strings that are concatenated to form the real name.
The first string is the authenticatee's name, and the second is the
domain.  When sending back the pseudonym, the EAP Identity string is
formed as "pseudonym_" | <uppercase-hex-pseudonym-value> | <domain>.
When sending back the real name, the string is <name> | <domain>.

> this feature, and then drop back to cleartext identity.

You'd have to rely on the NAS failing to decrypt a useful value, being
unable to find a AAA server, and then falling back on a second EAP
Identify message.  Not pretty, but it would work.

> by using cleartext domain names would be a backward compatible way 

That seems like a fair argument to me.  We'll keep the domain in the
clear.

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