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 16:30:21 -0700

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

According to the Mike Swift and John Brezak draft for user2user, two
TOK_IDs are assigned to the user2user messages: 04 00 for TGT_REQUEST
and 04 01 for TGT_REPLY.  Our GSSAPI/user2user implementation follows
this draft and it is shipped since windows 2000.   On windows server
2003, we went one step further to allow KDCs to enforce user2user for
user accounts if configured.

Let me know if you need a copy of this draft. 

Larry

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

On Wed, Sep 10, 2003 at 03:04:08PM -0700, Liqiang(Larry) Zhu wrote:
> 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.

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: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 09:24:37 -0700

> Let me know if you need a copy of this draft. 

You misunderstood my question, which I'll re-phrase as follows:

Would you like the new Kerberos V GSS-API mechanism to describe how to
do user-2-user?

I would.  So I'll propose a single context token design which
facilitates user-2-user, something like (preview):

<OID wrapper, tok_id, <DER encoding of KerberosVMechCtxToken>}

-- explicit tagging environment
MIC  ::= OCTECT STRING

KerberosVMechCtxToken ::= SEQUENCE {
    token-body      [0] KerberosVMechCtxToken-BODY,
    token-body-mic  [1] MIC OPTIONAL, -- MIC of token-body TLV encoding
    ...
}

KerberosVMechCtxToken-BODY ::= SEQUENCE OF {
    kerberos-pdu    [0] CHOICE {
        [0] AP-REQ,
        [1] AP-REP,
        [2] KRB-ERROR,
        [3] Ticket, -- TGT, for user-2-user
        [4] NULL,   -- TGT request for user-2-user (should this be a
                    -- principal and realm name instead of NULL?)

        [5] NULL,   -- For last token of extra 1/2 round-trip mech
                    -- option, which allows the acceptor to forgo
                    -- the replay cache.  Requires an associated
                    -- item in the intial token's mech-options.
        ...
    }
    mech-flags      [1] BIT SRTING { ... },
    mech-options    [2] SEQUENCE OF SEQUENCE {
        opt-type         [0] Int32,
        opt-critical     [1] BOOLEAN DEFAULT FALSE,
        opt-data         [2] OCTET STRING,
        ...
    }
    prev-token-mic  [3] MIC OPTIONAL -- MIC of previous token's body
    -- 
    -- The KRB-CRED for credential delegation would be a mech option.
    -- 
    ...
}

We may have to use different OIDs to indicate the use of user-2-user or
to indicate the use of the extra 1/2 round-trip option (which allows the
acceptor to eschew the replay cache)

Cheers,

Nico
--