Re: which is our DIGEST-MD5 successor?

[Jeffrey Hutzelman <jhutz@xxxxxxx>]

On Wed, 12 Mar 2008, Chris Newman wrote:

> If we have two wire encodings of the same mechanism, then SASL applications
> could access the same mechanism via two different names (e.g.,
> SASL-FRIENDLY-NAME, GS2-KSDJFHSLKDSF).  But a simple applicability
> statement to not use the latter in SASL-based protocols is sufficient to
> resolve interoperability problems for this case.  I can't see this as a
> matter that will cause significant confusion.

The problem in this case is that it requires GS2 implementations which
enumerate all GSS-API mechanisms and offer them all as SASL mechanisms to
know that _this_ mechanism is special and shouldn't be offered.  A large
part of the value of a wrapper is that it scales, making it unnecessary to
make specification or implementation changes to the SASL framework or SASL
applications for each new GSS-API mechanism.  Define a new mech (which
_anyone_ can do) and it just works.  The first time you require the
wrapper to handle a particular mechanism specially, you destroy that
property.




> While I prefer to avoid two different wire encodings for the same
function,
> I consider the deployability of the mechanism to be a much more important
> concern and the deployment impact of binary in the SASL authentication
> protocol is significant in my experience.

Let us please be clear.  SASL is not a text-based.  SASL is binary.
SASL-using application protocols may be text-based, and this often
requires them to hex- or base64-encode SASL messages.  You are not going
to be able to look at the bits on the wire and debug a SASL mechanism,
especially in the text-based protocols that are its major users, without
some decoding assistance.

For example, IMAP's AUTHENTICATE command exchanges base64-encoded tokens;
this means that you cannot read SCRAM's semi-human-readable tokens in a
packet trace.

SMTP's AUTH command behaves the same way.



I'm seeing an awful lot of "GS2 is going to make the wire encoding more
complicated!  It's binary; binary is always complicated!" and similar FUD.
I really wish people would stop spreading that, RIGHT NOW, and go actually
read (or re-read) the documents in question.

As has been said repeatedly and at multiple meetings, the only additional
constraints the GSS-API places on tokens exchanged by a mechanism is the
presence of standard framing on the first context token, which is used
primarily to allow the recipient of such a token to tell what mechanism it
belongs to.  SASL doesn't need this, but it needs to be present anyway in
order to allow a pure-sasl implementation to interoperate with a
deployment in which a GS2 implementation has been layered on top of the
SCRAM GSS-API mechanism, _which may be done by an adminstrator without
either component knowing about it in advance_.

The emphasized part is an important capability; it's akin to being able to
buy your IP service from someone other than who provides the DSL layer,
and that from someone other than the local phone company.  Or, if you
prefer, being able to buy your email service from someone other than your
ISP.


The same issue is likely to contain some other constraints, because GS2
must use the GSS-API's abstract interface and operate the same for every
mechanism.  So, for example, it's going to exchange some number of tokens
to establish a context, and then it's going to exchange a token to
authenticate the channel bindings.  That last token can often be sent in
the same message as the last token of the context exchange, saving a round
trip.  But this can be done only by putting them in the same SASL token,
which means we have to have some way of representing the length of the
first token and whether the second is present or will require a separate
message (possibly this could be inferred).  Sam and Nico will tell us
exactly what this might look like for SCRAM, but it's likely to involve a
count of some sort.


I'm sorry if you don't like binary protocols, but I don't find "I prefer
ASCII only" a compelling argument for introducing market confusion,
interoperability problems, and/or implementation complexity in what is,
after all, _already_ a binary protocol.

-- Jeff