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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

I'm curious whether using a username that looks like user@realm would
solve Nico's concern, or whether there is something that really needs
protocol semantics?

I agree with Chris that realm handling causes significant user interface
and API complexity for a password-based mechanism.  Password-handling
systems like PAM doesn't understand what a realm is, and they are used
beneath a SASL library sometimes.  I always regarded realms as a
underspecified area of DIGEST-MD5, because the semantics and intended
use of it was never fully described.

Without more justification that the complexities of realms are needed in
this context, I think we are better of without it.

/Simon

Chris Newman <Chris.Newman@xxxxxxx> writes:

> 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).
>
> 		- Chris
>
> --On March 17, 2008 12:13:18 -0500 Nicolas Williams
> <Nicolas.Williams@xxxxxxx> wrote:
>
>>
>> Also, one thing I've been wanting is a notion of optional domain or
>> realm for SCRAM.
>>
>> The motivation is to allow per-{user, domain/realm} enrolment and the
>> domain to then distribute verifiers to various servers, where each
>> verifier is distinct from the others and cannot be reversed to recover
>> the domain/realm verifier/generator nor any of the other servers'
>> verifiers.
>>
>> If the client knows the domain/realm, then it works that into the key
>> derivation hierarchy and asserts the domain/realm in its first and
>> second messages to the server.
>>
>> Else the server asserts a domain/realm in its first message to the
>> client and the client decides whether that's OK (keep reading), derives
>> keys, and goes on.  The way the client decides whether a server-asserted
>> domain/realm is OK is as follows: if the domain/realm == server name
>> then it's OK, else it will need to use local policy to decide whether to
>> go on, prompt the user, or fail (with a reasonable default).