Subject: RE: gssapi-cfx-04.txt section 4.1.1.1 with regard to section 5.2

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

Douglas E. Engert wrote:
>> Section 5.2 says 16K buffers must be supported, and larger sizes
>> are optional. But I don't see how to negotiate a larger size.

Unfortunately, this is done via out of band mechanisms, perhaps via SASL
in the upper layer.

>> If 4.1.1.1 is really for "extension negotiation" how is negotiation
>> actually done? It currently looks like more informational then
anything
>> because the only response on the part of the acceptor is to return an

>> error.    

You are correct we do not provide an example how to negotiate an
extension or an option.

If I stretch a bit, the last paragraph in section 4.1 gives an example
of negotiation and it is done, ironically, by returning an error
message.

Also, the negotiation of CFX when the KDC does not understand newer
enctypes is another instance where the acceptor indicates it understands
the CFX mechanism by asserting a subkey in AES.

We discussed earlier about introducing more generic negotiation
framework, including considerations of critical and non critical
extensions. We were afraid it would delay the GSS-CFX draft, which is
badly needed.  My understanding is that this should be addressed by the
future extension draft.

Thx, Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Douglas E.
Engert
Sent: Tuesday, December 02, 2003 2:16 PM
To: Kerberos WG
Subject: gssapi-cfx-04.txt section 4.1.1.1 with regard to section 5.2 

Section 5.2 says 16K buffers must be supported, and larger sizes
are optional. But I don't see how to negotiate a larger size. 

Section 4.1.1.1 says it is "used to convey service options or 
extension negotiation information". Could it convey some buffer size
as well? 

If 4.1.1.1 is really for "extension negotiation" how is negotiation
actually done? It currently looks like more informational then anything
because the only response on the part of the acceptor is to return an
error.    

-- 

 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: Fri, 5 Dec 2003 01:52:17 -0800

The recommended buffer size is more of expectation than what
implementations really do today. 64k should buy us more time moving into
the future (that is an increment by a factor of 4).

I agree with Doug, the average message size is bounded to increase over
time.

Doug Wrote:
> But if what is driving adding this limit in this document is that 
> applications using SSPI need to get buffers of some size, then this is
an 
> application negotiation problem, and if the applications want to
negotiate 
> a larger buffer sizes then 16K this protocol should not restrict it. 

> I like Martin's text or something that does not limit the size to such

> small buffers. 

> If you need some limits, please consider adding a buffer size to the 
> checksum fields so the initiator can tell the acceptor the max size
buffer > it will use. Unfortunately the GSS-API only has the
gss_wrap_size_limit to > get a clue as to what the implementation is
using. So interoperability 
> between an application using SSPI and one using GSSAPI is problematic.

I am fine to go ahead with Martin's text.

This limit was inherited from 1964, it did not come from SSPI (as far as
I know).

Martin, I have you read your earlier messages, and thanks, SSPI does not
have any limit for this either (ok, to be politically correct, it does
not have this limit for all practical purposes: you might have a problem
if the length is more than 4G since a 32 bit integer is used to encode
the length in the descriptor but that is it). I do not know exactly why
this limit was stated in rfc 1964 but I assume it is good to make the
input message size bounded, just with common sense.

GSS-API is not aware of the stream oriented communication channel,
right? Do you know any GSSAPI mechanism that takes advantage of the
fragmentation and re-assembly you described (other than the MS SSL
implementation, which never claims to be a GSSAPI mechanism).

Thx,

Larry

-----Original Message----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Thursday, December 04, 2003 12:45 PM
To: Douglas E. Engert
Cc: Liqiang(Larry) Zhu; [email-masked]; [email-masked]
Subject: Re: gssapi-cfx-04.txt section 4.1.1.1 with regard to section
5.2

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> "Liqiang(Larry) Zhu" wrote:
    >> 
    >> Martin Rex wrote:
    >> >> How about >> "must support 16 KB, should support 64 KB and
    >> may support larger sizes"
    >> 
    >> Have anybody else feel the need to change it to this way?  I
    >> have the impression that most app messages are smaller than 16k
    >> and the large messages are fragmented into pieces first.

    Douglas> That may be what you are seeing today. But not
    Douglas> necessarily in the future, with higher speed networks,
    Douglas> faster processors, and more memory.  the GSS-API does not
    Douglas> impose any restriction on the length.

Right, and most hosted implementations will support huge messages.
Heimdal, MIT and Microsoft do this; I suspect the GNU implementation
will as well.

But if you are in a restricted environment, you want some limit.