Re: Security review of draft-ietf-kitten-gssapi-channel-bindings-06

[Nicolas Williams <[e-mail]>]

On Wed, Apr 01, 2009 at 12:20:06PM +0300, canetti wrote:
>   *I have reviewed this document as part of the security directorate's
>   *ongoing effort to review all IETF documents being processed by the
>   *IESG.  These comments were written primarily for the benefit of the
>   *security area directors.  Document editors and WG chairs should treat
>   *these comments just like any other last call comments.

Thanks!

I know that Jeff has already answered this...

> This is a very short document. It describes a more generic way of
> formatting the API for channel bindings. The move to a more generic
> format is welcome. One potential objection here, however, is to the
> requirement that compliant implementations MUST interpret the API as
> having the new format. This may have backwards compatibility issues,
> and for no apparent good reason. It might be better to specify the
> format so that an implementation will be able to take also older API
> formats.  (Since this is not an interoperability or security-sensitive
> issue, there seems to be no reason for the IETF to MANDATE one way
> over another.)

Let's pick a programming language, say, Python, and suppose that the
Python bindings of the GSS-API followed RFC2743 with regards to channel
binding.

An implementation of those bindings AND of the Kerberos V
GSS-API mechanism (RFCs 1964 and 4121) would have to decide how to map
the RFC2743 "OCTET STRING" channel binding input to the mechanism's
channel binding (which is defined in terms of RFC2744's
gss_channel_bindings_struct C struct rather than "OCTET STRING").  Two
implementations of such bindings would fail to interop when using
channel bindings if the implementors decided this matter differently.

Worse, suppose that you had a Python bindings implementation that mapped
the RFC2743 OCTET STRING channel binding input to then initiator_address
field of the RFC2744 gss_channel_bindings_struct C struct.  Then you
could not interop with C implementations of the same application
protocol when using channel binding[*].

IMO the only reasonable decision for the implementors would be to map
the RFC2743 OCTET STRING channel binding input to the RFC2744
application_data field of gss_channel_bindings_struct.  And indeed, this
may require changing some of the putative implementations of the
putative Python bindings of the GSS-API.  I don't see any alternatives.

[*] Only RFC2744 application_data makes sense for channel binding
    nowadays.  Use of network addresses for channel binding was long ago
    abandoned -- think of NATs :( -- and anyways, channel binding
    to cryptographically secure channels makes much sense, while channel
    binding to network addresses does not make much sense at all.

Nico
--