[Cryptography] SRP for mutual authentication - as an alternative / addition to certificates?

[Pawel Veselov]

On Sun, Aug 2, 2015 at 9:54 AM, Carlo Contavalli <ccontavalli at gmail.com>
 wrote:

> Hello,
>
> haven't seen many conversations or much noise about SRP, from
> http://srp.stanford.edu/ on this mailing list.
>
> By a quick reading, and by peeking at the implementation, it provides
> strong mutual authentication of both client and server through a
> "shared secret", which is stored as a one way hash on the server, and
> never exchanged on the wire.
>

Yes. Wikipedia article
https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
also has a reasonable explanation on how they work. There is also an RFC
5054
that plops SRP on top of TLS.


> Eg, if used with ssh, checking the fingerprint when connecting would
> be significantly less relevant, the fact that the server can establish
> an encrypted session at all proves that the server knows a hash of the
> shared secret.
>

But, with ssh, or protocols like ssh, session is established per TCP
connection. You wouldn't ask the user the password every time an HTTP(s)
connection is established.


> Has drawbacks - but certainly sounds like an improvement compared to
> existing protocols?
>
> Are there / why are not similar technologies used for web?
>

There certainly are for the web. Not so much for HTTP(s) though. You can't
reasonably (from the UE perspective) implement SRP/ZKP for HTTP because
it needs to span multiple HTTP requests. The full SRP web solutions do
require
javascript (or other) code to retrieve any protected data (there are
solutions
that only check the password, after which it's standard HTTP session)


> I see two separate needs x509 certificates and TLS typically try to
> address:
> 1) establishing the identity of a site you connect to.
> 2) maintaining privacy and preventing mangling of the data exchanged.
>
> If I think about my typical workflow, ... x509 and certificates would
> still play a role the first time I end up on a site.
>
> Eg, the first time I go to uber.com, or first time I register to use
> my health plan benefits online, I would check that the certificate
> matches who the site claims to be.
>
> But from then on... once registered, and once I have a password, SRP
> would allow me to establish that the remote end is who they claim to
> be based on their ability to prove that they know a hash of my
> password, the certificate would just be an additional protection?
>

If the X509 certificate checks out that just means nobody stole the private
key of the holder, or a CA you trust. If the SRP checks out, that means
that the
server has the verifier code derived from your password. So in case of
the password database breach, it would be very hard to derive your password,
but still as easy to impersonate the server. Though they won't get your
password
even if you give it to the impersonator.


> Seems like a significant improvement over what we have today? Reducing
> exposure, and need to trust certification authorities?
>

If you don't use PKI, then you'd have problems trusting whom to establish
the passwords with in the first place.


> For example: a rogue certificate authority creates a false uber /
> false health plan management site. Or a rogue certificate is installed
> on my laptop. I try to login after this fake has been created, ... I
> would not be able to login?


Your client must terminate the connection if the server's proof doesn't
check out, or if it can't decrypt the data from the server.


> or notice immediately? Or if they proxy my
> connection acting as a MITM, they would not be able to decrypt my
> data?
>

Yes, neither fake servers no MITM can get into your data unless they have
the verifier.


> Opinions?
>

SRP really helps in:
- preventing password from ever being transmitted
- preventing guessing the password even if the password is really simple

Besides it's ability to encrypt communications, it in no way deprecates any
of the
functionality of the PKI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150804/939a8b7c/attachment.html>