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

From: Jehan Pagès <[email-masked]>
Date: Tue, 22 Jun 2010 17:05:36 +0900

Hello,

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).
Am I missing something?
Thanks.

Jehan

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Jun 2010 10:06:49 +0100

>Hello,
Hi Jehan,

>(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.

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 22 Jun 2010 20:19:28 +0900

Hi,

2010/6/22 Alexey Melnikov <[email-masked]>:
> 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 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.
>

I understand the argument. So it seems this "issue" has indeed been
already thought of. Is it so common to massively change authentication
identities in a running system?

Because considering that many users use the same password everywhere,
here this stored key really makes me think of an universal key which,
once acquired, enter any system whatever the login name or the service
is (no authentication identity, no realm in the stored key), like some
ssh key without a password (so once obtained, such ssh key enables a
malicious user to enter any remote computer the actual user has the
right to enter).
Of course the salt/iteration count makes this issue less problematic,
but it is still a weakness in my opinion.

And as an afterthought, if the authentication id is changed, couldn't
we imagine there could be some challenge where the user could still
authenticate using the old stored key (so holding the old
authentication id) until he resets with a new password (which can be
the same or a different, anyway the system won't make the difference
as this new password will be associated with a new auth id) once
authenticated. This way the reset is handled by the user without much
hassle (less than a server-side reset which would imply something like
an email sent with the new authentication id and some randomly
temporary generated password, then the user has to use it to
reconfigure his client): it is transparent for the user which does not
change his configuration, and this one would be automatically changed
by the system which just pop-ups a query to set a new password
(without needing to type again the old one as the authentication is
still handled by the old stored key at first).
In fact it might even be easier for the user than the current system,
as one does not have to manually find where to change one's
authentication id (the system does it for him).
I hope I am clear, otherwise I could write down some client-server
exchange example.
Thanks.

Jehan

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Jun 2010 13:25:27 +0200

> identities in a running system?

Yes.  I've designed a proprietary implementation which also hashed the
username in the server-side hashed key, and deployment has been a pain
because administrators do want the ability to move "password-hashes"
between usernames.  I agree with you that allowing this weakens the
security somewhat, but practical matters appears to be more important.
I don't view it as a significant security problem.

> but it is still a weakness in my opinion.

If salt is not chosen randomly by each system, there is definitely a
risk.  However, this is not how we want things to be deployed, and I
don't think it is how it is being deployed either?  Time will tell.

/Simon