Re: Optional domain/realm for SCRAM? (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

> On Mon, Mar 17, 2008 at 05:56:44PM -0700, Chris Newman wrote:
>> I am opposed to this suggestion, leaning in the direction of strongly 
>> opposed.
>> 
>> This is one of the sources of interoperability problems for DIGEST-MD5 
>> (client implementers didn't understand what the domain/realm meant).
>> 
>> It makes the client UI more complex and thus creates a significant 
>> complexity barrier (far more significant than any of the crypto algorithm 
>> issues).
>> 
>> If the domain matters, users can just use an email-style login identifier 
>> (e.g., chris.newman@xxxxxxx as my login identifier).
>
> This is not about a domain in the username!
>
> This is about enrolling in a realm so that many servers in that realm
> can authenticate the same users but without being able to impersonate
> those users to any other servers in that realm.
>
> Without this feature the only way to do the above is by having the
> servers authenticate to a realm server, pass through SCRAM messages and
> then get the results from the realm server.
>
> Not being able to enroll once but authenticate to many servers seems
> obnoxious.

I think this is out of scope for a simple password based password
mechanism.

If you have an infrastructure like the one you describe, either Kerberos
(if you prefer symmetric encryption) or TLS+EXTERNAL (if you prefer
asymmetric encryption) seems like a better approach to me.

If you really want to achieve something like you want, wouldn't the
following work?  Enroll the user once, and then ask the user to use a
username like 'user@xxxxxxxxxxxxx', 'user@xxxxxxxxxxxxx' for each of the
servers in that realm.  The enrollment process could push out the
password-equivalent hash to each server.

In my experience, the realms feature was not used widely with
DIGEST-MD5, but made the specification more complex.

/Simon