Subject: Re: New GS2 design -- much simplified, and simplified SCRAM

From: Dave Cridland <[email-masked]>
Date: Sun, 01 Mar 2009 10:48:04 +0000

On Sat Feb 28 19:27:54 2009, Nicolas Williams wrote:
> http://www.iana.org/assignments/channel-binding-types/tls-unique

Assuming it's this one, I'm done. (In well under ten minutes, I just  
had to delete one line).

So, I've an implementation of SCRAM-HMAC-H for H in any of MD2 MD5  
SHA-* that Python's hashlib supports. I don't even know what hashes  
are supported. Four hours, probably one of which was spent reading  
multiple I-Ds to try and figure out what TLS channel binding data was  
needed.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave Cridland <[email-masked]>
Date: Sun, 01 Mar 2009 10:48:00 +0000

On Sat Feb 28 19:27:54 2009, Nicolas Williams wrote:
> I have an LDAP application that uses SASL/GSS-API with security  
> layers
> all the time.
> 
> 
Sure, I think the OpenLDAP libraries will do security layers, too, by  
using Cyrus SASL and actually including the additional magic to turn  
them on. I think this'd even be fairly commonplace with apps designed  
to use, say, Kerberos V.

But I still see you, me, and anyone else using seclayers as an  
insignificant minority in this matter. It's not even as if I like  
being insignificant, either.

> But sure, I second Jeff's call for a consensus on security layers.   
> If
> we agree we don't want them, then several bits of the GS2 headers go
> away.
> 
> 
I want them, I just don't think that, in practise, they'll be used.

I susect that much of this is because the notions of "secure" and  
"encrypted" are inextricably linked to TLS in the minds of the  
consumer, and the protocols that use SASL are often consumer-driven  
protocols, like email, instant messaging, etc. (LDAP's an exception  
here, so it wouldn't surprise me if LDAP sees plenty of use of  
security layers.)

If I ruled the world, then - after mandating more important things  
like food for all, world peace, and British spelling - I'd recast TLS  
itself as a security layer extension within SASL, and/or extend SCRAM  
with optional security layers.

But I suspect the whole seclayer thing's going to increase perceived  
complexity, and that's something I'm really averse to right now,  
while my status as ruler of the universe is still in some doubt.  
Application security is achievable to a reasonable level with  
SCRAM-HMAC-* and channel bindings, and that's good enough for now.

I still maintain that going after GS2-* compatibility is not the  
sensible goal here, incidentally. Aside from anything else, I suspect  
those environments which *do* wish to deploy GS2-* will also be  
wanting security layers - you're practically setting yourself up as a  
case in point, here. I think security layers are good, for many  
values of good, and I think that a GSS-API mechanism based on the  
same design as SCRAM would probably have security layers, and indeed  
they'd be used.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 01 Mar 2009 11:05:39 +0000

Nicolas Williams wrote:

>On Sat, Feb 28, 2009 at 09:25:52PM +0000, Alexey Melnikov wrote:
>  
>
>>Nicolas Williams wrote:
>>    
>>
>>>SASL must handle max buffer negotiation and security layers negotiation,
>>>right?  That's why I have that in GS2.  It means not having to have it
>>>in SCRAM (is it a bug in Chris' I-D that SCRAM doesn't have these?).
>>>      
>>>
>>No, it is not a bug. A SASL mechanism may choose not to provide any 
>>security layer. But if it does, it must allow negotiation of the max 
>>buffer size.
>>    
>>
>Most who have commented since seem to be saying we don't want SCRAM to
>have sec layers -- that we must always do channel binding.
>  
>
Speaking as an individual:

Not having a SCRAM security layer is fine with me.

