Re: Holding gs2

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Sun, Jan 27, 2008 at 06:27:47PM +0000, Alexey Melnikov wrote:
> I consider reduction of round-trips as the main goal of GS2.

But it doesn't quite meet that goal.  It can cost an extra half
round-trip for some mechanisms, IIRC.  (If your krb5 mech initiator
implementation doesn't support PORT_READY then it can even cost you an
extra half round-trip when using krb5.)

(Of course, channel binding alone can cost you an extra half round-trip
-- think of krb5 w/o mutual authentication: to add channel binding you
must do mutual auth, which means 1 round-trip instead of half.)

However, Sam's objection is not about round-trips, but about complexity
for implementors who wish SASL mechanisms but not GSS mechanisms: the
gs2 approach forces them to implement MIC tokens.

Sam is proposing SASL mechanisms that support channel binding but not
any security layers, which effectively changes the semantics of channel
binding that we had assumed/concluded we wanted.  This change can
greatly simplify the design of future SASL mechanisms, and it can
greatly simplify the design of a SASL/GSS bridge for GSS mechanisms that
support channel binding.

> How about publishing GS2 as Experimental RFC and move it (or replace it, 
> if errors are found) to Standard Track once we have some implementation 
> experience?

We could say that the channel binding semantics that gs2 provides are
experimental...

Or we could do (2b) as I suggested, and maybe profile gs2 for simple,
channel-binding-but-no-security-layers SASL mechanisms.  Or we could
pursue the latter as a separate thing altoghether and separately
describe a SASL/GSS bridge (gs2 extensions or gs3) with the same
properties.  I haven't yet thought enough about which approach will get
us there faster.

If we agree that we don't need any new SASL mechs to provide security
layers, and that we don't care for GSS mechanisms that don't support
channel binding, then we can even abandon gs2 and go for gs3 with a much
simpler design (using GSS-API channel bindings to do the channel binding
work and to protect the authzid -- no MIC tokens needed).

> >If I recall correctly, the use-case of hybrid SASL and GSS-API
> >mechanisms was established after we decided to do GS2.

Sam and I had been wanting a SASL/GSS bridge for a long time, and we
wanted channel binding to be a primary feature.  Sam now suggests that
we selected a channel binding semantic that was too complicated.

Nico
--