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

[Sam Hartman <[e-mail]>]

>>>>> "Sam" == Sam Hartman <[e-mail]> writes:

nnel
    >> bindings to GSS_Accept_sec_context(), and b) not indicated
    >> support for the ret_channel_bound_flag flag, then the mechanism
    >> MUST fail to establish a security context if the initiator did
    >> not provide channel bindings data.  This requirement is critical
    >> for security purposes, to make applications predating this
    >> document secure, and this requirement reflects actual
    >> implementations as deployed.

    Sam> Actually, this behavior is inconsistent with RFC 7055 section
    Sam> 5.6.2 and with the Moonshot implementation of the ABFAB GSS-API
    Sam> mechanism.  In that mechanism, if the initiator provides null
    Sam> channel bindings, the acceptor channel bindings are always
    Sam> ignored.  I'm not seeing the security issue here.  If you are
    Sam> using channel bindings as a MITM defense rather than as an
    Sam> additional layer of security, you need to do something like
    Sam> SASL does and have a plus and minus varient of your protocol
    Sam> and always pass in channel bindings.

    Sam> There's also what I think is a real operational issue here.
    Sam> You may not be able to know what your channel bindings are on
    Sam> an acceptor.  Depending on whether you are behind a TLS
    Sam> accelerator, reverse proxy or the like, it may affect your
    Sam> ability to know your channel bindings.

I meant to go back and revise my review before sending.
I think it's something worth fixing that Kerberos and ABFAB have
inconsistent behavior here, and I do think it's worth standardizing.

I think  we're in a good position.  If we were to decide to relax the
behavior we'd be changing Kerberos in a manner where all authentications
that succeed today would continue to succeed.  Kerberos is much much
much more widely deployed than ABFAB.
If we were to decide to make the behavior as strict as described in this
draft, then we'd be potentially breaking valid uses of ABFAB, but I
think the ABFAB deployment is small enough that it is reasonable to do
that.

However, I think that the decision as to what to do should be based on
analysis of applications where one side uses channel bindings and the
other does not.  Since I'm not actually aware of any significant
applications that do that, I'll hold off until my previous question on
that issue is answered before forming my opinion on the correct
behavior.