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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 11 Sep 2003 17:00:23 -0700

Nicolas Williams wrote:

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

If you have separate TOK_IDs for each message, including the user2user
messages and AP_REQ and AP_REP etc, we still can make it a single spec. 

We should get a closure on this in the interim meeting.

Larry

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

On Thu, Sep 11, 2003 at 04:21:48PM -0700, Liqiang(Larry) Zhu wrote:
> 
> 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).

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: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 12 Sep 2003 09:10:29 -0700

Martin Rex wrote:
>> Btw. would interoperability with Microsoft's implementation require
that >> the communication peer must have SPNEGO?

The availability of new features and interoperability can be achieved
without SPNEGO.  My initial reaction to this is "no" in that, IIUC, both
flavors are implemented since windows 2000.

You do have a good point as most of our applications do not ask (or
rather, do not know when to ask) for u2u explicitly.

Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, September 12, 2003 4:59 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Do we have any consensus on the 8003 checksum

Liqiang\ wrote:
> >> 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.

Don't close the discussion prematurely and wouldn't like to see
this issue silenced in favour of rubber-stamping Micrsoft's approach.

Btw. would interoperability with Microsoft's implementation require
that the communication peer must have SPNEGO?

If the absence of context_flags input parameter to
gss_accept_sec_context()
is your only concern, then adding a gss_accept_sec_context_ex() with
such a parameter for those applications that do want to play tricks
would be one way to go.

What we would need for a discussion and a reasonable engineering
decision is the exact scenarios that need to be addressed, i.e.

   - is there always a choice for the application for one or
     the other or are there constraints?
     (if there are constraints then this would have to be
      reflected in the availability/absence of the mechanism OID
      and will in general require the application to retry a
      failed GSS-API call when SPNEGO is not available.
      When using a context request flag it would be ok if
      the mechanism did use a fallback when necessary without
      the need to play tricks with OIDs or returning an error
      when the pseudo-mechanism is currently not usable

   - what motivations are there to prefer u2u over TGS/TGS_REP
     or the other way round?

   - if there is a strong motivation to have apps use one over
     the other, how do you solve this for portable applications
     that don't have this new-kerberos-mech meta-knowledge?

-Martin