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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Jeffrey Hutzelman <jhutz@xxxxxxx> writes:

> --On Tuesday, March 18, 2008 04:52:49 PM +0100 Simon Josefsson
> <simon@xxxxxxxxxxxxx> wrote:
>
>> 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.
>
> Except the point is to _not_ have a central authentication server
> which must be online and accessible for logins to succeed.  We're
> talking about a situation in which there may not be much
> "infrastructure" at all; just a bit of automation that pushes out new
> hashes to all the servers when a user is added or a password is
> changed.
>
>> 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.
>
> OMG no.  What you're suggesting is telling users to enter a different
> username based on which server the load balancer connects them to.
> Since, depending on the load balancer in use, the client may not even
> know this, it is unreasonable to expect it.  And really, it's creating
> a UI nightmare and more deployment pain in the name of making protocol
> design and implementation easier, and that's backwards.

Sure.  Ok.  Let me see if I understand this properly.

The usage scenario is that you are load-balancing a particular service
(e.g., IMAP or outgoing SMTP), and you don't have a central
authentication server?

The threat model is that you want to avoid that an successful attack on
one of the servers, where the attacker collects the password-equivalent,
enables the attacker to use that information to impersonate the user on
one of the other servers?

If that is the entire problem we want to solve, I think there are much
simpler solutions than introducing a realm concept.  Just make the
server-side password-equivalent unusable as a client-side
password-equivalent.  Is there any problem with that solution?

/Simon