Subject: RE: Do we have any consensus on the 8003 checksum

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 11 Sep 2003 16:21:48 -0700

Sam Hartman wrote:
>> Also, making U2U be the same OID requires that everyone support U2U.
>> I think MIT would be much faster to implement this mechanism if U2U
>> had a different OID.

MS has shipped the GSSAPI/U2U implementation with a different OID.  This
enables the client to request for U2U explicitly (when both u2u and
regular Kerberos are available).

Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Thursday, September 11, 2003 2:33 PM
To: [email-masked]
Cc: Nicolas Williams; Liqiang(Larry) Zhu; [email-masked];
[email-masked]
Subject: Re: Do we have any consensus on the 8003 checksum

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Nicolas Williams wrote:
    >>  Speaking of which, would you like user-2-user to be part of
    >> this mechanism (with or without a different OID - I'm talking
    >> about the mech design)?

    Martin> My personal preference is that you stick with a single
    Martin> mechanism OID.  For dealing with multiple mechanism OIDs
    Martin> you would normally require SPNEGO to be available, and you
    Martin> may confuse (existing) applications that recognize the
    Martin> rfc-1964 mechanim OID but not the new one.

How do you negotiate whether to use U2U?  The hack of having the KDC
return an error is not appropriate because there may be situations
where U2U needs to be used even when a principal can sometimes act as
a service principal.

Also, making U2U be the same OID requires that everyone support U2U.
I think MIT would be much faster to implement this mechanism if U2U
had a different OID.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 16:20:50 -0700

> regular Kerberos are available).

We need a separate OID for explicitly requesting U2U.  We can still use
one OID for normal AP exchanges and KDC-negotiated U2U.  And even if we
don't, we can still use a single spec with two OIDs.  I'd prefer to have
a single spec.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Sep 2003 13:39:20 +0200 (MET DST)

> don't, we can still use a single spec with two OIDs.  I'd prefer to have

I don't know whether everyone is aware of this, but a seperate mechanism
OID is a real pain and should be avoided whenever possible.
I'm pretty convinced that it can be avoided.
A seperate mechanism OID will require consistent use of that seperate
mechanism OID on all gssapi calls and on all Kerberos tokens.

Also for portable applications there should be a possibility to
configure the gssapi mechanism locally so that u2u gets preferred,
the application will not play lottery with mechanism OIDs, it just
wants a security context established, period.  The preference
of u2u over regular kerberos is a policy issue of the admin,
the application writer in general doesn't care the slightest.

The more often that you invent new mechanism OIDs, the more often
you will have problems with legacy apps that have been trained to
request those particular mechanism OIDs.  There already is such
a problem with the pre-rfc1964 mechanism OID vs the rfc1964 mechanism OID,
and each new mechanism OID will create a problem for today's
applications tomorrow.

-Martin