Subject: Some SRP issues

From: [email-masked] (Niels M�ller)
Date: 19 Mar 2001 14:51:42 +0100

I and Tom Holroyd have been discussing SRP key exchange recently, and
there are a few questions where I would appreciate advice from Tom Wu
and from the working group.

My draft is at http://www.lysator.liu.se/~nisse/lsh/srp-spec.nroff.

The first issue is the addition of a host key to the messages.
Earlier, I didn't want to add that for purity reasons; as it's
possible to get a copy of the host key later, using the ssh
"connection" protocol, it seemed unnecessary to add it already at the
key exchange.

Counter arguments are: (i) The key is useful at key reexchange during
the same connection, so it belongs to the keyexchange and transport
layer, and (ii) it is an easy and convenient way to transfer the
authentic host key.

That would change the draft by adding an (optional) host key to the
SSH_MSG_KEXSRP_REPLY message, and to the exchange hash.

A second issue is negotiation of the group (or perhaps more properly,
ring) used for the exchange. Tom Holroyd likes to have the ability to
negotiate which group is used, analogously to the
draft-dh-group-exchange. I don't know the exact details, but I imagine
that the groups is stored together with the verifier and therefore
choosen by the server.

But if the user's secret value x is constructed as

  x = HASH(s | H(n | p))

like in my draft, this opens for attack. Assume that we are
communicating with a bogus server. The server tells us to use a group
of its choice, and it chooses a group in which the attacker can
compute discrete logarithms.

Now the user sends v = g^x to the server, and the server can extract x
(modulo the size of his choosen group). Knowing x, the attacker can
impersonate the user to the real server.

A possible remedy is to make x depend on the group, say,

  x = HASH(s | description of group | H(n | p))

Would that work? I think this illustrates that adding group
negotiation must be done very carefully. (In the dh-group-exchange
case, I think the security is saved by the server's signature. The
signature provides authentication that doesn't break of the dh group
is tampered with).

Regards,
/Niels

---

From: Tom Wu <[email-masked]>
Date: Mon, 19 Mar 2001 14:49:17 -0800

> that the groups is stored together with the verifier and therefore

Yes, the server selects the ring beforehand.  When a user sets/changes
his password, that ring is used to compute the verifier, which is stored
on the server.

> impersonate the user to the real server.

I assume you're referring to a situation where a user is attempting to
*set* his password remotely for the very first time on a server, since
that is the only time one would ever send "v" over the network.  The
user's initial password should be set locally.  Once that is
established, the user can log in securely from anywhere, and can change
his password securely.  I don't see how the situation you described
could ever arise in a real environment.

If you want to devise a mechanism to allow a user to do remote password
initialization (a very hard, unsolved problem), I'd recommend having the
user select the ring and send {N, g, s, v} to the server, encrypted and
MACed if possible.

> Would that work? I think this illustrates that adding group

I don't see how this would help, and it would break compatiblity with
the installed server base.  I agree that the question of how to select
rings/groups is a tricky one; this is something I've had to deal with
quite a  bit when designing SRP and the associated protocols.

-- 
Tom Wu
Principal Software Engineer
Arcot Systems
(408) 969-6124
"The Borg?  Sounds Swedish..."

---

From: [email-masked] (Niels M�ller)
Date: 20 Mar 2001 00:22:59 +0100

> > But if the user's secret value x is constructed as

...

> that is the only time one would ever send "v" over the network.

*blush* You're right, of course. It's half a year since I really
worked with SRP, and appearantly I'm forgetting important things about
it... No, I was not thinking about setting the password, only the key
exchange.

So what is a correct analysis of the case where the attacker tells the
client to use a group of the attackers choice, and the attacker can
compute logarithms?

The values that the attacker gets are

  e = g^a, from which a discrete log computation yields the users
           secret dh value a.

  f = v + g^b, which doesn't yield anything obvious.

So it seems fine. Is there anywhere I can read more about this
scenario?

/Niels

---

From: Tom Wu <[email-masked]>
Date: Mon, 19 Mar 2001 19:19:36 -0800

>   f = v + g^b, which doesn't yield anything obvious.

Worst case, if the attacker feeds the client a "booby-trapped" safe
prime that he can do fast DL in, then he can extract the client's secret
"a".  He then sends some random string in place of B, gets the client's
response hash, and then can run through a list of passwords, guessing
possible passwords and checking them against the client's response.  The
defense is to accept only known, safe parameters (like the Oakley/IPSec
moduli) or at least allow only parameters that pass verification *and*
are sufficiently long.

> /Niels

Tom

---

From: [email-masked] (Niels M�ller)
Date: 20 Mar 2001 10:18:07 +0100

> moduli) or at least allow only parameters that pass verification *and*

Thanks.

I don't feel terribly good about requiring the client to check that
some prime provided by the server is safe. So I'd prefer a hard coded
list (which can be expanded as time goes by).

/Niels