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

[Jeffrey Hutzelman <[e-mail]>]

--On Wednesday, April 01, 2009 12:20:06 PM +0300 canetti 
<[e-mail]> 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.
>
>
> 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.)

Since it's the only one that applies to implementatios, I assume you're 
referring to the requirement that, when bindings of the GSS-API to a 
particular programming language model channel bindings as octet strings, 
the input be treated as corresponding only to the application-data portion 
of the channel bindings structure rather than some (unspecified) encoding 
of the channel bindings structure.

This requirement is needed for interoperability.  GSS-API mechanisms 
supporting channel bindings are responsible for checking that the channel 
bindings claimed by the initiator and acceptor are the same, and failing 
the authentication process otherwise.  This is typically done by 
transferring an integrity-protected copy of the channel bindings data or a 
hash thereof.  Naturally, for this to work it is important that when the 
channel bindings are actually the same, so are the data strings used by the 
mechanism implementations at both ends.  More generally, it is important 
that for any given set of channel binding data, the data string used to 
represent that data by any given mechanism always be the same.

This is accomplished at three layers...

- By defining abstract interfaces between GSS-API applications and the
  GSS-API framework or mechanism, including what information about channel
  bindings must be passed down.  This is done in RFC2743, updated and
  clarified by the present document.

- By defining concrete bindings to the abstract interfaces in various
  specific programming languages.  This is done in RFC2744 for C, and
  by RFC2853 (to be updated by a current KITTEN document) for Java.

- By defining, for each mechanism, the procedure for transforming the
  abstract channel binding information into a particular octet string
  used to verify channel bindings on the wire.


What the present requirement is about is insuring that, when the concrete 
bindings for a particular language provide only for a single octet string 
rather than for all of the elements in the GSS-CHANNEL-BINDINGS structure, 
the interpretation of that octet string is consistent from one 
implementation to the next.


Note that this is not a change to the API; it is a clarification which 
improves interoperability by requiring all implementations of an ambiguous 
API to resolve the ambiguity in the same way.

-- Jeff