Subject: Re: SASL GSSAPI draft

From: Ken Hornstein <[email-masked]>
Date: Thu, 25 May 2000 17:02:22 -0400

>This draft maintains the SHOULD NOT directive against using SPNEGO
>underneath SASL.  When the previous draft was published, this raised an
>objection, but the objection was nontechnical and failed to address or
>consider the interoperability and security problems which led to the
>SHOULD NOT directive.

I think I might have missed that discussion (or did it take place on
ietf-sasl?).

I'd hate to ask you to reiterate all of that discussion again, so if
you could please point me to a mailing list archive and an approximate
time frame that the discussion about not using SPNEGO in SASL took
place, I'll go away quitely :-)

--Ken

---

From: [email-masked] (John Myers)
Date: Thu, 25 May 2000 14:39:42 -0700

> I think I might have missed that discussion (or did it take place on

There was some discussion around March/April 1999 on the CAT mailing
list.  I wouldn't say those discussions resolved the issue.  Please feel
free to bring up concerns you have with my recently posted draft.

> place, I'll go away quitely :-)

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.

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 29 May 2000 23:36:12 -0400

>free to bring up concerns you have with my recently posted draft.

Okay, I saw only a message from Bill Ricker asking about SPNEGO,
posting by you, and Paul Leach's reply.

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

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

I'm really torn here.  I can't see the harm in duplicating the SASL
negotiation with SPNEGO, and SPNEGO negotiation _is_ protected without
having to do any extra work ... but the SASL negotiation really is
better suited to piecemeal upgrade, which makes me think it's a better
choice (but I'm not completely convinced).

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 25 May 2000 17:02:22 -0400

--Ken

---

From: [email-masked] (John Myers)
Date: Thu, 25 May 2000 14:39:42 -0700

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 29 May 2000 23:36:12 -0400

As for this:

--Ken