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

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

Nicolas Williams wrote:
>> 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>}

I could not see the value by having both TOK_IDs and choice TAGs.  

We would prefer to proceed with the existing TOK_IDs; at least it is
more consistent with the per-message tokens.

I do not see it as a huge problem using typed holes for the Kerberos 5
GSSAPI mechanism, although it is less desirable from the abstraction
point of view.  If we can live with that, we can just wait for the
extension work. You argued that the resulting Kerberos messages might
have some GSS flavor, but how would that present a problem?

I think getting GSSAPI/AES support out of the door quicker is more
important, especially when we do not even have an example (I refuted the
example you quoted earlier) to make these changes.

Thanks, 
   
Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, September 11, 2003 9:25 AM
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 04:30:21PM -0700, Liqiang(Larry) Zhu wrote:
> 
> 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. 

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

---

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

> I could not see the value by having both TOK_IDs and choice TAGs.  

I did not say there'd be multiple tok_ids.  I am proposing a single
token ID and that CHOICE.

> more consistent with the per-message tokens.

I don't care for keeping the rfc1964 context tokens and Sam has
convinced me that it's best not to rely on typed holes in the Kerberos
messages to get what we need in the context tokens.

> example you quoted earlier) to make these changes.

We won't reach consensus on all the mech issues until next week at the
earliest.  I expect that we'll talk about this in the hall next week.

We still have to decide prot_ready and subkey issues too.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Sep 2003 14:11:44 -0400

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> I do not see it as a huge problem using typed
    Liqiang(Larry)> holes for the Kerberos 5 GSSAPI mechanism,
    Liqiang(Larry)> although it is less desirable from the abstraction
    Liqiang(Larry)> point of view.  If we can live with that, we can
    Liqiang(Larry)> just wait for the extension work. 

This means that we can never extend GSSAPI between two clarifications
peers.  Are we willing to live with that?