The SRP protocol as described in RFC 2945 generates the password verifier:
x = SHA(<salt> | SHA(<username> | ":" | <raw password>))`
v = g^x % N
I have three questions: why use SHA twice, why involve the username and why add a separator? Do these add any practical security over x = SHA(<salt> | <raw password>)?
SHA-1 is not an ideal hash function (actually, neither are the SHA-2 functions). The double hash invocation hides a few of the internal shortcomings of SHA-1. This is similar to HMAC, which also uses a double hash invocation for pretty much the same reasons. In more details, we want the function which maps the username-and-password to x (function selected by the salt among a family of functions) to behave like a random oracle, and the normal security properties of hash functions (collision resistance, preimage resistance) are not enough to guarantee such behavior.
The username is involved so as to make security proofs easier: it allows the security analysis to concentrate on a single user, without having to account for what happens when a given server accepts several users, each with his own password. The separator participates to the same goal: otherwise, "john" with the password "ny67dtzo" and "johnny" with the password "67dtzo" would live in the same world, security wise.
The separator is a good cryptographic design practice, whenever feeding multiple strings into a hash function. It helps prevent confusion between, e.g., username bob, password bydesign and username bobby, password design.
The general design principle is "Be careful when concatenating multiple strings, before hashing". You can find a more detailed explanation at that link. Violations of this design principle have led to flaws in the past, so it is good practice to always follow the design principle, even when you can't think of an obvious attack.
