Subject: GSSAPI and SASL

From: Marc Horowitz <[email-masked]>
Date: Wed, 29 Apr 1998 21:10:33 EDT

I've recently become aware of a possible change to SASL which I think
would be a serious mistake.  I'm going to base my arguments on rfc2222
(since I don't see a more recent draft), and on the archives I
downloaded from imc.org.

From: Chris Newman <[email-masked]>
Date: Thu, 15 Jan 1998 17:11:48 -0800 (PST)

>> I believe the problem is the basic GSSAPI assumption that the client and
>> server have the same mechanism "active."  This assumption fails in
>> practice and thus breaks interoperability.  I can see two ways to fix
>> this: (1) wait for SNEGO to go proposed and make that part of the GSSAPI
>> mechanism. (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms
>> which are specific interoperable profiles of GSSAPI mechanisms.

From: Mark Crispin <[email-masked]>
Date: Thu, 15 Jan 1998 17:15:01 -0800 (PST)

>> > (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms
>> > which are specific interoperable profiles of GSSAPI mechanisms.
>> 
>> It would be quite acceptable -- and probably extremely desirable -- to
>> do this.  I am assuming two things: it allows Kerberos 5 to remain
>> part of the base SASL specification, and it blesses implementations
>> that implement GSSAPI only for Kerberos 5.

I think it would be a tremendous mistake to separate out the GSSAPI
mechanisms this way.  One of the ideas behind the GSSAPI is that
applications which use it do not need to have any understanding of the
underlying security mechanism which is being used.  The SPNEGO
mechanism allows peers to negotiate a common mechanism without
requiring that this process be exposed to the caller.  At least wrt
authentication, there is no reason for any specific knowledge to be
exposed.

John Meyers makes a good point later:

From: John Gardiner Myers <[email-masked]>
Date: Mon, 26 Jan 1998 11:32:27 -0800

>> Let's take an example: the client supports both Kerberos v5 under GSSAPI
>> and Kerberos v5 under SNEGO under GSSAPI.  The server is older and
>> supports Kerberos v5 under GSSAPI, but doesn't support SNEGO.
>> 
>> If the organization has a Kerberos V5 infrastructure set up, the client
>> can still send either Kerberos v5 under GSSAPI or Kerberos v5 under
>> SNEGO under GSSAPI.  If it sends the latter, authentication fails, but
>> this is not due to any policy reason.

Looking at the IMAP and SASL specifications, there's no single
mandatory required authentication mechanism, so there's no guarantee
of interoperability, there, either.  (Where are {S,}CRAM-MD5 defined,
anyway?)  However, this problem can be solved.

IMAP could require that a particular SASL mech be implemented, and it
could also require certain behavior of the GSSAPI mech if it exists.
Given the unlikelyhood of a server which supports multiple mechanisms
but not SPNEGO, IMAP (and other protocols) could require this: request
SPNEGO, and if the acceptor doesn't recognize the mechanism, then fall
back to a "real" mechanism.  It is reasonable to expect SPNEGO will
get deployed widely, so this won't be necessary except for new clients
talking to older servers, which will also get upgraded relatively
quickly, one would think.

In any case, a client should be prepared to fall back, because
regardless of how cleverly the server constructs the list of
mechanisms it supports, the actual process can still fail.  Another
mechanism might succeed, and it would be nice if the client tried it.

This does require a bit of extra work now, but in the long run, it
will be worth it.  People may want krb5 now, but in a year, they'll be
asking for SPKI, or whatever, and it would be nice to have a clean
migration path.

I also think that putting GSSAPI in a separate document would be a
good idea.  Otherwise, it cannot progress to Draft Standard, since
GSSAPI isn't there yet, and this gives us some time to come to
consensus on the GSSAPI issues.

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

>> 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.

This is simply not true.  SAP has a server/client infrastructure which
is *completely* independent of the particulars of the underlying
mechanism.  In fact, they don't plan on shipping the GSSAPI mechanism
at all, for export reasons.  All they require is a proper mechanism in
a shared lib (unix) or DLL (windows).  SASL can do this, too, you just
need to decide you want to.  If you have questions (which is entirely
understandable, given the state of the documentation), please ask for
help; you'll get it.

		Marc