Subject: RE: EAP-SRP and identity privacy

From: [email-masked]
Date: Fri, 29 Jun 2001 16:48:42 +0300

> From: ext James Carlson [mailto:[email-masked]]
> 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.  :-/

Yes, the size of the pseudonym may become a problem. RFC 2486 says
devices handling NAIs MUST support an NAI length of at least 72 octets.
That isn't much.

We should probably use the 72 octects as efficiently as possible. 
Can base64 encoding be used? 

If the pseudonym is opaque to everything else but the AAA server, 
then maybe we don't have to specify what it is. We should
give examples and recommendations. Is it enough if the AAA server is 
able to tell a pseudonym from an invalid NAI? If so, then the format 
of the pseudonym could be left up to implementations altogether.

If we can do that, then the client should obtain the text presentation 
of pseudonym (without domain part) from the Next Pseudonym field, 
without doing any textual encoding itself but just decryption.

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

I agree.

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

Yes, the client should be able to concatenate the user name portion
of the pseudonym and the domain to the EAP Identity string.
(But as I wrote above, I'm not sure if we need to specify
the actual format of the pseudonym user name portion.)

> > 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.
> 
> That seems like a fair argument to me.  We'll keep the domain in the
> clear.

OK.

This is starting to look pretty good to me!

Regards,
Henry

---

From: James Carlson <[email-masked]>
Date: Fri, 29 Jun 2001 10:12:16 -0400 (EDT)

> devices handling NAIs MUST support an NAI length of at least 72 octets.

No kidding.  I think, though, that if the pseudonym is too long, and
the AAA server doesn't handle long enough NAIs, then the failure
handling is rather simple; it doesn't recognize the mangled pseudonym,
and it does the Identity reprompt to drop back to cleartext.

This would conflict with the current definition of the "use pseudonym
if available," but not terribly.  The heuristic "try again just once;
two failures in a row means that the peer lied about its support for
pseudonyms" does the job well enough, if necessary.  I don't think
this is a very serious problem since this is an optional feature
anyway.  Documenting the failure mode is probably enough.

Plus, the pseudonym as specified isn't that big.  It's the encrypted
user name, so it's just rounded up to the next block boundary as
specified by the encryption algorithm.

> Can base64 encoding be used? 

Fortunately, there's no conflict between BASE64 and the NAI syntax, so
that's reasonable to do.

> of the pseudonym could be left up to implementations altogether.

I think problem is that the charset needs to be restricted enough that
existing NAS implementations can handle the user/realm split.  As long
as that's maintained, I agree that there's no reason for us to
strictly specify it.

(I wouldn't be surprised to find the use of strchr(nai,'@') to do the
split rather than strrchr(nai,'@') in some NASes.  If the AAA server
were ignorant of NAIs and chose badly in its encoding of the user
portion, this would likely break the NAS's server selection.)

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