Subject: Re: SCRAM "mandatory extensions"?

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 07 Dec 2008 21:13:13 -0500

--On Thursday, November 27, 2008 12:03:04 PM +0100 Hallvard B Furuseth 
<[email-masked]> wrote:

>
> 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?

Nothing.  Since no such extensions are currently described, the server 
can't possibly support them, and so if the attribute is present, 
authentication fails.  Period.

The purpose of this field is to provide a mechanism to allow extensions to 
be defined in the future which cannot be safely ignored by servers that do 
not understand them.  To do that, there must be a field which all servers 
_do_ (MUST) understand, at least enough to know it means there is something 
going on they do not understand.

The semantics of this attribute are quite simple and clearly described in 
the text you quoted:  Presence of this attribute... MUST cause 
authentication failure.  Period.

At some point in the future, we might publish a new version of the spec 
which defines new semantics for this field such that sometimes it can be 
present and not cause authentication failure.  But that's the future.

-- Jeff

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 8 Dec 2008 14:07:59 +0100

Simon Josefsson writes:
>Hallvard B Furuseth <[email-masked]> writes:
>>> 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.
>
> 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:

Sorry, I seem to have invited a bit confusion here.  SCRAM has two
extension fields: "mandatory-exts" (m=) which always return failure,
and "extensions" which are ignored if not recognized.

I don't know the reason why either was introduced in the draft.

I can see why the (non-mandatory) extensions can be useful, such
as a "try this mechanism instead" response which takes no extra
round trips.  Whether it's worth the extra complexity I don't know.

OTOH as far as I can tell, mandatory extensions which always fail
can be replaced with a separate QUERY mechanism which always fails.
E.g. both initial response and result could look something like this:

  <protocol-specific field - e.g. return status value> ":" <query type>
  ":" <mechanism> ":" <mechanism-independent> ":" <mechanism-specific>

Let all fields be optional - an absent mechanism might ask about SASL
status in general, and an invalid mechanism like "*" could ask about all
mechanisms.

Or the syntax could be more complex, e.g. allowing multiple queries, but
never mind for now.  I don't even know.  Since I didn't know why "m="
was introduced in the first place it seemed premature to go into much
detail about their replacement.

Anyway,

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

Depends on what the server is being queried about.
Remember that "m=" and thus "QUERY" is for as-yet unspecified
extensions, not just a single extension.

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

More generally, QUERY could return any info at all which the SASL
implementation feels like chatting about, so for each extension/QUERY
type one needs to consider server policy for access/integrity
protection.

> 3) Should the QUERY mechanism pseudo-authentication step fail or
> succeed?

Fail.  The draft makes the right call here.  Consider access control
based on whether the user successfully authenticated, in a server which
does not now about QUERY in particular.  Instead the server has a policy
to only accept mechanisms of a configured strength.

If QUERY could succeeded, anyone could gain access.  Thus QUERY which
can succeed, like ANONYMOUS, must have strength zero - and would be
rejected by this server.

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

My protocol-specific field in the message format above:-)

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

Note that I originally brought this up because I thought the feature was
misplaced in this draft, not because I have any particular need for it
at the moment.  The same goes for the extensions below, but just to have
mentioned it:

While the mandatory extensions seem like they can be moved to a separate
draft, the "optional" extensions (which are ignored if unrecognized)
cannot.  Yet I imagine the need for that is the same in SCRAM as in
other mechanisms.

To move them out of the draft so other mechanisms could use it, SASL
itself would have to be extended: Add a new set of optional messages
which can be passed along with the challenges and responses.

Also failed authentication can have an effect - resetting the connection
to anonymous in LDAP, or closing the connection in some applications.
The latter may make QUERY useless for per-connection info.  To fix that,
SASL would have to be extended to include non-authentication
response/challenge messages, which would not need to fail like QUERY.

-- 
Hallvard

---

From: Philip Guenther <[email-masked]>
Date: Mon, 8 Dec 2008 10:06:56 -0800

On Mon, 8 Dec 2008, Hallvard B Furuseth wrote:
...
> I don't know the reason why either was introduced in the draft.

I see these as directly parallel to the LDAP concept of 'criticality' on 
controls.  A manadatory extension is like a critical control; a plain 
extension is like a non-critical control.  So, how well has the concept of 
criticality worked out in LDAP?  I see extensions RFCs that say that the 
client MUST set the criticality value to TRUE, so it appears it has been a 
necessary capability for extending LDAP in certain ways.  It seems to me 
that the question is whether the likelihood of an extension needing this 
capability balances the cost of defining it and whether there are 
alternative ways of obtaining the same result.

(I seem to recall some recent discussion on an LDAP mailing list about 
issues in how criticality was actually specified.  Perhaps there's some 
lesson that could be carried over into this document.)

Philip Guenther

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Dec 2008 15:41:39 -0500

--On Monday, December 08, 2008 10:06:56 AM -0800 Philip Guenther 
<[email-masked]> wrote:

> It
> seems to me  that the question is whether the likelihood of an extension
> needing this  capability balances the cost of defining it

I think it does.  For critical extensions to work, there has to be a 
mechanism for signalling their presence to implementations which do _not_ 
support them.  You can't define the mechanism for labelling extensions as 
critical the first time you actually have one, because an implementation 
which does not support the new extension will then also not support the 
criticality mechanism.  Thus, the benefit of defining it up front, and more 
directly the cost of not doing so, is very high.

