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.
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 (
At that point, client and server have "mutual authentication" in the following sense:
(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
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.