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]
> 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]

---

From: [email-masked] (John Myers)
Date: Fri, 16 Jun 2000 16:34:28 -0700

"Linn, John" wrote:
> the SASL level.

Agreed.  There is also a problem case where the policy prefers a
non-GSSAPI mechanism over a particular GSSAPI mechanism.  One possible
reasonable policy would be to first prefer Kerberos, then DIGEST-MD5,
then GSS-API-Easy.  If a server only supports DIGEST-MD5 and
GSS-API-Easy, a client might through SPNEGO inadvertently use
GSS-API-Easy instead of DIGEST-MD5.

> If GSS mechanisms are exposed for negotiation at both the
> a protected means to select among the available GSS mechanisms.

One issue is whether or not it is a reasonable policy for the server to
only accept certain weaker GSS mechanisms when their use has been
negotiated through SPNEGO.  If it is a reasonable policy, then the
draft's current MUST wording about advertising the strongest GSS
mechanism at the SASL layer is sufficient.  If it is not a reasonable
policy, then the requirement needs to be strengthened to say that all of
the GSS mechanisms supported inside SPNEGO MUST also be advertised at
the SASL layer.

For SPNEGO to be useful, a client must not only have the policies you
state, but must additionally support and have access to credentials for
at least two GSS mechanisms.  Steve Hole, who has implemented both
Kerberos and SPKM, reports that in his experience any given client or
server only has access to infrastructure for one GSS mechanism.

I won't claim that it will never happen, but the set of policies and
circumstances for which SPNEGO under SASL is necessary is rarely
practical.

> One argument against SPNEGO under SASL (additionally to SASL-level

The incremental complexity of implementing SPNEGO is not necessarily
modest.  The SASL implementation I am currently working on and the CMU
Cyrus SASL library both allow for SASL mechanism plug-ins.  It would be
relatively straightforward to create a SASL mechanism plug-in
implementing Kerberos--that plug-in could then be loaded into any
product implemented using the library.  To support Kerberos underneath
SPNEGO, either the SASL library would have to implement both GSSAPI and
SPNEGO or one would have to create a GSSAPI/SPNEGO SASL plug-in and then
have Kerberos plug-in to the GSSAPI plug-in.

> exception), would this be a good candidate for compromise on a MAY?

I am extremely worried about offering two different ways to do the same
thing.  When a protocol offers multiple ways to do something, it is not
uncommon for an implementation to only test one of them.  Even if only
one way is a MUST IMPLEMENT, that is not necessarily the way that gets
tested.  If an implementation botches the MUST way and gains wide
deployment due to some some other way working, the protocol effectively
ends up with two or more MUST IMPLEMENTS.

(This is a form of the "be liberal considered harmful" argument.)

This is why I wrote this as a SHOULD NOT requirement with a listed
exception.  I am trying to get implementors to think about their
customer's security requirements and only take on the complexity and
risk of noninteroperation if the security policy and set of
circumstances require.  If we change the SHOULD NOT to a MAY, how else
can we minimize the risk of clients and servers which only work with
SPNEGO due to implementation laziness or error?