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

[canetti <[e-mail]>]

Thanks Jeff and Nico for the tutorial. The current specification does seem 
very reasonable.

Best,
Ran

Nicolas Williams wrote:
> 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