Re: "The End of SSL and SSH?"

[Michael Wojcik <Michael.Wojcik () MERANT COM>]

> From: Ajax [mailto:ajax () FIREST0RM ORG]

> Allow me to refer everyone to the SRP protocol (http://srp.stanford.edu/),
> which accomplishes a cryptographically strong password exchange

Not really.  SRP uses a ZKP protocol which allows the two sides to agree
that each knows the same shared secret, without either of them revealing
that secret or its equivalent.  That prevents, for example, a hostile server
from grabbing what it needs to spoof the user against a genuine server.

> and uses
> it to establish a session key.  This works by assuming you already have a
> password stored on the remote host (you do, in /etc/shadow)

That's only true if you're talking to a remote host that uses /etc/shadow to
hold a shared secret used to authenticate your account.  While that
situation (or its equivalent) is present for many of the cases where SSH
(and the other protocols people have been discussing here) is used, it's not
ubiquitous.

Shared-secret authentication schemes are different from public-key
authentication schemes.  It's not simply a matter of substituting one for
the other.  There are significant protocol changes.

And SRP authentication is available for SSH; it's not a matter of SRP or
SSH.  You can use SSH/SRP rather than, say, TELNET/SRP or Kermit/SRP.
(Personally I'm not so enamoured of SSH, so I use TELNET/SRP and FTP/SRP,
but it's largely a matter of personal preference.)

> , and therefore
> pushes the initial key placement problem up to account creation time,
> which we assume is a secure event, right?

Perhaps (I don't know that I'm comfortable with a blanket assumption that
all of "account creation" is secure), but you still have the problem of key
placement: How does a user enter the secret securely when the account is
created?  There are a variety of solutions, but they all impose
administrative and/or user burdens of one sort or another that public-key
schemes are supposed to avoid.

Consider SSL with only SRP for authentication, for example.  Try using that
with web shopping.  How do you securely create your account with the
merchant?  How do you verify you're talking to the merchant?

> The only problem with SRP is that it doesn't allow you to verify the
> trustedness of the client (well, you can, but it requires you to, for
> example, add an IP address to the username string and store a unique hash
> for each IP she might be coming from).

SRP is not a full remote-access security protocol; it's an authentication
scheme.  It's not supposed to prove the trustedness of the client.  It's
supposed to verify that the client has access to the secret.

By the way, Phil MacKenzie at Bell Labs has recently developed a new
EKE-style protocol family, PAK (the latest variant is PAK-RY, I think),
which is similar to SRP but has some formal security proofs [1].  I don't
know of any reason to rush to replace SRP with PAK-RY, but the work is
interesting.


Michael Wojcik             michael.wojcik () merant com
MERANT
Department of English, Miami University

1. http://www.bell-labs.com/user/philmac/pak.html