Subject: RE: Do we have any consensus on the 8003 checksum--text follows this line--

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 10 Sep 2003 15:04:08 -0700

Sam Hartman wrote:
>> So, I'm with Nico--it's OK to use such an extension only if we plan
to
>> adopt it for Kerberos in general.  ANd I remind people of Ken's
point:
>> it is very unfortunate if we end up adopting a slightly different
>> actual extension mechanism for ap-rep.  I.E. using an extensions
>> ap-rep is OK; using something between clarifications and extensions
is
>> not.

When we have the message in pieces, one of which is an AP_REP, such as
the one Nicolas proposed earlier, we need to have a separate MIC against
the already encrypted data to bind the pieces together.  This is
something that I see as less desirable.  We can avoid that if the server
always asserts a subkey, however.

Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, September 10, 2003 2:04 PM
To: Liqiang(Larry) Zhu
Cc: Jeffrey Hutzelman; [email-masked]
Subject: Re: Do we have any consensus on the 8003 checksum--text follows
this line--

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, Sep 08, 2003 at 09:55:49AM -0700, Liqiang(Larry)
    Nicolas> Zhu wrote:
    >> I include a summary for the offline discussion with Nicolas.

    Nicolas> Note: I oppose extending Kerberos V types for the
    Nicolas> mechanism, but if we commit to carry such extensions
    Nicolas> forward to the Kerberos V extensions work, I could be
    Nicolas> convinced to go along.

So, I'm with Nico--it's OK to use such an extension only if we plan to
adopt it for Kerberos in general.  ANd I remind people of Ken's point:
it is very unfortunate if we end up adopting a slightly different
actual extension mechanism for ap-rep.  I.E. using an extensions
ap-rep is OK; using something between clarifications and extensions is
not.

Also, I question whether the GSSAPI optional token features are really
protocol elements at the Kerberos level.  Applications should not use
the typed holes in Kerberos as a substitute for protocol design.
I.E. if I were doing GSSAPI today, the 8003 checksum should not go in
the authenticator at all.

I could go either way on the second point--I'm fairly certain the
GSSAPI data elements are not  Kerberos protocol elements, but we're
already committing that sin.  

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 10 Sep 2003 15:15:12 -0700

> always asserts a subkey, however.

I don't object to the context token typed hole being outside the AP-REP
(or AP-REQ for that matter) nor do I object to the MIC of that and the
AP message.

I do wonder if we will ever need confidentiality protection for future
items to be put into the context token typed hole - I think that we
won't (and that if we ever do then we can always use wrap tokens to wrap
the individual items that need conf protection).

At any rate, I'll write up a proposal for a generic context token that
has an extensible CHOICE of AP-REQ, AP-REP and KRB-ERROR, the idea being
that we can later add a request for a TGT and a Ticket to the CHOICE so
we can implement user-2-user with the same mech design, though we may
want to use different mechanism OIDs for u2u.  And if we add a NULL to
the CHOICE we can also get a 1 1/2 round-trip mechanism so we can safely
avoid using a replay cache on the acceptor side, also w/ a different
OID and/or perhaps with an acceptor option to force the initiator to do
the extra 1/2 round-trip.

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

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Sep 2003 18:22:32 +0200 (MET DST)

