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 Tue, Mar 18, 2008 at 04:52:49PM +0100, Simon Josefsson wrote:
>> Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:
>> > 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.
>
> Hmmm, I think I can live with this answer, but I also think that a SCRAM
> with this option will have sufficiently different properties from
> Kerberos that in many case it could be preferable (specifically: no
> online infrastructure requirement for the client).

If I understand your scenario, it may be that it can be solved easily
with unmodified SCRAM, see my response to Jeff.

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

That is what I do in one (small) environment.  It is simple and works
fairly well.  It is not a load-balancing setup though, where I admit
this approach would not work well.

>> In my experience, the realms feature was not used widely with
>> DIGEST-MD5, but made the specification more complex.
>
> OK, I withdraw this proposal.

I'm not strongly opposed to realms, but if it leads to complexity in the
protocol, I think we should motivate it carefully.

The complexity in DIGEST-MD5 was not sufficiently motivated, neither in
the specification nor by real-world requirements, in my opinion.

/Simon