Subject: Channel binding hashing in draft-ietf-krb-wg-gssapi-cfx-05

From: Simon Josefsson <[email-masked]>
Date: Wed, 28 Jan 2004 18:39:44 +0100

The description of how channel bindings are hashed can be improved.
Without help from the authors, I didn't know which of two possible
interpretations was the intended one.  I suggest incorporating the
following modifications.  Opinions?

OLD:

   (1) Each integer field shall be formatted into four octets, using
   little endian octet ordering, for purposes of MD5 hash computation.

NEW:

   (1) Each integer field and input length field shall be formatted
                         ^^^^^^^^^^^^^^^^^^^^^^^
   into four octets, using little endian octet ordering, for purposes
   of MD5 hash computation.

ADD (to end of 4.1.1.2):

   If the application supply, in the channel binding, a buffer with a
   length field larger than 4294967295 (i.e., the limit of what can be
   represented in the 4 octets available) the implementation of this
   mechanism MAY chose to reject the channel bindings altogether,
   using GSS_S_BAD_BINDINGS.  In any case, the size of channel binding
   data buffers that (interoperable, without extensions) can be used
   with this specification is limited to 4294967295 octets.

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Jan 2004 13:12:28 -0600

>    (1) Each integer field and input length field shall be formatted

The buffer length fields are integers, thus this would be redundant.

>    with this specification is limited to 4294967295 octets.

This too is implicit from the above, but, that said, it's worth
mentioning that implementations are free to set channel bindings buffer
size limits at much less than 2^32 octets and that they must return
GSS_S_BAD_BINDINGS when presented with channel bindings buffers larger
than the implementation's limits.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Jan 2004 17:56:07 -0600

On Fri, Jan 30, 2004 at 12:37:03AM +0100, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> 
> It is redundant if you know buffer lengths are to be regarded as
> integers, which is what I thought wasn't obvious, and that I believe
> my proposed text would make clear.  Buffer lengths are not explicit in
> the core GSS-API, nor in some language bindings such as Java.

But this draft explicitly references rfc2744 (GSS-API C-Bindings), as it
has to.

Yes, that's ugly, but that's because rfc2743 did not define the
structure of channel bindings and left the task to rfc2744 which defines
it in terms of C, so now every mechanism that supports channel bindings
has to reference rfc2744 and all other language bindings of the GSS-API
have to use a channel bindings representation that maps onto rfc2744's.

Now, given this it's clear then that the buffer lengths are integers
because that's how rfc2744 models them.

I don't oppose a clarification if you'd find it useful however -- I'm
merely pointing out that this is not a flaw in this I-D and the change
you propose should not hold up the CFX I-D.

>                                                                That
> buffer lengths are to be considered as integers may be inferred, if
> you are looking at the GSS C bindings where the buffer length field is
> explicit in the definition of gss_buffer_desc, though.

Correct.  RFC2744 is a normative reference of CFX.

>                                                         I'm assuming
> that gssapi-cfx does not presuppose that the C language GSS bindings
> are used.

Wrong, sort of.  See above, and below for the ugly details :/

Neither CFX nor rfc1964 actually restrict the use of channel bindings to
C applications nor do they specify a need to convert channel bindings
into gss_channel_bindings_struct form, but because rfc2744 is _the_
authority on the structure of GSS-API channel bindings both CFX and
rfc1964 have to specify how they use channel bindings in terms of the
rfc2744 gss_channel_bindings_struct structure.

>            Thus, referring to "integers fields" only suggested (to me)
> the two integers mentioned in the section, i.e., the two address type
> fields.  Also compare the Java GSS bindings, the address type integers
> aren't explicit.

The reason for referencing gss_channel_bindings_struct in CFX and the
reference to "integer fields" should now be clear.  Painkillers may be
in order however :/

> The limit is a mechanism specific protocol limit, not an application
> nor core GSS-API limit.  Even if my system and implementation support
> channel bindings of lengths larger than 2^32-1, which the core GSS
> specification handle fine, this GSS-API mechanism doesn't allow this
> to be represented in any way.  Thus I believe it is prudent to mention
> this.  However, I agree with you that suggesting that implementations
> may reject channel bindings at any length they chose could be useful.

As in section 5.2 of CFX, which really ought to apply to the channel
bindings buffers as well and may have to be modified to explicitly do
so.

> But I believe that recommendation would be orthogonal to the mechanism
> specific protocol limit of 2^32-1 discussed above.  I don't care
> strongly about your recommendation, so I leave proposing text for it
> to someone who does.

The mechanism's theoretical maximum of 2^32 octets for the various
channel bindings buffers should be clear from the text that says "[each]
integer field shall be formatted into four octets ..." and the normative
reference to rfc2744.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Jan 2004 17:57:44 -0600

On Thu, Jan 29, 2004 at 01:10:53PM -0500, Sam Hartman wrote:
> I don't see a problem with the proposed clarification.

I don't either, if Simon still thinks it's needed.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 30 Jan 2004 00:37:03 +0100

It is redundant if you know buffer lengths are to be regarded as
integers, which is what I thought wasn't obvious, and that I believe
my proposed text would make clear.  Buffer lengths are not explicit in
the core GSS-API, nor in some language bindings such as Java.  That
buffer lengths are to be considered as integers may be inferred, if
you are looking at the GSS C bindings where the buffer length field is
explicit in the definition of gss_buffer_desc, though.  I'm assuming
that gssapi-cfx does not presuppose that the C language GSS bindings
are used.  Thus, referring to "integers fields" only suggested (to me)
the two integers mentioned in the section, i.e., the two address type
fields.  Also compare the Java GSS bindings, the address type integers
aren't explicit.

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Jan 2004 13:10:53 -0500