Subject: RE: EAP-SRP and identity privacy

From: [email-masked]
Date: Tue, 26 Jun 2001 16:04:20 +0300

> From: ext James Carlson [mailto:[email-masked]]
> 
> Ah, I think I see what you're suggesting now.  So, you're proposing
> two levels of encryption on the server side -- one with this private
> key, then again with the ephemeral key "K".  The client decrypts with
> "K" to reveal the encrypted identity, and uses that as its identity
> in the next session.
>
> That appears to fix an important problem.  It allows the protocol to
> run without having to requery for identity -- the identity is always
> in the pseudonym, and it's always valid.

Yes, pseudonyms could always be easely recovered by the 
authenticator. You're right, this would require the pseudonym to be
transmitted using some form of reversible encryption. The pseudonym
cannot be simply a keyed hash of a nonce.

I think some robustness considerations need to be taken into 
account regardless of the approach we choose. A requery for 
the identity is an alternative. Or, the authenticator could 
simply send an EAP-Failure in response to the EAP-Response/Identity
if it doesn't recognize the pseudonym, and the client would have
to retry with the actual user identity.

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

Hmm... Why the disconnect? Observers already know that this user is
around and using the network. Is it just to make the duration of 
the session and the traffic patterns unlinkable to observers? I guess
that might make sense.

> Here's what I'll propose: add an optional Next Pseudonym field to the
> Server Validator (Subtype 3) message.  If this is present, then the
> authenticatee MAY save this value and MAY use it in response to the
> EAP Identity Request message in a subsequent session.  Regardless of
> the use of a Next Pseudonym value in any prior session, the
> authenticator MUST always accept the authenticatee's regular name for
> validation.

This looks good and we just need to specify how the actual next 
pseudonym is obtained from the contents of the Next Pseudonym field.
In any case, it would be good to include some robustness considerations,
for example:
"If the authenticator does not recognize a pseudonym received in
an EAP Identity Response, the authenticator MUST send an EAP Failure 
to the authenticatee. The authenticatee's regular name SHOULD then be 
used in the EAP Identity Response message of the next authentication 
attempt."

Regards,
Henry

---

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

> cannot be simply a keyed hash of a nonce.

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

The other issue is transmission of the pseudonym to the authenticatee.
Using a nonce has the distinct advantage that no encryption at all is
required for this feature, but the implementation disadvantages are
probably more significant.  So, I'll require the use of a SHA-1-based
hiding mechanism (similar to the AVP hiding done in RADIUS and L2TP)
for the pseudonym transfer from authenticator to authenticatee.

> to retry with the actual user identity.

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.

> the session and the traffic patterns unlinkable to observers? I guess

Yes.  If the monitoring is done "near" the server side and there's
sufficient call traffic, then this introduces uncertainty into the
deduction of identity.  If the monitoring is not "near" the server or
there's little call traffic, then no measure is going to help.
Picking one user out of a crowd of one isn't very hard.  :-/

So, it might help, and doesn't hurt.

> used in the EAP Identity Response message of the next authentication 

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.

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