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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 3 Dec 2003 18:34:43 -0800

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.

>> If we really think that a 2-byte length field might be a little
>> short for delegated credentials, then a 16 KB limit on protected
>> messages is quite small...

we do not say anything about the size limit for
GSS_Init_sec_context()/GSS_Accept_sec_context tokens.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Wednesday, December 03, 2003 8:16 AM
To: Douglas E. Engert
Cc: [email-masked]
Subject: Re: gssapi-cfx-04.txt section 4.1.1.1 with regard to section
5.2

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. 

Now that is funny.  I never noticed that section, neither in rfc1964
nor in gssapi-cfx.

We do have an interoperability requirement of at least 32 KB
for our application and my GSSTEST tests up to 64 KB.
I don't have a problem with this since we do require several
characteristics that are merely optional in the GSS-API standard
and require interoperability certification in case the customer
wants support when he runs into problems.

How about
"must support 16 KB, should support 64 KB and may support larger sizes"

If we really think that a 2-byte length field might be a little
short for delegated credentials, then a 16 KB limit on protected
messages is quite small...

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

Conceptually there is no upper bounds for the size of protected messages
that an application has to account for in GSS-API. gss_wrap_size_limit()
is specifically to get a prediction on the additional framing in order
to optimally fill a fixed MTU size on a datagram-oriented communication
channel.  GSS-API based apps that use stream-oriented communication do
NOT
expect limits on the protected message size.

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 04 Dec 2003 11:10:45 -0600

> messages are fragmented into pieces first.

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

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.

-- 

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Dec 2003 15:44:31 -0500

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