Pure SRP authentication without TLS

Question

IF using a SRP for client/server application authentication without TLS. Will it be vulnerable to man-in-middle attack, since if using SRP, the public info doesn't really useful to calculate the session key.

Answer 1

SRP is a password-based key exchange protocol, which implies mutual authentication (the client has a guarantee that it talked to the right server, the server has a guarantee that it talked to the right client). By definition, this rules out any man in the middle attack. This applies to the complete SRP protocol; if you look at the design page, you see that client and server first exchange a pair of messages (I,A from the client, s,B from the server), and then do some computations which yield the common session key K for both. But the authentication is not complete at that point; as the page says, client and server still "need to prove to each other that their keys match" so there are a couple extra messages to be exchanged.

At that point, client and server have "mutual authentication" in the following sense:

• They both know the shared session key K.
• The client (resp. server) knows that only the rightful server (resp. client) knows the key K.
• They both know that the rightful server or client was indeed involved in the process (the authentication is explicit).

(The extra "key match" messages are needed to make the authentication explicit, but also to make the protocol robust -- the cryptographic details are intricate.)

But this is not enough. Indeed, when you want authentication, you don't just want some knowledge in abstracto that the intended peer exists and is not dead yet; you want to authenticate a session, i.e. subsequently exchanged data. An attacker in the position of doing a MitM attack could just let the messages pass, and then hijack the transport medium and inject his own data packets. To authenticate the session, the shared key K must then be used to compute a Message Authentication Code over the data chunks which the client and server then send to each other. In many cases, encryption will also be needed. Applying a MAC and possibly encryption to streamed data, in a safe way, is known to be a difficult task; there are details.

If you implement SRP and then add a transport layer for data which computes the MAC and encryption and does everything that is needed to make the session safe (including key diversification to prevent an attacker from making the server talk to itself; sequencing, to prevent reordering of data chunks; verified termination, to prevent truncation; and so on...), then you end up with something which is, basically, TLS. TLS with SRP is about the minimal protocol that uses SRP to authentication a session. It would take a very special situation to warrant inventing your own protocol (an highly risky endeavour) instead of just using TLS.