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

[[e-mail] (Martin Rex)]

Just a quick comment, I haven't been following IETF work for months...

Sam Hartman <[e-mail]> wrote:
> 
> This draft is based on the premis that the GSS-API channel binding
> behavior is flawed and that  there's a security problem associated with
> not knowing if channel bindings are validated.

Frankly, the whole idea of channel bindings is thoroughly flawed,
and it _can_not_possibly_work_ whenever there are any application
level gateways ("proxies") involved in the communication path,
something that is pretty common in non-trivial application,
and in particular in non-trivial backend servers.

If you see someone using channel bindings, you can be pretty sure
that they're doing some kind of seriously stupid abuse of technology.

Whenever the *ENTIRE* application-level data is properly protected
with gss_wrap(conf=TRUE), channel bindings will provide *ZERO*
additional value, while creating a whole bunch of problems.


> 
> I've heard this argument over the years, but never been convinced of it,
> and unfortunately, this draft is filled with assertions of that fact
> without any rationale.

I agree, this is extremely disappointing.
In particular, because a general need is asserted, although just
the opposite is true, for honest and sane usage scenarios,
channel bindings are useless bloat that break application level
proxy traversal.

> 
> At one level it doesn't matter much.  I absolutely agree that a facility
> for knowing if channel bindings are validated would be incredibly useful
> and would simplify application design.

That is what the "ret_flags" could be used for.  There are still a few
free bits left in the 32-bit output value of the rfc2744 C-bindings.


> 
> As I write this up, I'm realizing that the draft authors seem to be
> making an assumption that  there are applications in the wild that pass
> in channel bindings to the initiator but not the acceptor or vise
> versa.  The only such application I'm aware of is gss ftp, which passed
> IP address channel bindings into the acceptor and optionally initiator.

Yes, apparently there are.

The application that I am aware of is Microsoft's proprietary
Hack rfc4559 HTTP Negotiate when used with Kerberos,
where TLS channel bindings are first asserted in Windows Vista (or Win7) ?

But rfc4559 is a crystal clear HACK, which misuses a naked rfc1964/rfc4121
two-token Kerberos authentication as an OTP scheme, and by NOT using
any of the GSS-API message protection facilities for the application data,
there is *NO* binding between the application data in the HTTP request
and the AP_REQ in the rfc4559 HTTP Request header, making that
approach vulnerable to man-in-the-middle attacks (proxying/relaying).

However, if the backend architecture uses a reverse proxy
(Load Balancer / "SSL-Accelerator"), while the HTTP-layer rfc4559 processing
is performed in the backend host (different machine), it is simply not
possible to perform channel binding to the TLS channel (that ended
on the reverse proxy).



>
> It would help me evaluate whether there is a security problem to
> understand these applications better.
> I note that SASL is not such an application.

There is a serious security problem in rfc4559 HTTP negotiate.

Use of TLS channel bindings for rfc4559 is a mitigation to pretend
that the security problem doesn't exist.



> 
> Regardless of whether this is a security problem, I am very supportive
> of a mechanism along these lines.  I think that it would simplify
> application design over the approaches necessary for the gs2 family of
> mechanisms.

-Martin