IIRC, we originally discussed the question of critical extensions and the 
need to define a criticality mechanism up front during the Dublin meeting. 
During that discussion, we made some compromises to keep down the cost of 
defining such a mechanism.  For example, we agreed to avoid specifying the 
syntax of the m= attribute, or its semantics beyond the requirement that 
authentication fail if it is present.  This gives us enough to insure that 
criticality works, while putting off as much as possible of the work of 
defining it until we actually need it.

> and whether
> there are  alternative ways of obtaining the same result.

Certainly there are.  For example, one could simply declare that all 
extensions are critical.  However, that doesn't really reduce the amount of 
work needed, because then if you ever want non-critical extensions you have 
to define a way of signalling that an extension is non-critical, and that 
signalling mechanism has to be in the base spec, or else things that don't 
understand a new extension also won't understand that it is non-critical.

I think we came to the conclusion that non-critical extensions are more 
likely than critical ones, and that specifying that a single specific 
attribute is critical without specifying its semantics was less work than 
making all extensions critical and then having to specify how the 
non-critical-extension atrtibute works (which I think you'd have to do up 
front).

-- Jeff

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Dec 2008 13:49:34 +0100

Philip Guenther writes:
> controls.  A manadatory extension is like a critical control;

No.  An LDAP critical control only causes failure if it cannot be
applied.

A SCRAM manadatory extension always causes auth failure.  Looks like a
cheat to insert a "non-authentication operation" in SASL, which is why
I'm suggesting to make it a separate SASL mechanism.

Chris/Alexey, could you say something about all this?

> a plain extension is like a non-critical control.  So, how well has
> the concept of criticality worked out in LDAP?

LDAP criticality - "this LDAP operation MUST fail if the control is
unknown or fails" - is a necessary feature for some LDAP controls.  For
example the "assertion" control, which says that the LDAP request shall
not be run unless assertion about the related LDAP entry is verified.

> lesson that could be carried over into this document.)

LDAP criticality was originally poorly defined and too flexible, which
left quite a mess in some control specs.  It's been cleaned up in the
latest LDAP standard, but that doesn't fix those old control specs.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Dec 2008 19:14:59 +0100

Jeffrey Hutzelman writes:
>> (...)
> not understand them.

Is the idea that such an extension definition will contradict the "auth
MUST fail" statement in this draft, so that auth with m= can succeed
after all?  If so I suggest to phrase that differently in the draft.

Also the "m" attribute would need a syntax of its own, so that
different mandatory extensions can be defined independently of each
other.  They can't all identify themselves as just "m".

> To do that, there must be a field which all servers _do_ (MUST)
> understand, at least enough to know it means there is something going
> on they do not understand.

True, but the placement of an unknown extension in front of
client-first-message / server-first-message in the syntax is suffixient
to force a syntax error.  An "m=" attribute is not necessary for that.

Well, I guess the draft should explicitly say that syntax error should
cause auth failure.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Dec 2008 19:37:11 +0100

> No.  An LDAP critical control only causes failure if it cannot be

Sorry, I had not seen Jeffrey's message yet.

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 09 Dec 2008 14:17:00 -0500

--On Tuesday, December 09, 2008 07:14:59 PM +0100 Hallvard B Furuseth 
<[email-masked]> wrote:

>> The purpose of this field is to provide a mechanism to allow extensions
>> to  be defined in the future which cannot be safely ignored by servers
>> that do  not understand them.
>

The idea is that the first time we need a critical extension, we publish a 
specification which defines the syntax of "m" and how it works and replaces 
the "MUST fail" rule with a newer one.  That specification would be an 
update to SCRAM, and would become a normative reference for any critical 
extension.  We could, of course, just include that in the base SASL spec, 
but the idea was to avoid spending time specifying it until we need it.

-- Jeff

---

From: Chris Newman <[email-masked]>
Date: Wed, 24 Dec 2008 16:56:12 -0800

> Chris/Alexey, could you say something about all this?

Personally, I don't think extension mechanisms within a SASL mechanism 
serve much purpose and hope they're not used.  I'd prefer SCRAM was a 
simpler mechanism without extensibility (a new mechanism can be defined if 
necessary or we can fix critical omissions when we go from SCRAM-SHA1 to 
SCRAM-NIST-HASH-WINNER).  But some people feel strongly about this issue 
and I don't.

		- Chris

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 25 Dec 2008 05:18:33 -0800

On Dec 24, 2008, at 4:56 PM, Chris Newman wrote:

>
> --On December 9, 2008 13:49:34 +0100 Hallvard B Furuseth <[email-masked] 
> > wrote:
> Personally, I don't think extension mechanisms within a SASL  
> mechanism serve much purpose and hope they're not used.

I generally agree.  The double negotiation is problematic, especially  
in protocols which only allow one authentication attempt per session.

It's really annoying when an mechanism is offered but then one  
discovers later that it's not offered with some key feature.

I much rather mechanism name be used to advertise and select variants  
of a mechanism (as separate mechanisms).

> I'd prefer SCRAM was a simpler mechanism without extensibility (a  
> new mechanism can be defined if necessary or we can fix critical  
> omissions when we go from SCRAM-SHA1 to SCRAM-NIST-HASH-WINNER).   
> But some people feel strongly about this issue and I don't.
>
> 		- Chris