Subject: EAP-SRP and identity privacy

From: [email-masked]
Date: Wed, 20 Jun 2001 17:09:13 +0300

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

---

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

> not able to recover the pseudonym.

That's an interesting idea.  Of course, you'd need to be able to
handle the error-recovery cases (where authenticator or authenticatee
either "forgets" the current pseudonym entirely or, due to a
restoration from back-up, reverts to a prior pseudonym) to make it
robust, but it sounds like it should work.

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.

The Next Pseudonym value SHOULD contain an implementation-dependent
identifying mark (the string "Pseudo" is suggested) so that the
authenticator can requery for EAP Identity if the Pseudonym presented
by the authenticatee is unknown due to synchronization problems.  If
the authenticator sends an EAP Identity Request message with a changed
ID field, the authenticatee MUST revert to its regular identity in
subsequent Responses and the authenticator MUST NOT allow the use of a
Pseudonym for identification within that same authentication session.

Authenticatees that do not have stable storage for the Next Pseudonym
value or otherwise do not elect to implement this feature may ignore
this field entirely and use the same client identifier with all
sessions.

How does that look?

> using a key that is known to the authenticator only.

The authenticator *would* have to maintain state across calls in order
to use the pseudonym; you must at least to keep track of that random
salt.  Otherwise, you either always have the same pseudonym or you
can't recognize the client by his pseudonym when he comes back.

-- 
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: James Carlson <[email-masked]>
Date: Wed, 20 Jun 2001 11:18:56 -0400 (EDT)

> authenticator MUST always accept the authenticatee's regular name for

I managed to leave off an important aspect: the Next Pseudoynm needs
to be the result *after* encryption using the shared key, naturally.

---

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

I had the following question put to me recently:

a. In the IP statement filed with IETF on SRP, it is noted that
"bi-directional auth" (SRP-Z) requires a royalty. This version involves
having both sides store the verifier. 

b. In a peer-to-peer protocol like PPP (or 802.11 ad-hoc, for that
matter), either side might be the authenticator, and therefore might have
to store the verifier. 

Does this mean that use of SRP in adhoc scenarios is not "freely
licensable"?

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Jun 2001 15:46:48 -0400 (EDT)

> having both sides store the verifier. 

It's my understanding that SRP-Z is a different algorithm, though I
haven't been able to find enough information about it to be certain.

The implementation described in the EAP SRP-SHA1 draft is based
directly on RFC 2495, and that is known to be "free."

> matter), either side might be the authenticator, and therefore might have

SRP as described in this draft doesn't work that way.  It's more like
PAP.  If you had (for whatever reason) both sides behaving as
authenticators, then you'd have independent verifiers and secrets for
each direction.

In particular, I don't see how a client with only a copy of the
verifier (and no access to the secret) could use it to authenticate to
the server.

> Does this mean that use of SRP in adhoc scenarios is not "freely

The right person to ask is probably Thomas Wu, so I've copied him.

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Jun 2001 16:51:44 -0400 (EDT)

Tom Wu writes:
> That's a security property of the SRP protocol.  The important
> distinction to bear in mind, to determine if 802.11 ad-hoc or PPP uses
> SRP or SRP-Z, is whether or not both sides use their secrets and
> verifiers *at the same time* during authentication.
> 
> For example, given that all the nodes in some network had verifiers for
> all the other nodes in that network, if node A wants to authenticate to
> node B, and node A uses his password while node B uses his verifier for
> A to authenticate A, then that's "free" use of SRP.  OTOH, if node A
> uses his password to authenticate to B, while simultaneously using his
> verifier for B to ensure that B is explicitly authenticated back to A,
> that's SRP-Z.

Standard PPP is symmetric; in a given session, each side can choose to
authenticate or not as it sees fit, and the (possible) two
authentications are completely independent and asynchronous.

If merely using RFC 2495 in two directions "at the same time" is a
violation of this separate patent, then we've got a real problem here
with EAP SRP-SHA1.

At a minimum, I'll probably have to note somewhere that doing
bidirectional authentication requires a special license, and document
some sort of work-around.  Since standard PPP is, as I said,
symmetric, this isn't going to be very pretty.

This isn't a good result.

Thanks for the clarification, though.

---

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

> SRP-Z is indeed a different algorithm.  It's not that "both sides store
> the verifier", but more accurately, each side has a verifier for its
> peer, and both sides use them during authentication.  In regular SRP,
> explicit authentication is done only in one direction.

Don't both sides verify the hashes so as to provie mutual auth?

> verifiers *at the same time* during authentication.

So the distinction between SRP and SRP-Z isn't based on an on-the-wire
protocol difference, but rather the usage model? Typically you will do one
auth at a time, first one direction, then the other. So would that be SRP
if they're not *simultaneous*?

> Tom
Is there a document on SRP-Z available somewhere that we can read so as to
make the distinction more clear?