GS2 open issues (was: Re: WG Review: GSSAPI and GS2 I-D)

[Simon Josefsson <jas@xxxxxxxxxxx>]

"Kurt D. Zeilenga" <Kurt@xxxxxxxxxxxx> writes:

> The editors have revised these two works.  Please review
> and comment on them during the next week or so.  This
> should allow the editors to revise again before IETF#65.

As for GS2, the primary open issue is how GSS-API channel bindings
relate to the GS2 channel bindings.  See my previous post:

http://article.gmane.org/gmane.ietf.sasl/2222

I'm trying to translate my discussion into options that we can chose
from below.

["channel_binding_data" refer to the channel binding set in the Wrap
token, " chan_binding" to the channel binding as input to the GSS-API
context functions.]

1) There is just one channel binding concept.  The application will
   have to put exactly the same data into "channel_binding_data" and
   "chan_binding".

   This will lead to a security consideration that the GS2 mechanism
   may expose the channel binding in the clear.

2) There are two channel bindings concepts, and they are orthogonal.
   Applications may set "chan_binding" (GSS-API cb) on a
   per-application need, and the "channel_binding_data" (GS2 cb) will
   have to be defined for, e.g., TLS.

   Having "chan_binding" be application-specified seem problematic to
   me.  There is little interoperability in that.  However, it may
   solve some problems.

2a) The "chan_binding" field MUST be NULL.  In other words, for GS2
    interop we disallow the GSS-API cb completely, and only support a
    GS2 cb.

3) There are two channel bindings concepts, but they are related.
   The GS2 cb data field is included within the GSS-API cb field.

   This would permit the most flexibility while continuing to use the
   GSS-API cb fields.  It has the same interop problems as 2.

4) There are two channel bindings concepts, but they are related.
   The GSS-API cb is included within the GS2 cb.

   This is similar to 3, but has some different security properties.
   It seems this may end up including the initiator/acceptor addresses
   in the data protected by the Wrap token.

There is also another orthogonal issue:

A) Define channel bindings for GSS-API used over TLS [through GS2].  I
   believe this would be a critical document, which should be
   normative for GS2.  It is not useful to move GS2 forward if we
   haven't agreed what the channel binding for GS2 over TLS should
   look like.  I couldn't implement GS2 without such a document.

   I believe we should use the TLS PRF to derive a GS2 channel binding
   string.

I will attempt to publish a straw-man solution for A before the I-D
cut-off, unless someone has a better suggestion.

Thanks.