Re: [sasl] draft-ietf-sasl-scram-11: why don't include the authentication identity in the stored key?

[Alexey Melnikov <[e-mail]>]

Jehan Pagès wrote:

>Hello,
>  
>
Hi Jehan,

>I am reading the SCRAM draft for an implementation and had a remark.
>The SCRAM's design motivations states this:
>
>«
>The server does not gain the ability to impersonate the client to
>      other servers (with an exception for server-authorized proxies),
>      unless such other servers allow SCRAM authentication and use the
>      same salt and iteration count for the user.
>»
>
>But if the username was included in the StoredKey algorithm (for
>instance instead of salting the password only, you could salt
>[authentication identity + UTF8NUL + password]), noone having the
>stored key (whether the server itself or someone having gained access
>to it on the user's computer for instance) could use it to access any
>service other than the one it was stored for, EVEN IF this other
>service has the same salt and iteration count by some extraordinary
>chance, unless the same authentication identity is also used on both
>service (which might be improbable, though not impossible, as such
>identity often include a service domain).
>
>Isn't it better for security (though I agree that the chances of
>having same salt and iteration count are weak, here they would be even
>weaker)? Moreover in my opinion, associating the
>username/authentication identity and the password seems a nicer design
>(by including them both into the Stored key).
>  
>
I think you are right about security aspect of this. What you suggest 
was done for DIGEST-MD5. The problem with that is that any change to the 
authentication identity invalidates the hash containing it, so sysadmins 
can't rename the user without also resetting the corresponding password. 
Authentication identity changes is a sufficiently important problem for 
big enterprise and university deployments, so it was decided that it was 
more important to make sysadmin job easier than the security aspect.