In SRP, is the client protected from server impersonation?

Question

Assume use of SRP over an otherwise insecure unauthenticated channel where

• the user running the client side has chosen a password,
• the user only uses that password with a trusted SRP client software, and with the intention to login to the legitimate server (then communicate securely with that server using the SRP-negotiated session key),
• there was no attack at enrollment time,
• the server keeps the enrollment data confidential,
• the password is good enough that odds are negligible that it could be guessed in a thousand attempts, and neither the server nor user would tolerate that many unsuccessful login attempts.

Does that protect the user from logging to another server?

---

Motivation: see that question.

^{So far, I have determined that such protection is not in SRP's advertised features:}

^{It solves the problem of authenticating clients to servers securely, in cases where the user of the client software must memorize a small secret (like a password) and carries no other secret information, and where the server carries a verifier for each user, which allows it to authenticate the client but which, if compromised, would not allow the attacker to impersonate the client. In addition, SRP exchanges a cryptographically-strong secret as a byproduct of successful authentication, which enables the two parties to communicate securely.}

Answer 1

Yes (and it is an explicit goal of SRP; perhaps not as advertised as such)

The only attack that SRP allows is for the faux server to take a guess at the password, and then attempt to allow the client to login based on that guess (and if the client thinks he succeeds, the guess was correct).

Given that we assume that the password was strong enough to make that unlikely, you're safe.

Answer 2

The SRP protocol as defined in the RFC documents only authenticates the client to the server. However, you can add a role reversed SRP exchange before or after the SRP protocol exchange where the client role is taken by the server, and the server role is taken by the client with a server secret z and public verifier Z for x and v to authenticate the server to the client.