Subject: SCRAM "mandatory extensions"?

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 27 Nov 2008 12:03:04 +0100

I don't understand the purpose of the SCRAM "m" (mandatory extensions)
field.  The scram-07 draft says:

  - m: Presence of this attribute in a client or a server message MUST
    cause authentication failure when the attribute is parsed by the
    other end.  The purpose of this attribute is to describe list of
    mandatory extensions to SCRAM that the other end must support.
    This attribute is reserved for future extensibility.

What's the server supposed to use this information for?  Return a "m="
message to the client about what extensions it does support?  If so that
could be useful, but for other mechanisms too.  So I think a new SASL
mechanism QUERY would be better.  The parameters could include an
optional mechanism name if one wants to ask about a specific mechanism.

As for "m=" sent to the client - if it's in response to an "m=" from the
client, that's covered by QUERY above.  If it's not - then it seems to
me the server will have announced that it supports SCRAM, only to reply
"no, not ordinary SCRAM" when the client tries to use it.  Seems to me
that could be more cleanly achieved by defining another mechanism
consisting of SCRAM + the extension.

Am I missing something?

-- 
Hallvard

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Nov 2008 13:04:29 +0100

> consisting of SCRAM + the extension.

It looks like future extensibility to me.  I'd prefer to avoid it, the
SASL framework (and GSS-API too, for that matter) is extensible, no need
to reproduce that in each mechanism too.

/Simon

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 27 Nov 2008 14:03:14 +0100

Simon Josefsson writes:
> It looks like future extensibility to me.

Yes.  I should have said, I don't see what good the m= field does.
The draft has a field with optional extensions too.

> I'd prefer to avoid it, the SASL framework (and GSS-API
> too, for that matter) is extensible, no need to reproduce
> that in each mechanism too.

Well, SASL limitations have come up, like my desire for a server
to be able to respond "for this user, try this mecanism/SCRAM
hash instead".  But that's not a mechanism-specific problem.
I think I'm gonna sit on the fence for that one.

-- 
Hallvard

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Nov 2008 14:24:17 +0100

> I think I'm gonna sit on the fence for that one.

I thought more about a potential QUERY mechanism, and I see three
problems with it.  I think the problems can be solved, but they reduce
the neatness of the idea:

1) Authentication identities is a mechanism-specific concept.  However,
this could be solved by simply saying that a server is responsible for
querying all supported mechanisms whether the associated username is
known or not, and then potentially list a number of SASL mechanisms that
may support that particular username.

2) The list of mechanisms to return is not integrity protected.  This
can be solved by saying that QUERY is only useful with TLS and when the
eventually used SASL mechanism checks channel bindings.

3) Should the QUERY mechanism pseudo-authentication step fail or
succeed?  What happens on SASL mechanism failures is somewhat
implementation specific, and may be application protocol specific, so it
needs to be discussed and tested how it works in practice.

I would be interested in helping documenting and implementing a QUERY
mechanism though, if others are interested in it...

/Simon