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

[Greg Hudson <[e-mail]>]

On 3/11/19 4:05 PM, Nico Williams wrote:
>    If the application provided channel bindings, and channel binding
>    succeeded, then the mechanism MUST include GSS_C_CHANNEL_BOUND_FLAG
>    in the ret_flags.

MUST for accept_sec_context and MAY for init_sec_context, I assume.
(Since existing mech protocols don't provide CB confirmation, and CB
confirmation is typically impossible when mutual auth isn't used.)
>    If the application did not provide channel bindings, but the peer
>    did, then the mechanism may or may not fail security context
>    establishment, but if it succeeds, it MUST NOT indicate the
>    GSS_C_CHANNEL_BOUND_FLAG ret_flag to either peer.
> 
>    If both peer applications provided channel bindings and channel
>    binding failed, then a mechanism MAY fail to establish a security
>    context, but if it permits the context to establish, then it MUST NOT
>    set GSS_C_CHANNEL_BOUND_FLAG in the ret_flags.

My first concern is that this provides no meaningful promises to the
application about how accept_sec_context() will be affected by channel
bindings.  It might or might not cause failure on mismatched bindings
and it might or might not cause failure if the initiator provides no
bindings.  We could add mechanism attributes to distinguish, but that
unfortunately only helps if the acceptor is limited to one or a few
mechs (none of which is SPNEGO), since the choice to supply bindings
comes before we know the mechanism of the initiator token.

My second concern is that if an acceptor application does not see the
channel-bound ret_flag, it cannot distinguish between mismatched
bindings, a lack of bindings from the initiator, or an old
implementation.  (Knowledge of the mech implementation might rule out
some of those possibilities.)

If the goal is to allow applications, whose protocols can optionally use
gss_wrap(), to save some CPU cycles when channel bindings succeed, this
might be good enough--though in many cases admins would have to decide
whether to supply channel bindings based on knowledge they shouldn't
need to have.  I'm not sure if this is a worthwhile goal--do we know of
any specific applications which would benefit?

If the goal is to achieve defense-in-depth against MITM attacks when TLS
security fails, for protocols which never use gss_wrap() and at the cost
of disallowing proxies, then these semantics don't seem likely to
achieve the goal.