Having 2 variants of the SASL mechanism (one which requires channel 
binding and one which doesn't) is fine with me too. Not having the last 
choice is not.

>Jeff's right: we need a consensus call on whether or not to bother with
>sec layers.
>  
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 01 Mar 2009 08:12:12 -0500

--On Sunday, March 01, 2009 10:48:04 AM +0000 Dave Cridland 
<[email-masked]> wrote:

> So, I've an implementation of SCRAM-HMAC-H for H in any of MD2 MD5 SHA-*
> that Python's hashlib supports. I don't even know what hashes are
> supported.

I believe this is _exactly_ what we were trying to avoid by specifying 
SCRAM-HMAC-SHA-1 rather than SCRAM-HMAC-<any_hash>.  if your implementation 
advertises SCRAM-HMAC-SHA-2, and it ends up getting used, than that will 
create interoperability problems if the IETF eventually defines 
SCRAM-HMAC-SHA-2 and it ends up being something other than SCRAM-HMAC-SHA-1 
with the hash swapped out.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 01 Mar 2009 08:14:38 -0500

--On Saturday, February 28, 2009 02:21:08 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

> I like where this is going.  Everyone seems to be saying "to hell with
> sec layers" -- that simplifies GS2 enormously since it removes max
> buffer and sec layer negotiation and leaves just that one RFC2743 header
> compression constant.  The channel binding negotiation bits stay and
> are needed whether or not GS2 is kept, so GS2 is really now just a
> single boolean constant added to SCRAM.

Except that you keep trying to remove the bit in the client's first message 
that says whether channel binding data is included, and you cannot do that. 
You can get by without it for SCRAM, but not for arbitrary GSS-API 
mechanisms, and so GS2 must include it.  Simple is good; too simple is 
fatal.

-- Jeff

---

From: [email-masked]
Date: Sun, 01 Mar 2009 08:07:16 -0800 (PST)

> Jeff's right: we need a consensus call on whether or not to bother with

I'm always a little leery of anecdotal evidence, but FWIW we have found no
reason to support SASL security layers. In fact not too long ago I actually
ripped out most of the latent support for security layers in our SMTP client
and server.  I was tired of navigating around all that complex buffer handling.
I was also concerned that due to minimal testing it had become a nest of latent
bugs waiting to bite us.

				Ned

---

From: Dave Cridland <[email-masked]>
Date: Sun, 01 Mar 2009 17:13:13 +0000

> I was also concerned that due to minimal testing it had become a  

FWIW, we [Isode] do support SASL based security layers - I'm not  
arguing that they should go away entirely, I think they're extremely  
useful in some environments, and particularly in the GSS-API cases.

However, I think the complexity outweighs the utility in a SASL SCRAM  
mechanism.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Sun, 01 Mar 2009 17:13:03 +0000

On Sun Mar  1 13:12:12 2009, Jeffrey Hutzelman wrote:
>> SHA-*
> I believe this is _exactly_ what we were trying to avoid by  
> specifying SCRAM-HMAC-SHA-1 rather than SCRAM-HMAC-<any_hash>.  if  
> your implementation advertises SCRAM-HMAC-SHA-2, and it ends up  
> getting used, than that will create interoperability problems if  
> the IETF eventually defines SCRAM-HMAC-SHA-2 and it ends up being  
> something other than SCRAM-HMAC-SHA-1 with the hash swapped out.

If SCRAM-HMAC-SHA-2 is not SCRAM-HMAC-SHA-1 with a IANA-registered  
SHA-2 instead of SHA-1, then I think we'll have interop problems  
anyway. You'd want it to be SCRAM2-HMAC-... or something, to avoid  
that barrel of laughs.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 02 Mar 2009 11:01:57 +0000

> with optional security layers.

BTW, the TLS-as-a-SASL-security-layer issue is so last century. The boat 
has sailed and sunk already.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 15:39:09 +0100

Nicolas Williams <[email-masked]> writes:

> Here's what we'll do about GS2 mech names:
>
> 1) Create a registry of GSS-API mechanism OID -> pretty SASL mech name
>    mappings.
>
> 2) Add an abstract API to the GSS-API: GSS_SASL_name() that outputs the
>    SASL name of a GSS-API mechanism.
>
> 3) GS2 will use the pretty name on wire for all GSS-API mechanisms
>    except for mechanisms that have no registered SASL name.
>
>    For mechanisms that have no registered SASL name GS2 will use a
>    hash-based name.  This means it's important for GSS-API mechanisms to
>    be born with a SASL name.
>
>    (Also, what we call "composed mechanisms" may not have pretty SASL
>    names ever, but that's really not an issue as no such mechanisms
>    exist now and anyways they are mechanically composed, thus they
>    arguably don't need pretty names or, in any case, might end up having
>    very long composed pretty names.)
>
> I think that should settle the last major issue.

