Subject: gssapi-cfx-04.txt section 4.1.1 question

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 02 Dec 2003 15:52:54 -0600

The Dlgth field in the checksum is only two bytes long. This may be to small
should it be 4 bytes? 

A recent change in Microsoft was to increase the maximum allowed ticket 
size from 8K to 12K indicting that there are now tickets larger then 8K. 

With all the extensions to tickets, I expect we may see tickets large then 
64K in the future which could not be delegated.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 3 Dec 2003 00:29:26 -0800

Nicolas Williams wrote:
>> There is no trouble.  And yes, no trouble is worth this change.  With

>> future extensions tickets may grow quite large for all we know now.
>> Let's not do the 640KB thing again.

With TE in mind, I will say "yes" to expand the field and it should be
in little endian order (just to be consistent with other fields in the
checksum).

I also realized the CFX negotiation without the assistance from the KDC
can be done with this change.

Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2003 10:42 PM
To: Liqiang(Larry) Zhu
Cc: Douglas E. Engert; Kerberos WG
Subject: Re: gssapi-cfx-04.txt section 4.1.1 question

On Tue, Dec 02, 2003 at 04:19:27PM -0800, Liqiang(Larry) Zhu wrote:
> Nicolas.Williams wrote:
> >> But surely changing that size field to be four octets can't hurt...
> >> Er, no implementations of CFX have shipped, right?
> 
> The task of negotiation (to use CFX) is given to KDCs as suggested by
> this document; if we want to do CFX with down level KDCs (but between
> upper level initiators and acceptors) we need to maintain the same
token
> format in the initial token.

Huh?  No, no.  This is not what we'd agreed to.

Negotiation between CFX and rfc1964 is to be done at the KDC exchanges
or through some other out-of-band mechanism - that was the agreement.
Keeping any CFX tokens interoperably compatible with rfc1964 tokens was
not an explicit goal.

> It is possible, however, to change the delegation length field if the
> KDC understands "newer enctyes", and in that case only.

This is a [partial] restatement of our previous agreement.

>                                                         Is it worth
the
> trouble given the size of TGTs is unlikely to exceed 64k in any
> foreseeable future?

There is no trouble.  And yes, no trouble is worth this change.  With
future extensions tickets may grow quite large for all we know now.
Let's not do the 640KB thing again.

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 5 Dec 2003 02:16:24 -0800

I would not object standardizing it. At Denver, we seemed to agree not
to include it. In any case, shouldn't we leave rooms for extensions to
meet specific needs from vendors? Microsoft certainly has expressed
interest to make this happen.

Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2003 6:10 PM
To: Liqiang(Larry) Zhu
Cc: Douglas E. Engert; Kerberos WG
Subject: Re: gssapi-cfx-04.txt section 4.1.1 question

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

    Nicolas> On Tue, Dec 02, 2003 at 04:19:27PM -0800, Liqiang(Larry)
    Nicolas> Zhu wrote:
    >> Nicolas.Williams wrote: >> But surely changing that size field
    >> to be four octets can't hurt...  >> Er, no implementations of
    >> CFX have shipped, right?
    >> 
    >> The task of negotiation (to use CFX) is given to KDCs as
    >> suggested by this document; if we want to do CFX with down
    >> level KDCs (but between upper level initiators and acceptors)
    >> we need to maintain the same token format in the initial token.

    Nicolas> Huh?  No, no.  This is not what we'd agreed to.

Well, it's more like Microsoft informed us that they would be doing
this whether we liked it or not.  At least that's how I read the
discussion.

we decided to keep the same initial context token to avoid introducing
more code paths.