Subject: gssapi-cfx-04: padding size

From: Ken Raeburn <[email-masked]>
Date: Tue, 02 Dec 2003 17:40:53 -0500

Section 4.2.4 uses the phrase "crypto-system garbage".  I don't really
like the use of the word "garbage" here, and I've said that before,
but if you're going to use it, please rephrase it to indicate more
concisely that that is the term you're defining and using *in this
document*.  As it's phrased, I'd read it to mean that that's the term
for it defined elsewhere (which one would presume to be [KCRYPTO]
except I know that's not the case), and that you're just repeating the
definition for clarity.  Try something like this:

    ...and the extra trailing octets, generally padding added by the
    cryptosystem, we shall call "crypto-system garbage" in this
    document, to distinguish them from padding octets added by this
    GSSAPI mechanism.

Section 4.2.4 says "one can always find the next (possibly larger)
size so that...", but [KCRYPTO] just says that such a size must exist,
and be within a certain range; it doesn't suggest that the smallest
such length has to be easy to find.  That inconsistency is sort of
okay, I guess, since section 4.2.4 doesn't actually say that the
smallest such size has to be used; the third paragraph just requires
that there be no "garbage".  The smallest semantic change to clean
this up would be to rephrase the description in the second paragraph
to say something like:

    ...one can always find a (possibly larger, but by less than 64K)
    size such that, when the message data is padded to that size,
    there will....

Section 5.2 says wrap tokens generated from a 16K octet input must be
handled.  It may be worth noting that the token could include nearly
64K of padding, and thus the token itself may be over 80K.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 2 Dec 2003 20:57:18 -0500

I just ran into some issues with GSS_Wrap_size_limit.

First, the description of the function in section 2.2 of RFC 2743 
("allows a caller to determine the size of a token which will be 
generated by a GSS_Wrap() operation") does not match the operation 
described in section 2.2.7 (which takes the output token size as an 
input argument, and returns the maximum input message size as a 
function output).  Well, maybe if you read "determine" as "choose a 
maximum by finding out from the GSS how to not exceed it" rather than 
"find out the maximum", but that's not how I read it the first several 
times.

Second, I'm trying to clarify something that isn't 100% obvious to me 
from the description in section 2.2.7.  Does GSS_Wrap_size_limit have 
to be applicable to the remote party, or only to the local 
implementation?  I.e., could an application protocol message size 
negotiation be done by feeding a local fixed buffer size into 
GSS_Wrap_size_limit and getting a message size that the other party 
should be told not to exceed, to keep the tokens fitting inside the 
buffer?  Or, turning it around, if I receive a token of a certain size, 
can I find out before unwrapping it the maximum size of the contained 
application data?  If Wrap token size expansion is non-deterministic 
(random size padding allowed, like cfx-04) or implementation-dependent 
for some real or hypothetical mechanism, that could be very difficult...

Ken

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Dec 2003 17:23:58 +0100 (MET)

> "find out the maximum", but that's not how I read it the first several 

As I just wrote in a previous message, GSS_Wrap_size_limit() is
for use by applications that use datagram-oriented communication channels
with a fixed MTU size and want to figure out what the maximum size
of an application data unit may be that still fits the MTU constraints
of the communication channel after having been processed by gss_wrap()

The result of gss_wrap_size_limit() doesn't need to be an exact prediction,
gssapi mechanisms should probably use a simplified calculation with
a small safety margin (1-20 Bytes).

> for some real or hypothetical mechanism, that could be very difficult...

The result of GSS_wrap_size_limit() is a purely local information,
and it is not required to be an exact match.  Two independent implementations
may use independent calculations/predictions with different safety margins.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 13:08:43 -0500

Do we want to require that the minimal padding be used?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 14:47:46 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> The result of GSS_wrap_size_limit() is a purely local
    Martin> information, and it is not required to be an exact match.
    Martin> Two independent implementations may use independent
    Martin> calculations/predictions with different safety margins.

Is this your opinion/understanding, or is there something in the spec
that would allow someone to conclude it is a local matter?

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 03 Dec 2003 19:52:39 -0500

> Do we want to require that the minimal padding be used?

I don't see much point.

Ken

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Dec 2003 15:35:07 +0100 (MET)

> that would allow someone to conclude it is a local matter?

Reality shows that it is implemented as a local matter.

There's nothing in rfc-2743/2744 or rfc-1964 that requires more
accuracy than to fit the goal stated in the description of this
api call in rfc-2744.  The logical conclusion is that it is
a local matter and the current implementation practice of
guesstimating with a safety margin is perfectly OK.

-Martin