I am slowly reading through this thread, but I just want to say that I
think the above sounds like a good compromise.  Getting good SASL
mechanism names for GSS-API mechanisms is important.

I started writing a document to specify the GSS_SASL_name function, but
the document became rather GS2 specific.  It doesn't seem like anything
other than GS2 will use it?  If so, isn't it sufficient to add a section
to GS2 which says something like the text below?  This also attempts to
address the interop problem when GSS-API mechanisms are deployed within
SASL and the SASL name is registered with IANA only later on.

Alternatively, we make the GSS-API interface less tied to SASL, and call
it, e.g., GSS_Mech_Human_Name.  It can still use the same syntax as SASL
mech names, so it would still work for GS2.  This function would be
useful by GSS-API programs for other purposes, e.g., to allow
administrators to configure GSS-API mechanism using friendly names
rather than by OIDs.

Thoughts?

X. Mechanism Name

   The SASL mechanism name for a GSS-API mechanism is learned from an
   IANA registry (a "friendly name"), or it can be derived from the OID
   algorithmically (an "OID-derived name").  To avoid interoperability
   problems when GSS-API mechanisms are deployed in SASL using a
   OID-derived name (when a friendly name has not been registered yet) a
   server SHOULD advertise both the friendly name and the OID-derived
   name.  The wire protocols MUST be identical regardless of which of
   the two names a client uses.

Y. IANA Considerations

   The IANA will create a registry that maps GSS-API OIDs to SASL
   mechanism names.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 10:55:03 -0600

> mechanism names for GSS-API mechanisms is important.

Good.

> to GS2 which says something like the text below?  [...]

Correct.  Yes.

> administrators to configure GSS-API mechanism using friendly names

It definitely needs to be tied to SASL, though it doesn't have to have
SASL in the function name.

Solaris has pretty names for GSS-API mechs, but a very non-standard
interface for using them (rpc_gss_mech_to_oid() -- not even
gss_-prefixed and not in libgss).

Thus I think that the two (SASL and human-friendly names) must be
separate, though they MAY be identical, at least in some locales.  Might
as well add a mechanism description too.

x.  GSS_Mechanism_name()

   Inputs:

   o desired_mech OBJECT IDENTIFIER

   Outputs:

   o mech_name UTF-8 STRING -- name of this mechanism, possibly
     localized

   o sasl_mech_name OCTET STRING -- SASL name for this mechanism
     (really, ASCII)

   o mech_description UTF-8 STRING -- possibly localized description of
     this mechanism.

x.1  C-bindings

   OM_uint32 gss_mechanism_name(
     OM_uint32    *minor_status,
     gss_buffer_t mech_name,
     gss_buffer_t sasl_mech_name,
     gss_buffer_t mech_description,
   );

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 13:57:36 -0500

>    the two names a client uses.

Don't do this.  The idea is that the SASL-like mechanism name is a property 
of the mechanism which must be specified when the mechanism is defined, 
just like the OID.  They cannot be added later(*); if a mechanism is 
defined without a name, then its name is derived from its OID.

Mechanism names like this should be limited to 16 characters and upper 
case.  This allows them to fit within SASL's name constraints while still 
allowing for a prefix like "GS2-".

(*) Except that when we first create the mechanism-name property, we can 
define its value for GSS-API mechanisms that already exist.  Names assigned 
in this way are treated the same as if they'd been assigned when the 
mechanism was defined; in particular, such mechanisms are _never_ named by 
OID.

