Some SRP issues

[nisse%lysator.liu.se@localhost (Niels Möller)]

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