Subject: RE: SASL GSSAPI draft

From: "Linn, John" <[email-masked]>
Date: Tue, 13 Jun 2000 09:59:06 -0400

Properly, I think, the interoperability concern applies to the case where
GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at
the SASL level.  If GSS mechanisms are exposed for negotiation at both the
SPNEGO and SASL levels, this would provide the broadest degree of
interoperability, supporting even those clients whose policies reject
negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as
a protected means to select among the available GSS mechanisms.  If it's
plausible for a client to have such a policy, even though it's interacting
with a server which may also have clients having other policies,
interoperability would be best served by allowing negotiation at both
levels.  One argument against SPNEGO under SASL (additionally to SASL-level
exposure of the same GSS mechanism set) is that it adds complexity which
would be superfluous in some situations; the (apparently modest) incremental
complexity might be justified by the fact that it enables a protected
negotiation which would be usefully and additionally secure in other
situations. 

Generally, wrt SPNEGO support under SASL, we've seen arguments for both
positions.  Rather than the present SHOULD NOT (albeit with listed
exception), would this be a good candidate for compromise on a MAY?   

--jl

> -----Original Message-----
> From: Ken Hornstein [mailto:[email-masked]]
> Sent: Monday, June 12, 2000 5:37 PM
> To: [email-masked]; [email-masked]
> Subject: Re: SASL GSSAPI draft 
> 
> 
> >   You keep bringing up these mythical "only Kerberos V5 underneath
> >   SPNEGO" implementations.  Even if you're doing SPNEGO, you still
> >   have to parse V5 GSSAPI tokens; I can't really imagine a reason
> >   why you would not be able to handle a V5 GSSAPI token exchange
> >   without SPNEGO.  I don't think this is a legitimate reason for
> >   recommending against the use of SPNEGO.
> >
> >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition
> >to SPNEGO, no additional security is obtained via SPNEGO (the active
> >attacks that SPNEGO prevents are just circumvented by removing SPNEGO
> >from the capabilities line).
> 
> That's true, with the current draft.  But if GSSAPI simply means, "any
> GSSAPI mechanism", then there's no reason a non-SPNEGO client can't
> interoperate with a SPNEGO-aware server, without any loss of security
> that I can tell (since there wouldn't be any negotiation in the
> non-SPNEGO case).
> 
> I was under the impression that "the interoperability 
> problem" was given
> as a reason not to use SPNEGO; that's the only reason why I'm saying
> I don't think it's a valid reason.
> 
> --Ken
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> 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]
>