---

From: Chris Newman <[email-masked]>
Date: Thu, 05 Mar 2009 15:13:36 -0800

--On March 1, 2009 10:48:00 +0000 Dave Cridland <[email-masked]> wrote:
> If I ruled the world, then - after mandating more important things like
> food for all, world peace, and British spelling - I'd recast TLS itself
> as a security layer extension within SASL, and/or extend SCRAM with
> optional security layers.

I actually disagree with you on this one point based on my experience as a 
production server engineer.

Certain software components accumulate certain types of complexity the 
longer they are deployed in production.  To keep software maintainable, 
it's important to avoid designs that force different classes of complexity 
to mix together into a monolithic system.

There is a class of complexity related to user identity services on 
servers.  This includes identity lookup, caching, password policy, 
single-sign-on-capabilities, server affinity, extensible attributes, 
identity plug-ins, proxy support, generation of SAML-like assertions, etc.

There is a class of complexity related to security layers and PKIX (TLS). 
This requires a stack-able I/O subsystem, tie-ins to crypto hardware (for 
both security layers and PKIX -- and it's unfortunate these are linked), 
PKIX parsing, cert chain verification, sync/async I/O issues, etc.  The 
production SSL library I'm most familiar with (NSS, used by Firefox and 
several Sun/Netscape/RedHat servers) has 6 full time engineers working on 
it last time I checked and they're swamped with work.

Both of these subsystems become huge and complex in production server 
software, and the complexity profiles are almost completely disjoint.  I 
want the tie-ins between these complexity profiles to be as minimal as 
possible.  Specifically there are only three places where data must be 
shared between the identity subsystem and the TLS subsystem:

1. Whether or not TLS security layer is active
2. TLS Client certificate (for Subject/SubjectAltName mapping and lookup to 
identity system) and PKIX verification status thereof.
3. Channel bindings

This is a rather clean abstraction.  I don't want my complex TLS stack 
contaminated by identity services, and I don't want my complex identity 
stack contaminated by security layer or PKIX services.  Keeping them 
separate is better software architecture, IMHO, at least on the server side.

		- Chris

---

From: Chris Newman <[email-masked]>
Date: Thu, 05 Mar 2009 16:15:06 -0800

--On February 28, 2009 13:38:36 -0600 Nicolas Williams 
<[email-masked]> wrote:
>  - We still have two mechanism names: the server advertises only one of
>    them, indicating whether the server supports channel binding.

Just so I'm clear, we would have:
  SCRAM-SHA1-NOCB  (no channel bindings)
  SCRAM-SHA1-CB    (mandatory channel bindings)
And the server only advertises one of these two mechanisms.  I do not like 
this approach.

I propose instead we do:
  SCRAM-SHA1-OPTCB (channel bindings optional, includes flag indicating cb 
support)
  SCRAM-SHA1-CB    (mandatory channel bindings, flag for cb support must be 
set)
The server would advertise either the first or both mechanisms.

The problem is that many implementers look at a single peer implementation 
and read the spec only as necessary to interoperate with that one peer. 
If, for example, a client of this type implements against a -NOCB server, 
then that client will fail to interoperate with a different -CB server. 
This in turn creates a deployment barrier for support of channel bindings 
since the -CB server can interoperate with that client if it advertises 
-NOCB but has to turn off -CB support to interoperate with clients that 
enforce the one-or-the-other-not-both rule at the same time.

With the latter approach, we don't create a deployment barrier for the -CB 
mechanism, and the flag allows detection of the downgrade attack.

The names I used above are for clarity of this example.  I'd actually 
prefer calling them "SCRAM-SHA1" and "SCRAM-SHA1-PLUS" (for -OPTCB and -CB 
respectively).  Mechanism names have a tendency to get into config files, 
error messages, logs and even set-up instructions.  The term "channel 
bindings" has little meaning for users/admins/etc and really shouldn't 
matter to them.  All they need to know is that the mechanism with mandatory 
channel bindings is "better".  Thus I suggest we use "-PLUS" to indicate 
"mandatory channel bindings".

		- Chris

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Mar 2009 20:37:38 -0600

