SRP with random, but constant private-value b

Question

In RFC5054, the SRP6a algorithm states that the client and the server should generate random ephemeral private values $a$ and $b$ respectively which are used for further derivation in the handshake and in the generation of the shared-key. For a persistent TLS connection, it obviously makes sense to generate a new random $b$ value each time a client connects.

Edited for clarity: However, I would like to use SRP in a stateless authentication handshake over multiple HTTP requests. The first request would be the client sending its $I$ to the server, and it would receive ($N$, $g$, $s$, $B$) in return. The client would the calculate $A$ and make another request to confirm its identity. Since the second request may hit a different server, this implies that the private $b$ would have to be shared across all servers. The simple solution is a constant value shared by all servers.

Aside from replayability, does choosing a random but constant $b$ value across all servers have any other security implications? Should I definitely not do this? Would silly tricks, like a varying time-windowed values derived from a constant $b$ be a better choice?

My instinct tells me this is roughly fine, in the same way that we use random-but-constant secrets to secure, e.g. session cookies, but I want to understand the implications.

To be clear, I'm only using this for authentication purposes so that the server never sees the user's password, and depending on TLS for forward secrecy of subsequent communications. I realize I could also, for example, bcrypt the user's password before sending it to the server to achieve similar goals, but thought it might be better to use a degraded version SRP instead.

Answer 1

If you use a $g^b$ value between sessions, you allow an attacker to test multiple passwords for the second session; this invalidates the security goal for SRP.

Here is how the attack looks like:

For the first session, the attacker logs in using a password he does know. The server sends the value $B = kv + g^b$; the attacker knows $k$ (that's derived from common data), he knows $v$ (that's derived from the password he knows), and so can recover $g^b$

For the second session, the attacker listens into a login that uses a password he does not know. Again, the server sends the value $B = k'v' + g^b$ (where $k', v'$ are different values for this session), as he now knows $g^b$ (and can derive $k'$, he can recover $v'$; he can then go through his dictionary, and test the various passwords against $v'$.

Answer 2

Why $b$ has to be a constant value? REST API? I think you can pack $g^b$ with rest message and client side first recovers $g^b$ and this should be fine