--On Monday, June 15, 2009 08:28:20 PM +0100 Dave Cridland <dave@xxxxxxxxxxxx> 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