> "mandatory channel bindings".

We might as well go for SCRAM-SHA1-LESSER and SCRAM-SHA1-BETTER :)

I agree with these suggestions.  And I'm very glad you've made them, as
I was concerned that the two mech name thing might not be acceptable to
you.

I think we're very close then to a GS2 on which we can get consensus.
It adds a header consisting of a constant and a one-byte flag (really,
two bits) to the first client authentication message and to the channel
binding data, and it also adds the two mechanism name suffixes.

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 5 Mar 2009 19:23:37 -0800

> I was concerned that the two mech name thing might not be acceptable  

I favor use of mechanism names to select features over negotiations  
within the mechanism.  -- Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 05 Mar 2009 23:30:04 -0500

--On Thursday, March 05, 2009 04:15:06 PM -0800 Chris Newman 
<[email-masked]> wrote:

> And the server only advertises one of these two mechanisms.  I do not
> like this approach.
>
> I propose instead we do:
>   SCRAM-SHA1-OPTCB (channel bindings optional, includes flag indicating
> cb support)
>   SCRAM-SHA1-CB    (mandatory channel bindings, flag for cb support must
> be set)
> The problem is that many implementers look at a single peer
> implementation and read the spec only as necessary to interoperate with
> that one peer. If, for example, a client of this type implements against
> a -NOCB server, then that client will fail to interoperate with a
> different -CB server. This in turn creates a deployment barrier for
> support of channel bindings since the -CB server can interoperate with
> that client if it advertises -NOCB but has to turn off -CB support to
> interoperate with clients that enforce the one-or-the-other-not-both rule
> at the same time.
>
> With the latter approach, we don't create a deployment barrier for the
> -CB mechanism, and the flag allows detection of the downgrade attack.
>
> prefer calling them "SCRAM-SHA1" and "SCRAM-SHA1-PLUS" (for -OPTCB and
> -CB respectively).  Mechanism names have a tendency to get into config
> files, error messages, logs and even set-up instructions.  The term
> "channel bindings" has little meaning for users/admins/etc and really
> shouldn't matter to them.  All they need to know is that the mechanism
> with mandatory channel bindings is "better".  Thus I suggest we use
> "-PLUS" to indicate "mandatory channel bindings".

I don't really care what you call them, but it's important to understand 
why there are two mechanism names.  Neither name means "mandatory channel 
bindings".  One name means the server has channel binding data, and the 
client can decide whether to use channel bindings.  The other name means 
the server does not have channel binding data, and the client must not use 
channel bindings.

Put another way, the mechanism name does not indicate whether the server 
wants to do channel bindings or whether it wants to require use of channel 
bindings; it indicates whether the server _can_ do channel bindings.  The 
goal is to negotiate the use of channel bindings whenever both sides are 
willing and able to use them, maintain interoperability when one or both 
sides are not willing or able to use CB, and prevent an attacker from 
forcing a downgrade.  This is accomplished by three steps:

1) server advertises whether it is able/willing to do CB
2) client decides whether to use CB, and tells server what it decided
3) client reports (1) back to server, protected by an HMAC.

The purpose of the second mechanism name is to accomplish (1).
The purpose of the second mechansim name is _not_ to indicate that use of 
CB is mandatory.  If you wanted to signal that, we'd actually need a 
_third_ mechanism name, because the client _must_ be able to distinguish 
the case where the server _cannot_ support channel bindings, in order to be 
able to do (2) correctly.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Mar 2009 00:15:30 -0600

Ah, right.  The server must advertise only one or the other of the two
names, never both as it's the client's choice of mech name that will
tip off the server to any MITMs.

