Subject: Re: Call for volunteers: Moving SASL to draft status (fwd)

From: Chris Newman <[email-masked]>
Date: Mon, 02 Feb 1998 10:29:45 -0800 (PST)

On Mon, 26 Jan 1998, Steve Hole wrote:
> On Fri, 23 Jan 1998 16:11:48 -0800 John Gardiner Myers <[email-masked]> 
> wrote:
> > (2) sounds like a very good idea.  GSSAPI mechanism implementations
> > which use different underlying GSSAPI mechanisms won't interoperate. 
> > Defining a separate SASL mechanism for each underlying GSSAPI mechanism
> > will allow this to be negotiated at the SASL layer.  
> > 
> > When SNEGO finally arrives, we can have GSSAPI-SNEGO.  I don't think
> > GSSAPI-using-Kerb5 interoperates with GSSAPI-using-SNEGO-using-Kerb5
> > anyway, so having a GSSAPI-SNEGO which can negotiate Kerb5 be separate
> > from GSSAPI-Kerb5 is a good thing.
> > 
> > We can either define a new GSS-KERB5 only if we act quickly, otherwise
> > we'd have to declare that the name GSSAPI refers to GSSAPI using
> > Kerberos V5.
> > 
> > Do we have a quick consensus to change this?
> 
> Hang on a minute.   The issue is that a client and server GSSAPI will
> not interoperate if they implement different underlying mechanisms.  If
> so then: (1) this will probably not happen often in practise because
> the authentication infrastructure an organization uses is usually controlled
> by the organization and (2) if it does happen, then authentication fails for a 
> valid reason.

The reason I proposed this change initially is that I dislike multi-level
negotiations.  Suppose you have a GSSAPI client which supports both
Kerberos-5 and public key?  When you try Kerberos-5 and it fails with
invalid messages for the Kerberos-5 GSSAPI mechanism, do you retry GSSAPI
to see if the server is using the public key or do you fall back to a
different SASL mechanism since GSSAPI failed?  It makes the code more
complicated to deal with cases like this.

> I am not totally set in this position.   The GSSAPI thing is messy.   I just
> wish that we had some more experience with it before we start mucking about
> this way.   At this time I don't really see all that big a win in doing this,
> but that could very well change in the near future as we try to deploy our
> implementation.

If we wait, I suspect GSSAPI will mean "Kerberos 5 GSSAPI mechanism."
That will only cause problems for GSSAPI mechanisms other than Kerb5.

		- Chris

---

From: Mark Crispin <[email-masked]>
Date: Mon, 2 Feb 1998 12:06:30 -0800 (PST)

On Mon, 02 Feb 1998 10:29:45 -0800 (PST), Chris Newman wrote:
> > the authentication infrastructure an organization uses is usually
> > controlled by the organization and (2) if it does happen, then
> > authentication fails for a valid reason.

This seems to be based on the notion that this can be configured in the
application (client and server) by the organization.  I don't think that this
is a valid assumption.

GSSAPI is not like c-client, which carefully keeps the application at a
distance from its drivers.  GSSAPI only takes you so far, then you start
having to have knowledge about the actual authentication infrastructure.

Think in terms of a world where most people do not build their own binaries.

Both my client and (especially!) server code have K5 knowledge.  The client
code may function with something other than K5, although you would definitely
have to rebuild and the error handling won't be right without source code
changes.  The server code will definitely not function without source code
changes.

My code isn't the only offender, either.

> That will only cause problems for GSSAPI mechanisms other than Kerb5.

This has already happened.  It's too late to prevent it.

It isn't too late to get the responsible parties to transition to a different
name for "Kerberos 5 GSSAPI mechanism" but time is rapidly running out.

---

From: Chris Newman <[email-masked]>
Date: Mon, 02 Feb 1998 10:29:45 -0800 (PST)

- Chris

---

From: Mark Crispin <[email-masked]>
Date: Mon, 2 Feb 1998 12:06:30 -0800 (PST)