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

[Sam Hartman <[e-mail]>]

>>>>> "Nico" == Nico Williams <[e-mail]> writes:


    >> 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.

    Nico> It's only flawed if you'd like to start using CB in
    Nico> applications that lack a negotiation for it.  Modifying
    Nico> application protocols is non-trivial.

How about.
"GSS-APi does not provide a mechanism to add channel bindings to
applications without adding a negotiation mechanism to determine when
channel bindings can be relied on.
This draft adds such a mechanism?
"

I'd avoid the word flaw in such a case, but don't care that much about
the text.  What I do care about is that I now understand what you're
trying to do, and I'm really happy about that.  I support the goal, with
some caviats I'll discuss below.


    >> However, by jumping to the conclusion that we're fixing a flaw, I
    >> think we approach interoperability and operational aspects with
    >> inadequate thought.  I think we discard some of the options too
    >> early.
    >> 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.  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.

    Nico> I believe IWA is such an application...

I'm not familiar with that application.
Pointer?

    >> I think the current draft has several shortcomings:
    >> 
    >> * I think that it inaccurately describes what RFC 2743 says and
    >> so it does not call out backward incompatible changes.

    Nico> There should be no backwards-incompatible changes.

I listed one later in my review.
In particular, RFC 2743 permits a mechanism to entirely ignore CB.  This
draft requires that if an initiator passes in channel bindings without
the new flag, then CB fails.
I think that is not required by RFC 2743.  As such, this makes legal
mechanisms under 2743 into non-compliant mechanisms and thus is a
backward compatible change.

    Nico> I am open to re-designing this extension.

    >> * I think that more consideration needs to be given to situations
    >> where one side supports the channel bound flag and the other does
    >> not and what if any signaling changes are required.

    Nico> We might want to extend the Kebreros mechanism to provide
    Nico> signalling about this from the acceptor to the initiator.

    Nico> That could be done in a separate I-D.

When I read the current draft it's not clear to me which sides get the
flag set and who knows CB has succeeded.  One advantage to adding
Kerberos signaling here or in a normative dependency is that we could
give both sides of the conversation info about whether CB has succeeded.

I think the current draft is too silent on whether the initiator learns
about CB success, the acceptor or both.  And unless we mandate
signaling, I think who learns about CB success depends a lot on the
mechanism involved.

I'd like to walk through what guarantees we can make, and then make sure
that is actually what applications need.

    >> * I think it does not consider behavior when mutual
    >> authentication is not requested.

    Nico> In that case the acceptor could not signal CB status to the
    Nico> initiator, not via a context token, though the application
    Nico> still could if it was necessary.

First, you seem to be assuming that it's the acceptor that verifies CB.
Is that actually guaranteed by GSS?

Second, how does the acceptor application signal to the initiator about
CB?
The channel might not be verified, so the initiator cannot depend on
that.
There's no mutual authentication, so it's not like the initiator can
know that a wrap token is from the acceptor.
I actually think CB may be kind of useless without mutual auth.
My point is not that the draft is broken, simply that it doesn't cover
the case, and I think application designers are unlikely to be sure on
their own.


    >> * I'm concerned that in thinking about channel binding we have
    >> not given adequate thought to how channel binding interacts with
    >> proxies, reverse proxies and the like.  I'm concerned that this
    >> draft makes that situation worse, and so I'd recommend exploring
    >> that at least enough to understand whether I'm right.

    Nico> As long as we provide a way to discover that CB failed, but
    Nico> continue context establishment, we are making things better,
    Nico> not worse.

To be concrete, I'm concerned that this makes channel binding better
 enough to work with proxies, but doesn't provide us channel
 binding type agility.

Addressing my concern might look like talking about proxies in the
security considerations section, noting that things like endpoint
channel bindings   are easier than unique when you have proxies.
And then noting that we have no plan for what happens when an
application without cb negotiation needs to change the preferred channel
binding type.
    >> * Please get review from multiple implementors before
    >> standardizing the create_context stuff.
    [This point has been addressed; Luke seemed fine when he wrote to
    the WG]