If the server says "I can do SCRAM with CB" and the client picks "SCRAM
w/o CB" but still does CB then nothing bad happens, but if the client
picks "SCRAM w/o CB" and does not do CB then authentication must fail.
Which is why there's no point to advertising both names.

So SCRAM-SHA-1-BETTER and SCRAM-SHA-1-LESSER will do as mech names, but
the client implementor needs to understand both names.

Nico
--

---

From: Chris Newman <[email-masked]>
Date: Wed, 11 Mar 2009 18:42:38 -0800

> tip off the server to any MITMs.

As I stated in my previous message, I believe the one-or-the-other 
mechanism name creates an interoperability problem.  If that is WG 
consensus, I will likely only implement the non-channel-binding variant as 
I know all SCRAM software will support that variant.  If I were to add 
server support for the channel binding variant, that probably would break 
interoperability with a client that does not understand the 
channel-binding-name variant.  I don't think that's a good outcome as it 
sabotages deployment of channel bindings.

There is a flag which indicates "server can do TLS and has access to TLS 
channel bindings".  It is my belief this flag needs to appear both in the 
mechanism name and in the authentication mechanism itself.  The former is 
used by the client to select the appropriate mechanism and the latter can 
be used by the client to detect a downgrade attack.

The result is we have two mechanisms that have identical bits-on-the-wire 
just different names.  I'll call them SCRAM-SHA1 and SCRAM-SHA1-PLUS for 
now.

Case 1: server supports channel bindings.

Server advertises both mechanisms.  Client may negotiate either mechanism 
and use channel bindings with either mechanism if it wishes.  If client 
policy requires channel bindings it will ignore SCRAM-SHA1 and only 
negotiate SCRAM-SHA1-PLUS.

Case 2: server does not support channel bindings

Server advertises only SCRAM-SHA1.  SCRAM-SHA1 includes flag indicating 
lack of server channel bindings.  If client selects SCRAM-SHA1 and attempts 
to use channel bindings, authentication will fail.  Client may choose a 
mechanism other than SCRAM-SHA1 due to lack of server channel binding 
support that is detectable at mechanism name negotiation time.

Case 3: downgrade attack.

Server advertises both names.  Client sees only SCRAM-SHA1, selects it and 
notices the server does support channel bindings.  If client supports 
channel bindings, it will see the flag indicating server support for 
channel bindings and either fail with MITM error then or negotiate channel 
bindings on and channel binding will fail due to MITM.  If MITM changed the 
flag, authentication will fail because the flag is included in the 
authentication hash.  If client does not support channel bindings, it 
proceeds as usual (although there is a sub-case it can detect that's no 
point doing so as the client policy permits MITMs in this case).

This approach does not create an interop problem and I suspect the code 
will be simpler on both ends than it would be with an either-or naming 
model.

		- Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 12 Mar 2009 08:02:15 -0400

--On Wednesday, March 11, 2009 06:42:38 PM -0800 Chris Newman 
<[email-masked]> wrote:

> consensus, I will likely only implement the non-channel-binding variant
> as I know all SCRAM software will support that variant.  If I were to add
> lack of server channel bindings.  If client selects SCRAM-SHA1 and
> attempts to use channel bindings, authentication will fail.  Client may
> choose a mechanism other than SCRAM-SHA1 due to lack of server channel
> binding support that is detectable at mechanism name negotiation time.
>
> Server advertises both names.  Client sees only SCRAM-SHA1, selects it
> and notices the server does support channel bindings.  If client supports
> channel bindings and either fail with MITM error then or negotiate
> channel bindings on and channel binding will fail due to MITM.  If MITM
> changed the flag, authentication will fail because the flag is included
> in the authentication hash.  If client does not support channel bindings,
> it proceeds as usual (although there is a sub-case it can detect that's
> no point doing so as the client policy permits MITMs in this case).
>

Yes, I think that would work.

Thinking about this a bit more, ideally, neither a SASL framework library 
nor an application which uses such a library should need to know more than 
is absolutele necessary about the special relationship between these 
mechanism names.  Ideally, correct behavior should be achievable through a 
combination of three things:

