Subject: RE: GSS-SPNEGO

From: Paul Leach <[email-masked]>
Date: Thu, 11 Feb 1999 17:22:11 -0800

Without GSS-SPNEGO, there is currently no way to handle a system that has
multiple GSS mechanisms.

Also, there is no currently support for clients and servers that support
GSS, but have different GSS mechanisms.
For example, a server that has Kerberos5 will offer the SASL GSSAPI; a
client that has GSS SPKM mechanism will believe it should accept the GSSAPI,
and they will not interoperate. That's pretty blatant. Even worse, a client
that supports SPKM and Kerberos5 has a 50/50 chance of interoperating with a
server that offers GSSAPI and suppports SPKM or Kerberos but not both. 

It is true that GSS-SPNEGO under SASL in theory does redundant negotiation.
However, to avoid it in fact and practice, you'd have to do something like
registering every GSS mechanism as its own SASL mechanism. For example,
there would have to be a SASL GSS-KERBEROS5 mechanism, and a GSS-SPKM
mechanism, and so forth for each new GSS mechanism. No one has done that.
I'm not averse to that solution, except for one thing: SASL negotation (if I
remember correctly) is not specified to be protected, unlike SPNEGO. That
means either it is subject to a dumbing down attack, or each protocol has to
perform a new, not yet specified, step to exchange the original list of SASL
mechanisms with integrity protection.

I'm not sure why the third sentence is relevant, but it is wrong. If a
server offers GSS-SPNEGO then it can also interop with Kerberos or SPKM or
any other GSS mechanism that it supports. That is because GSS blobs are self
identifying, so a properly coded server can look at one and decide which
mechanism to hand it to.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 11, 1999 4:33 PM
> To: Bill Ricker
> Cc: Paul Leach; [email-masked];
> [email-masked]
> Subject: Re: GSS-SPNEGO
> 
> 
> 
> I strongly recommend against using SPNEGO with SASL.  SPNEGO 
> duplicates
> the mechanism negotiation of SASL, and cannot use information about
> non-GSSAPI mechanisms in the negotiation.  I am also under the
> impression that a given GSSAPI mechanism under SPNEGO under SASL will
> not be able to interoperate with the same GSSAPI mechanism directly
> under SASL.
> 
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]