Subject: RE: comments on minutes

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Fri, 30 Mar 2001 10:56:23 -0500 (EST)

Minutes are fine with me too.

About OTP: as I said at the meeting, I don't see how it can be
applicable, and nobody at the meeting had an explanation of how it could be
used. So might we want to simplify things by eliminating that, unless
someone on the mailing list could explain how OTP fits in?

Radia

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Fri, 30 Mar 2001 14:27:25 -0500 (EST)

From: Stephen Farrell <[email-masked]>
	
	Hi Radia,
	
	...can you elaborate 
	on why "not storing a password-equivalent at the server...is not 
	an important property for a credentials download protocol"?
	
	If true, this is a fairly interesting difference!
	
	Stephen.

____________________________________________________________________

Everything about this stuff is interesting! :-)

****************************************
* terminology "basic" and "augmented"  *
****************************************

Let me use the word "basic" for schemes that store a password
equivalent. These include EKE, SPEKE, and PDM. Let me
call "augmented" those that don't store a "password equivalent"
(something that can be used to DIRECTLY impersonate the client),
but DO store something that, if stolen, can be used in a dictionary
attack to find the user's password. There are
"augmented" forms of EKE, SPEKE, and PDM. SRP is inherently
"augmented".

There's a newer wrinkle in a recent paper by Ford&Kaliski. That
scheme avoids storing anything useful in any single server, and
requires an exchange with multiple servers to piece together the
credential. This is interesting, but requires interaction with
multiple servers, which is a performance and availability problem,
and may have intellectual property issues, and I think the sacred
WG decided it really isn't important enough an advantage to worry
about at this time.

So we are left with "basic" protocols which store a password-equivalent,
and "augmented" protocols which store something which if stolen
can be used with a dictionary attack to find the user's password.

Important note! None of these protocols (basic or augmented)
allow an eavesdropper or
someone impersonating either side to obtain anything with which
to do a dictionary attack. I was talking to someone who was
concerned about having the server send you your credential without
authenticating you. But it doesn't "just send you" the credential. The
credential is encrypted with a strong secret established
in the client-server exchange that only can be
known by someone that knew your password. Someone impersonating
the client can only test
one password at a time in an on-line, auditable way. It is auditable
because the server has to participate in a protocol for each password
guess.

**********************************************************
*  Now let me explain how the augmented protocols work.  *
**********************************************************

Let me give one example of an augmented
protocol. It is an augmented form of PDM.
I think it might be the easiest to understand.
Remember in basic PDM, the server stores p. In this augmented
version of PDM, the server additionally stores 2**W mod p, where W is
a hash of the user's password. So the server knows 2**W mod p, and p.
The augmented protocol will be such that the
client will have to know both p and W in order to authenticate.
Someone who stole the server's database will not be able to obtain
W from 2**W without doing a dictionary attack, so will not be
able to impersonate the client.

The protocol is:

The client calculates p and W from the password and chooses a random A.
The client sends "Alice", 2**A mod p ----->
The server chooses a random B and sends:
  <------- 2**B mod p, and h((2**AB mod p),(2**WB mod p))
The client now knows the server must have known 2**W and p because it
verifies the hash.
The client sends a different hash of those two quantities, say
h(1,(2**AB mod p),(2**WB mod p)).

Both the client and server need to compute 2**AB and 2**WB. The
client computes 2**AB by raising 2**B (which it receives from the
server) to the power A. The client computes 2**WB by raising 2**B to
the power W (which it knows because it computed W from the password).

The server computes 2**AB by raising 2**A (which it received from the
client) to the power B (which it knows because it picked B). It computes
2**WB by raising 2**W (which it knows because it's stored at the server)
to the power B.

The client has to actually know W in order to do this protocol. Knowing
2**W will not help the client (without doing an offline dictionary
attack on 2**W to find W).

************************************************************************
* Why the augmented property is not important for credentials download *
************************************************************************

All of the schemes (basic and augmented) store a credential Y, such as
the user's private key encrypted with a password. They also store
something with which to parameterize a Diffie-Hellman exchange and
come up with a strong secret, which will be used to encrypt Y and
send it to the client.

In mutual authentication, if you stole the server database with a "basic"
scheme, you'd be able to impersonate the user. But for credentials
download, the PURPOSE of the exchange is to establish a strong secret
with the server so it can send you Y. If you've stolen the server
database, you already have Y! So there's no reason to
bother impersonating the client with a sacred-style protocol in order
to have it securely send you Y, when you already have Y!

Hope this is intelligible.

Radia