[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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