Subject: Inclusion of service name or URI in SCRAM

From: Chris Newman <[email-masked]>
Date: Mon, 23 Mar 2009 14:42:13 -0700

I had a hallway conversation with Love where he asked about including a URI 
or service name in the authentication hash as DIGEST does.

An example of the threat is that a user can authenticate to a "bad XMPP" 
server which proxies the salt and nonces to a "good LDAP" server.  As long 
as channel bindings are not used, the client will successfully authenticate 
mutually to the "bad XMPP" server and the bad server will have full access 
to the "good LDAP" server (indeed to all servers which use that same salt).

If the service name "xmpp" (or an xmpp uri) was included by the client in 
the hash, this authentication would fail without channel bindings.  So this 
provides "lightweight" protection against a subset of man-in-the-middle 
attacks, but does not protect against all such attacks the way channel 
bindings does.

I made a deliberate choice to omit service/uri from SCRAM, being aware of 
this attack vector.

I found the "URI" parameter in digest confusing and a deployment barrier. 
What does the hostname in the "URI" mean?  What sort of checks should be 
performed on it?  What if the URI doesn't include a hostname?  Can a user 
have multiple passwords on the same host and what are the client UI 
implications for that?

The service name is simpler, but I consider the functionality it provides 
both redundant with and inferior to channel bindings.

The counter-argument would be that including a string in the password hash 
(particularly a service name) is simpler to implement than channel 
bindings.  So if we want some man-in-the-middle defenses without channel 
bindings, we need that feature.

I do not support adding service name or URI to SCRAM.  CRAM doesn't have it 
and I think it's a confusing and complex feature in digest.  I'd prefer to 
have one mechanism to do MITM defenses (channel bindings), I'd prefer that 
mechanism be complete, and the market will decide if MITM defenses are 
important enough to deploy that mechanism.  I don't want to make SCRAM more 
complex to provide half-defenses in the event channel bindings don't deploy.

I do think this is an important decision, so other opinions are welcome.

		- Chris

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Mar 2009 17:19:37 -0500

> or service name in the authentication hash as DIGEST does.

You and I have also had this conversation, twice I believe.

> I do think this is an important decision, so other opinions are welcome.

I believe that making SCRAM deployment simple is, indeed, important.

I do believe that a mode of operation (under a different mechanism name,
mind you) where the salt includes the server name is, or, rather could
have been important.  And it should come with an infrastructure service
protocol for servers to use during the exchange (to avoid having to
store N StoredKeys for N servers in a user realm).

What is valuable about such a mode of operation is this: after a user
authenticates once to a server using SCRAM the server can then
impersonate the user to other servers using the same StoredKey, but if
the password is salted with the server name then the server can only
impersonate the user to itself.

Arguably environments that care about that problem ought to be using
Kerberos V and/or user certs (via PKINIT or in TLS).  Which is why I
don't think we need to require a servername-salted mode of SCRAM.

Perhaps someone has a use case where neither SCRAM as-is nor Kerberos V
would be appropriate but where a servername-salted-password variant of
SCRAM would be?

Nico
--

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 23 Mar 2009 16:57:03 -0700

> I do think this is an important decision, so other opinions are  

So I've seen situations where people do MITM on purpose with protocols  
that looks like scram.

If I was an server owner I would be concerned about 3rd parties using  
my server to authenticate my users w/o me knowing using my server.

"to login, just use your foo password, and since we are using your  
SCRAM we wont be able to get your password", but impersonate the user  
to any service we want here the user uses the same password.

I don't think its realistic that a service deployer can not deploy  
scram w/o cb  since some clients are simply not going to work then.

Love

---

From: Tony Finch <[email-masked]>
Date: Tue, 24 Mar 2009 17:02:49 +0000

On Mon, 23 Mar 2009, Chris Newman wrote:
>
> I found the "URI" parameter in digest confusing and a deployment barrier. What
> does the hostname in the "URI" mean?  What sort of checks should be performed
> on it?  What if the URI doesn't include a hostname?  Can a user have multiple
> passwords on the same host and what are the client UI implications for that?

There isn't an smtp URI scheme, and mailto: doesn't have a field for the
message submission server hostname.

Will the lack of a URI parameter provide any advantages when multiple
parallel services share the same authentication database (e.g. smtp, imap,
ldap, xmpp, ...)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 24 Mar 2009 12:04:01 -0700

> parallel services share the same authentication database (e.g. smtp,  

"URI" parameter wont affect sharing the authentication database.

It will stop passing of authentication exchanges between unrelated  
"domains", aka MITM attacks.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 24 Mar 2009 14:29:12 -0500

> "domains", aka MITM attacks.

Not if you have neither: a) security layers, b) a secure channel to bind
to and channel binding.

We've got consensus for ditching security layers.  So that leaves (b),
which you claim won't happen.

If we want to solve this particular problem then apps MUST use one of
security layers or channel binding.

Which means we must pick one of those solutions and specify them.  If we
specify both then we're likely to run into an interop problem: clients
that only support (a) or (b) not talking to servers that only support
(b) or (a).

That said, adding a "URI" parameter will prevent misdirection attacks
(active attacks where the attacker is nonetheless not an MITM), but only
if the server you're redirected to is not in league with the attacker.

Given some of the SASL application implementor comments that we've seen
on the list it's unlikely that we'll get consensus for security layers.

Nico
--