> mechanism (with or without a different OID - I'm talking about the mech

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

I had the impression that u2u was not a deliberate choice but a
requirement based on the particular situation and *NO* alternative
to regular Kerberos authentication (putting IAKERB aside).

So the application says it wants to use Kerberos, but the Kerberos
implementation decides that it can only succeed with u2u;
a distinction that a (portable gssapi-based) application
doesn't care about.

Unfortunately the decision whether to use a single mechanism OID
or a new mechanism OID for u2u will prevent that the error will
pop up at the acceptor (server) side if the server gssapi implementation
doesn't support this new feature and that the error message may
be confusing to application and user or get lost altogether.

gss_accept_sec_context() will fail with either GSS_S_BAD_MECH in
the new-mechanism-OID case, and it's quite likely that this error
message will NOT get propagated back to the initiator/client
at the application level (unprotected, there is no gssapi context
available).  However a GSS_S_BAD_MECH might easily be misinterpreted
that Kerberos is not at all supported at the acceptor side...

In the single-mechanism OID case the acceptor will get GSS_S_FAILURE
or GSS_S_DEFECTIVE_TOKEN returned from gss_accept_sec_context(),
(hopefully with a meaningful minor error code).  Similarily this
error might not get propagated back to the initiator, no matter
how helpful it might be.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 09:29:04 -0700

> that recognize the rfc-1964 mechanim OID but not the new one.

Yeah, I'd like a single OID as well.  Which pretty much answers the
question of whether the new mechanism spec should cover user-2-user (and
the answer is "yes").

> to regular Kerberos authentication (putting IAKERB aside).

Correct.

> a distinction that a (portable gssapi-based) application

Correct.

[...]
> error might not get propagated back to the initiator, no matter

This shouldn't happen - not if we cover user-2-user in the new mech
spec.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Sep 2003 20:44:12 +0200 (MET DST)

> This shouldn't happen - not if we cover user-2-user in the new mech

I meant this for the situation with a single mechanism OID where
the acceptor still uses and plain old rfc-1964 implementation
and doesn't understand the initiators request.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 12:23:36 -0700

> and doesn't understand the initiators request.

Well, yes, but, we are discussing the new mechanism here.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Sep 2003 17:33:29 -0400

>>>>> "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: Sam Hartman <[email-masked]>
Date: Thu, 11 Sep 2003 17:36:27 -0400

>> requirement based on the particular situation and *NO*
    >> alternative to regular Kerberos authentication (putting IAKERB
    >> aside).

    Nicolas> Correct.

Not at all.  There are situations where both U2U and standard Kerberos
are available as well as situations where only one of the two options
is avialable.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 14:51:17 -0700

> where U2U needs to be used even when a principal can sometimes act as

I think u2u can be done with one OID for cases where the KDC returns the
relevant error.

For cases where the initiator application desires the use of u2u we need
a way for the initiator to request u2u - either a new OID or a new GSS
flag.  (I know, mech-specific GSS flags would not be good to have, so
it'd better be generic, which I'm not sure we can get, so a new OID
it'll likely be.)

For cases where the acceptor application wants only u2u we can only use
a new OID to specify this (since there's no req_flags parameter to
GSS_Accept_sec_context()).

So we do need a new OID for cases where the application wants to insist
on u2u.

But the same old OID could be used for cases where a Kerberos u2u
exchange is negotiated [at the KDC exchange].

> Also, making U2U be the same OID requires that everyone support U2U.

Well, we can do u2u with the same OID with the new mech, if we specify
how.  We _can't_ do the same with the old mech.  Which means that where
old Kerberos V (pre-extensions) is used with old Kerberos enctypes
(pre-kcrypto) we can't do negotiated Kerberos V u2u with the Kerberos
mechanism OID (rfc1964).  Not a big deal.

I think it would be good to allow Kerberos u2u to be negotiated [at the
TGS exchange] for the new mechanism with the same OID as non-u2u.

But I note that one could implement the mechglue and mechanisms such
that initiator applications that use the default mechanism[*] will
negotiate u2u correctly, so support for u2u with the Kerberos mech OID
is not something we MUST have (MS may well disagree though).

[*]  Apps that call GSS_Init_sec_context() with GSS_NULL_OID for the
     desired_mech and GSS_C_NO_CREDENTIAL, or a credential acquired with
     GSS_Acquire_cred() and GSS_C_NULL_OID_SET (or the OID set returned
     by GSS_Indicate_mechs()) for the desired_mechs (or a credential
     acquired with a multiple calls to GSS_Add_cred(), one per-OID
     indicated by GSS_Indicate_mechs()), for the claimant_cred_handle.
     Similarly on the acceptor side, except that there is no
     desired_mech parameter for GSS_Accept_sec_context().

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 14:52:32 -0700

> are available as well as situations where only one of the two options

I stand corrected.  But u2u can be negotiated in the KDC exchange, which
I think is what Martin was referring to.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Sep 2003 19:44:15 +0200 (MET DST)

> where U2U needs to be used even when a principal can sometimes act as

One possibility for negotiating U2U would be to allocate a context
attribute flag for this purpose and use that.  That would be the
most compatible approach that should give you the best interoperability
with the installed base of rfc-1964.  Remember, the installed base
will choke on a new mechanism OID and might not recognize SPNEGO either.

> I think MIT would be much faster to implement this mechanism if U2U

Not at all!
Keeping the existing mechanism OID means that you MUST be fully
interoperable with the installed base of rfc-1964.  New features
of rfc1964 are purely optional.

If you want to add new features as mandatory, then this will be
backward incompatible to the installed base of rfc1964 and you'll
have to use an entirely different OID everywhere anyways.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Sep 2003 12:00:06 -0700

> will choke on a new mechanism OID and might not recognize SPNEGO either.

Yes, but that means adding a rather mechanism-specific flag to the
GSS-API - probably a non-starter.

> of rfc1964 are purely optional.

Again, we're talking about the new mechanism, and we have a method for
negotiating which mech is used - U2U interop w/ rfc1964 is, well, not.

> have to use an entirely different OID everywhere anyways.

See above.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Sep 2003 15:21:28 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, Sep 11, 2003 at 05:36:27PM -0400, Sam Hartman
    Nicolas> wrote:
    >> >> I had the impression that u2u was not a deliberate choice
    >> but a >> requirement based on the particular situation and *NO*
    >> >> alternative to regular Kerberos authentication (putting
    >> IAKERB >> aside).
    >> 
    Nicolas> Correct.
    >>  Not at all.  There are situations where both U2U and standard
    >> Kerberos are available as well as situations where only one of
    >> the two options is avialable.

    Nicolas> I stand corrected.  But u2u can be negotiated in the KDC
    Nicolas> exchange, which I think is what Martin was referring to.

I actually believe thinking of it that way would be abusing the KDC
exchange.  The KDC can return an error indicating that it would have
issued a u2u ticket but would not issue a non-u2u ticket.  That error
can be used by a client in deciding which mechanism to use, but does
not count as KDC negotiation.