Subject: GSSAPI direction

From: [email-masked] (Sam Hartman)
Date: Wed, 21 Jul 2004 12:38:35 -0400 (EDT)

[This message and for the most part any of my participation in GSSAPI
discussions are in the role of a participant not as a WG chair.]

I'd like to start a discussion about what direction we want to take
with the GSSAPI work.  Our charter requires that the work needs to be
based on the existing draft.  We probably need to at least document
the behavior of the GSSAPI (kerberos 5) sasl mechanism.

However the current GSSAPI protocol seems to be fairly inefficient.
It requires an extra round trip to negotiate the security layers; it
does not piggyback this negotiation on the last token.  The mechanism
will not take advantage of the prot_ready flag to remove a half round
trip.  

I think the GSSAPI sasl mechanism need to be as efficient as we can
make them.  There are two primary motivations for this.  First, I'd
like to see GSSAPI HTTP be reasonably fast.  Second, I'd like to
remove any excuses we can for designing SASL mechanisms instead of
GSSAPI mechanisms.  Redundancy in security protocols is undesirable.

Note that if we do change the gssapi draft in an incompatible manner,
we would need to change the prefix of the sasl mechanism names.  Note
also that changing the gssapi mechanism is more reasonable than the
other mechanisms; so far the gssapi mechanism is only an internet
draft.  There is a description of GSSAPI in RFC 2222 but we're already
going to end up being incompatible with that description for
everything besides Kerberos.

--Sam

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 25 Jul 2004 22:29:31 +0100

>the behavior of the GSSAPI (kerberos 5) sasl mechanism.
I agree.

>Note that if we do change the gssapi draft in an incompatible manner,
I don't mind the changes you are proposing (at least I agree with their 
motivation), however this suggestion is a bit late and I would like to 
point out that there several independent implementations of GSSAPI 
(Kerberos) mechanism that interoperate well (at least better than 
DIGEST-MD5).

I am afraid that it is not possible to reduce existing 2 round trips in 
a backward compatible manner. I would be glad if you can prove me wrong.

So, if the WG wants to tackle the issue that you've described above, I 
would suggest that the WG publishes the existing GSSAPI draft as GSSAPI 
Kerberos-only and designs a new GSSAPIv2 (which works for all GSSAPI 
mechanisms) in a separate draft.

>everything besides Kerberos.
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 25 Jul 2004 22:29:31 +0100

I agree.

Alexey