# Why is TLS SRP verifier based on user name?

I don't understand why TLS SRP (or SRP in general) includes the user name in verifier calculation, given that user name is basically public.

From spec RFC 5054 $x$, which is then used to calculate verifier, is calculated as follows:

x = SHA1(s | SHA1(I | ":" | P))

I thought about removing 'I' to facilitate changing of user names(verifier won't have to be recalculated). Then $x$ will be:

x = SHA1(s | SHA1(P))

However I'm not sure if it will have any negative impact on the protocol. Will that change decrease security?

-
The server can choose the salt, so it can start a multi-target attack by giving all users the same salt. –  CodesInChaos Jun 7 '13 at 11:30
Not sure what you mean? Salt should be randomly generated, if it is not then it is implementation fault. –  nefarel Jun 7 '13 at 14:55
Yes, salt should be randomly generated, but what if the server is malicious? It doesn't have to play by the rules. In this case the server can mount the multi-target attack spoken of. –  mikeazo Jun 7 '13 at 16:18
@CodesInChaos Where do you see that the server chooses the salt? I suppose whoever chooses the salt also does the calculation of the verifier, so this entity already knows (or could know) the input of that calculation.) –  Paŭlo Ebermann Jun 9 '13 at 16:36

One of the design goals of SRP is that it should be a zero-knowledge authentication protocol. This is to say, even the legitimate server should not be able to learn anything about the user's password (other than what it could learn using a generic brute force attack on the verifier).

SRP also assumes that the user may not be able to remember anything except their username and password. In particular, even though the user may choose the salt when they first compute their verifier, that salt is stored on the server and is sent back to the user by the server whenever the user wants to authenticate.

If the username was not included in the verifier calculation, a malicious or compromised server could try to learn whether user Alice had the same password as user Bob by sending Bob's salt to Alice when she tries to authenticate and seeing if the authentication (using Bob's verifier) still succeeds. Including the username in the verifier prevents this potential information leak.

Admittedly, this is a fairly minor leak, and probably not of much concern in practice. Still, it does violate the intended zero-knowledge property of SRP.

Ps. While looking at the SRP documentation to see if it says anything about this, I noticed something curious: the original 1998 paper defining SRP-3 doesn't seem to say anything about the username being included in the verifier calculation. Indeed, the protocol specification in section 3.2.2 simply says that:

"To establish a password $P$ with Steve, Carol picks a random salt $s$, and computes: $$x = H(s, P)$$ $$v = g^x$$

However, the SRP-6 paper starts off with:

"The original protocol, sometimes referred to as "SRP-3" for historical reasons and specified in [4], operates in a group defined by a large safe prime $p$ and a primitive root $g$. Reviewing briefly, the server computes its verifier value $v$ for a user identity $I$ as follows: $$x = H(s, I, P)$$ $$v = g^x$$

The reference "[4]" in the SRP-6 paper is not actually to the earlier paper, but to RFC 2945, which claims to describe the same protocol as the SRP-3 paper but does include the username in the calculation. So apparently this change was quietly made at some point between the publication of the SRP-3 paper in 1998 and its standardization as RFC 2945 in 2000.

-