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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 2 Dec 2003 16:19:27 -0800

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.

It is possible, however, to change the delegation length field if the
KDC understands "newer enctyes", and in that case only. Is it worth the
trouble given the size of TGTs is unlikely to exceed 64k in any
foreseeable future?

Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2003 3:38 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 03:37:30PM -0800, Liqiang(Larry) Zhu wrote:
> Douglas E. Engert wrote:
> >> The Dlgth field in the checksum is only two bytes long. This may be
> to 
> >> small should it be 4 bytes? 
> >>
> 
> The PAC in TGTs does not contain resource groups and it is compressed
> correctly since windows 2000 gold, thus the 64K of the ticket size can
> contain 1024 domain global groups (the max group # supported by MS)
plus
> up to roughly 1400 SIDs of history or universal groups in extra SIDs.
> For all practical purposes, the 64k limit here is sufficient.  

But surely changing that size field to be four octets can't hurt...

> >> 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.
> 
> This is the SSPI toke size that contains resource groups; this is
> usually significantly larger than that of delegation TGTs.
> 
> If we can afford it, I would not mind making the delegation length
field
> 4 bytes long, but such seemly benign change would break
interoperability
> with existing implementations, particularly the initial context
> establishment token. 

Er, no implementations of CFX have shipped, right?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Dec 2003 22:42:28 -0800

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

> KDC understands "newer enctyes", and in that case only.

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

>                                                         Is it worth the

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: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 21:09:46 -0500

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