During development of a client side application of TLS-SRP, i noticed a bug that allows an attacker spoofing as the server to send custom, but non-arbitrary $N$ values, with the client accepting them. Having fixed it immediately, i'm still curious to understand what the implication might have been.
The client has a known-good $N$ value stored in memory, taken from the SRP RFC, comprised of bytes $N_0...N_n$, against which the N received from the server is compared. The issue is that exploiting the above bug, it is possible to trick the client to accept an arbitrary-length prefix of the good $N$ value (i.e. $N_{smaller}=N_0...N_k | k < n$). Alternatively, the client can be tricked to accept a larger $N_{larger} > N$ ($N_{larger}=N_0...N_j|j>n$), where the trailing bytes ($N_{n+1}...N_j$) are known to the attacker but cannot be specially crafted.
What attack vectors does this kind of vulnerability open up, and how should N be crafted to achieve it? For example, can an attacker successfully spoof as the server without knowing the password / verifier? Can an attacker calculate $x$ (password + identifier hash) for later authentication as the client? Can an attacker calculate the private key $a$ out of $A$ ($A = g^a $ $mod$ $N$)? TLS-SRP RFC: https://www.rfc-editor.org/rfc/rfc5054
