Subject: SASL mechanisms via GSS-API and round trips

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Dec 2007 09:55:44 -0500

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.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2007 09:26:50 -0600

Sam,

GS2 takes adavantage of PROT_READY where available.  I think that's
enough.  I don't think there's any need to require PROT_READY support of
new mechanisms, though I would strongly recommend PROT_READY support
where it is actually feasible (I can imagine mechanisms where PROT_READY
couldn't be signalled before GSS_S_COMPLETE).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Dec 2007 10:40:01 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Sam, GS2 takes adavantage of PROT_READY where available.

No, GS2 implementations may take advantage of prot_ready where available but are not required to do so.

    Nicolas> 
    Nicolas> I think that's enough.  I don't think there's any need to
    Nicolas> require PROT_READY support of new mechanisms, though I
    Nicolas> would strongly recommend PROT_READY support where it is
    Nicolas> actually feasible (I can imagine mechanisms where
    Nicolas> PROT_READY couldn't be signalled before GSS_S_COMPLETE).

I explained why I don't think this is enough.  I'd appreciate an explanation of why I'm wrong.

Note, I'm only saying we should require prot_ready for new mechanisms
that people are going to want to implement as sasl native, not for all
new mechanisms.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2007 10:13:10 -0600

> that people are going to want to implement as sasl native, not for all

Ah, I must have misread -- I thought you wanted to make this requirement
for all GSS mechanisms.  I think I'm OK with making that requirement
only of all SASL/GS2 mechanisms.