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

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

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: Martin Rex <[email-masked]>
Date: Wed, 3 Dec 2003 17:16:18 +0100 (MET)

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

> extension negotiation information". Could it convey some buffer size

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: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 17:05:23 -0500

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

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

GSSAPI has never done this at the mechanism level.

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

No, not really.

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

The initiator can convey support for options using flags.

If the initiator wants to use a mechanism that is not backward
compatible, it uses a different token ID and deals with an extra round
trip if it has to fall back.