Subject: Re: Sequence of attributes in a SCRAM message

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 15 Jun 2009 16:40:17 -0400

--On Monday, June 15, 2009 08:28:20 PM +0100 Dave Cridland 
<[email-masked]> wrote:

>
> On Mon Jun 15 19:47:32 2009, Nicolas Williams wrote:
>> On Mon, Jun 15, 2009 at 08:27:41PM +0200, Tobias Markmann wrote:
>> > Hi,
>> > From Section 5.1 of the latest draft:
>> >
>> > > Note that the order of attributes in client or server messages
>> is
>> > >    fixed, with the exception of extension attributes (described
>> by the
>> > >    "extensions" ABNF production), which can appear in any order
>> in the
>> > >    designated positions.  See the ABNF section for authoritative
>> > >    reference.
>> > >
>> > >
>> > Does this mean that during serialization, attribute 'a' goes
>> first, then
>> > 'n', 'm', 'r' and so on? If so why the restriction on sequence?
>>
>> The ABNF itself provides the order.  See the ABNF.
>
> That's not answering the question, though - what is the purpose of this
> rule? (I don't recall it existing before, except that 'r' was at the end).

It's not new -- the ABNF has always specified a sequence of particular 
attributes, some of which might be optional, not a sequence of aribtrary 
"key=value" pairs and a set of permissible keys.

There are several reasons for the ordering requirement, but much of it 
boils down to the fact that some of the attributes come from the GS2 layer, 
while others are SCRAM-specific.  The modularity needed to allow GS2 + 
GSS-SCRAM to interoperate with a pure-SASL SCRAM implementation imposes 
certain requirements.  One is that all of the bits of a message that are 
SCRAM-specific are grouped together and easily separable, so that GS2 can 
treat them as a single opaque string, since it cannot know the details of 
SCRAM.  Another has to do with the hash calculation; we need to be sure 
that the value being hashed is the same on both sides, which means either 
requiring a particular order for attributes or requiring implementations to 
pick out the attributes to be hashed and assembling them together in the 
right order.  This is probably doable, but "the right order" would have to 
group together everything passed down from the GS2 layer, including the 
actual channel bindings, because GSS-SCRAM cannot know that it is being 
called by GS2 and thus must treat the GSS-API CB application data (where 
GS2 puts the actual channel bindings and also things like the authzid and 
CB indicator flag) as an opaque string.

In short, we don't have to require a specific sequence of attributes, but 
allowing them to be reordered completely arbitrarily would break the 
protocol, and the constraints on how they can be reordered would be complex 
to describe and to implement.

I don't believe there is anything that would break if an implementation 
were to accept out-of-order attributes, as long as the hashes are computed 
in the same way by both sides (either in the order sent, or in the order 
specified in the protocol).  But I'd have to read the document fairly 
carefully to be sure there were no security ramifications.

-- Jeff