- An interface which allows the application to pass channel bindings to
  SASL, and for the framework and mechanism to tell whether they were
  given.  I think this is necessary no matter what negotation model we
  end up with.

- Some way for the framework to know which mechanisms _require_ channel
  bindings.  For negotiation to select the correct mechanism in all cases,
  SCRAM-SHA1-PLUS must be considered such a mechanism, though I believe
  that in practice it will interoperate correctly even if this mechanism
  is used without channel bindings.

- Configuration, presumably provided by the user/administrator, which
  what mechanisms are used and in what preference order.

If client has CB:
  Case 1: server advertises + and -, client prefers +   => + with CB
  Case 2: server advertises - only, client negotates -  => - with no CB
  Case 3: server advertises + and -, client negotates - => - with no CB
          ... but downgrade is detected

If client has no CB:
  server advertises whatever; client negotiates -       => - with no CB

If client requires CB:
  Case 1: server advertises + and -, client requires +  => + with CB
  Case 2: server advertises - only, client requires +   => fail

Given the model you describe, this means clients should be configured to 
prefer SCRAM-SHA1-PLUS over SCRAM-SHA1, unless policy requires the use of 
channel bindings, in which case they should be configured to use only 
SCRAM-SHA1-PLUS.  This will result in negotiation of SCRAM-SHA1-PLUS 
whenever channel bindings should be used, and SCRAM-SHA1 when they should 
not; the mechanism decides whether to send CB depending on which mechanism 
name was used.  Note that this means we no longer need to send a separate 
bit indicating whether CB were used, since that is now implied by the 
mechanism name.

For downgrade detection, the client needs to send an additional bit of 
authenticated information.  In the proposal Nico originally posted, this 
was the client's idea of whether the server had advertised CB support (via 
the mechanism name); if this was clear but the server actually did 
advertise CB support, then a downgrade had been attempted.  Under your 
model, this bit indicates whether the client supports CB.  If it is set, 
and the server also supports CB, but they were not used, then there is a 
downgrade.

It is necessary for the downgrade-detection bit to be set from the client 
to the server, not the other way around, because detection depends on this 
bit being authenticated, and security depends on the downgrade being 
detected before the server considers authentication successful.  Suppose 
the server advertises CB support, an attacker suppressed that bit, and so 
the client chooses SCRAM without CB.  They then carry out an authentication 
exchange, during which the server claims to support CB, but the attacker 
modifies _that_ claim, so that again the server appears not to support CB. 
Now, the client will eventually figure that out, when the server's final 
response doesn't verify, but by then it is too late -- the server has 
already accepted the authentication, and the MiTM controls a connection to 
the server authenticated as the client.

-- Jeff

---

From: Chris Newman <[email-masked]>
Date: Thu, 12 Mar 2009 10:56:00 -0700

Sounds good to me.

		- Chris

--On March 12, 2009 8:02:15 -0400 Jeffrey Hutzelman <[email-masked]> wrote:

> nor an application which uses such a library should need to know more
> than is absolutele necessary about the special relationship between these
> mechanism names.  Ideally, correct behavior should be achievable through
> a combination of three things:
>
> not; the mechanism decides whether to send CB depending on which
> mechanism name was used.  Note that this means we no longer need to send
> a separate bit indicating whether CB were used, since that is now implied
> by the mechanism name.
>
> was the client's idea of whether the server had advertised CB support
> (via the mechanism name); if this was clear but the server actually did
> to the server, not the other way around, because detection depends on
> this bit being authenticated, and security depends on the downgrade being
> the client chooses SCRAM without CB.  They then carry out an
> authentication exchange, during which the server claims to support CB,
> but the attacker modifies _that_ claim, so that again the server appears
> not to support CB. Now, the client will eventually figure that out, when
> the server's final response doesn't verify, but by then it is too late --
> the server has already accepted the authentication, and the MiTM controls
> a connection to the server authenticated as the client.
>
> -- Jeff
>