Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-04

[Greg Hudson <[e-mail]>]

1. Sam suggested that we consider allowing context establishment in the
acceptor-only binding case (i.e. where the acceptor caller provided
channel bindings but the initiator caller did not).  Sam notes that
Moonshot's GSS-EAP implementation allows this, and that policing a
legitimate initiator's decision to provide channel bindings isn't
security-critical in common scenarios.  He nevertheless supports a
mechanism to inform the acceptor whether channel bindings were used.

I discovered recently that Heimdal's krb5 mechanism permits
acceptor-only bindings, if I read the code correctly.  So it may be that
MIT's krb5 mech is unusual in rejecting the acceptor-only bindings case.
 (GNU Shishi's GSS krb5 mech does as well.)

Relaxing implementations to allow acceptor-only bindings solves the
original problem of allowing channel bindings to be introduced at
acceptors when not all initiators provide them.  But without some kind
of signalling, application code can't be certain in advance that it's
running against a relaxed implementation.  A mechanism attribute is the
most robust way to signal this.

2. Nico noted (out of band) that with a relaxed implementation, we can
communicate channel binding state very simply: allocate two ret_flags,
one for "channel bindings were used" and one for "channel bindings were
not used".  If you don't get either flag back, you're running against an
old implementation (or, on the initiator side, the mechanism protocol
doesn't provide confirmation).

In this model, we don't need a ret_flags_understood input to
accept_sec_context, and therefore don't need gss_create_sec_context().

3. Martin argues against channel bindings altogether, on the basis that
they break proxies and that it's better to use a channel security layer
tied to the authentication mechanism.  This viewpoint seems out of step
with the decision not to provide a security layer in SASL GS2.

Practically speaking, the most common underlying secure channel is TLS,
whose server authentication (when the client actually performs it)
prevents MITM attacks in most cases.  It is of some concern that TLS
does not have the same server naming or trust roots as the GSS
mechanism.  I'm not sure that amounts to a pressing need for channel
bindings, but I do see some value in them as a defense-in-depth measure
when it's not desirable to allow proxies.

I don't see much value in endpoint channel bindings.

Separately from all of this, I am a bit concerned that we are fulfilling
a need to upgrade from no-channel-bindings to channel-bindings, but once
an application protocol starts using channel bindings of any type, there
is no practical way to upgrade to a different type of channel bindings
without application-layer signalling.