Subject: RE: SASL GSSAPI draft

From: "Linn, John" <[email-masked]>
Date: Tue, 30 May 2000 09:52:25 -0400

Ken wrote, excerpting:

> >
> >The reasoning is laid out in section 4 of my recently posted draft. 
> >There is a SHOULD NOT directive and a MUST directive in that section.
> 
> Okay, I reread this section.  I take it you mean this:
> 
>    A client which supports, for example, the Kerberos V5 GSSAPI
>    mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
>    mechanism will not interoperate with a server which supports the
>    Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
>    mechanism.
> 
> This might be right, but for the wrong reason.  As I read RFC 2478,
> you always deal with the OID of the underlying mechanism, so I
> don't think it's possible to support, for example, Kerberos "under"
> SPNEGO without just supporting Kerberos (well, let me rephrase that
> ... you could certainly write a SPNEGO implementation that would
> fail to interoperate with a vanilla Kerberos 5 GSSAPI implementation,
> but you would have to work at it :-).)  Having said that .... I
> think that a client that sent a SPNEGO token to a SPNEGO-unaware
> server would fail.  I have been thinking for a while on how to
> migrate to clients & servers supporting SPNEGO, and I haven't come
> up with any good ideas yet (if I'm missing something obvious, then
> please let me know).

It's certainly true that an SPNEGO token won't be usefully processable by a
target which doesn't support SPNEGO. If, however, a GSS implementation can
support GSS_MECH_A and GSS_MECH_B negotiated under SPNEGO, and that GSS
implementation is being used with SASL, it may not be too much incremental
effort to make GSS_MECH_A and GSS_MECH_B also available for negotiation at
the SASL level.  There's a security vs. interoperability tradeoff, since the
SPNEGO negotiation is protected but the SASL negotiation isn't.  I'd suggest
recommending, not discouraging, support for SPNEGO for use where available
and appropriate, but also recommending configurable support to allow
negotiation of individual GSS mechanisms at the SASL level.  

> 
> As for this:
> 
>    If a client's policy is to first prefer GSSAPI mechanism X, then
>    non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server
>    supports mechanisms Y and Z but not X, then if the client 
> attempts to
>    negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it
>    may end up using mechanism Z when it should have used mechanism Y.
> 
> This presumes that the app will have to have special-case code to
> determine which mechanisms exist and to apply policy information
> to the mechanism list; I'm not sure how you'll do that without
> giving the app knowledge of each mechanism, which would kinda defeat
> part of the purpose of GSSAPI.  I have a hard time imaging this done
> in practice (it seems that you can give SPNEGO some policy 
> constraints,
> but it doesn't give you the ability to do the ordering you want).

If an application client (and its associated SASL and/or SPNEGO client)
supports policy-driven mechanism negotiation, the preferred set might (1)
span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms
only, with non-GSS SASL mechanisms to be invoked only as a fallback if none
of the GSS mechanisms are available.  If (1), the client is most easily
served by performing the negotiation (and exposing the individual GSS
mechanisms) at the SASL level.  Given the prospect of (2), however, it'd be
good to be able to negotiate among the available GSS mechanisms in an
SPNEGO-protected manner.

--jl

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