6

In SRP, an authentication exchange starts with the client and server generating nonces a and b, and sending their public variants (A = g^a % N and B = (v + g^b) % N) to the other party. However, reading RFC2945, it is quite adamant that

The host MUST send B after receiving A from the client, never before.

I'm struggling to understand why this is, and as far as I can tell, the RFC doesn't explain the requirement further.

Since a and A are effectively just random numbers, sending A before receiving the B number doesn't impose any onerous requirement on the client. If, as a malicious client, I wanted to get a thousand B numbers from the server, I'd just send a thousand A numbers and it wouldn't cost me anything of note. And even if I did, I can't see what I would gain from it.

Is there an explanation for this requirement?

Improve this question

1 Answer 1

Reset to default
10

The reason for this requirement is explained in section 3.2.4 of the original SRP paper.

If B is sent before A, then an attacker who has managed to obtain the password verifier v = g^x of another user (e.g., through an SQL injection), can successfully authenticate as this user without knowing their password-derived secret x. This works by sending a crafted A which cancels out the x term in the calculations of the shared secret S.

All calculations are modulo N:

  1. Contrary to the standard protocol, the server first sends B = v + g^b to the attacker who masquerades as a legitimate client.
  2. Knowing both v and B, the attacker can craft A as A = g^a * v^(-u), where u are the first 32 bits of SHA1(B). This A is what the attacker sends to the server.
  3. According to the protocol, the server calculates the shared secret as S = (A * v^u)^b, which in this case results in S = (g^a * v^(-u) * v^u)^b = g^(ab). Note that the verifier v = g^x and therefore the secret x have been completely cancelled out due to the choice of A.
  4. The attacker can calculate this shared secret with S = (B - v)^a = (v + g^b - v)^a = g^(ab).
  5. Now the attacker is able to prove they know the session key K = SHA_Interleave(S).

This attack only works because the attacker knows B (and with it u) before they have to send their A. If the server follows the standard and demands A before revealing B, there's no way for the attacker to craft their A based on knowledge of B.

On a side note: SRP has been revised several times, and RFC 2945 describes the old version 3. The current version 6a is described in RFC 5054 in the context of TLS (it's referred to as version 6 in the RFC, but this is an error).

Improve this answer
2
  • 1
    I don't know when it changed, but in SRP-6a, u is not just a function of B, but of B and A. Since you normally wouldn't be able to craft A such that it cancels out its own hash, does that mean that this requirement is obsolete? Commented Jan 19 at 16:44
  • 3
    @Dolda2000: Correct. In the TLS context, the server actually sends their B first as part of the ServerKeyExchange message. Only then does the client send their A with the ClientKeyExchange message. Commented Jan 19 at 16:56

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.