SASL mechanisms via GSS-API and round trips

[Sam Hartman <hartmans-ietf@xxxxxxx>]

One of the things I think we're going to need to do to make specifying
mechanisms as GSS-API mechanisms acceptable to the apps community is
to reduce options and implementation complexity.


Unless we've screwed something up, I think we have the normal case of
a client-first mechanism via GS2 working so that it will be the same
number of packets without significant extra bytes as the same
mechanism as a native SASL mechanism.


However GS2 does not require prot_ready support and does not require
optimal number of round trips.

Let's take a simple challenge response mechanism

c->s: {client_name , null}
s->c: {server_nonce,null}
c->s: {f(key,client_nonce,server_nonce), wrap(authz_id,cbdata)}
s->c: {g(server_nonce, client_nonce), wrap(flags)}

I'm talking about an idealized gs2 here; there's also goop to say that
neither side wants a security layer in some of those packets.

That's roughly what gs2 of a sasl mechanism would look like assuming
that people are being optimal.  I don't think doing a native
non-gss-implementation that is wire compatible with that is hard.
However if that native implementation talks to a real gss
implementation you may get something like


c->s: {client_name , null}
s->c: {server_nonce,null}
c->s: {f(key,client_nonce,server_nonce), null}
s->c: {g(server_nonce, client_nonce), wrap(flags, cbdata)
c->s: {null, wrap(flags,authzid)}


I'd need to go back and look at the spec.  IT may turn out that it can
take an extra round trip if the wrap token from the server to the
client is null and the client has to send first after all the context
tokens are done.  I don't think that is permitted though.

It seems like supporting that interaction would significantly increase
the control loop complexity of the native SASL mechanism.  I bet that will be unacceptable to a lot of people.

So, I think we're going to have to require that you use the optimal
number of round trips.  That's kind of complicated to do.  Not all
mechanisms specify whether they support prot_ready.

I'm sort of imagining a requirement in GS2 that for GSS-API mechanisms
that mandate prot_ready support,GS2 must take advantage of it.  Then
in anything we design expecting that it will be both a SASL mechanism
without GSS code and is using the GS2 wire protocol we require
prot_ready support in the mechanism.

Put another way, we thread a requirement through a couple abstraction
layers to say that you shouldn't be stupid.

This does increase the minimum complexity of a generic GS2 mechanism.
However I think it significantly saves on the complexity of
wire-compatible native SASL mechanisms.