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

[Nico Williams <[e-mail]>]

On Mon, Feb 18, 2019 at 04:29:34PM -0500, Sam Hartman wrote:
> I've reviewed this document at the request of one of the authors, and
> here are my comments:

Thanks.

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

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

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

In GSS it is generally the case that all features are optional and one
finds out what one actually gets by looking at the ret_flags from
context establishment, but CB status is not indicated this way.  This
seems like at least an inconsistency.

Perhaps we can rephrase this?

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

Yes.

> 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.
>
> My past experience is that when we take short cuts like that, we find
> ourselves frustrated later when we discover things we overlooked.
> 
> 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.

I believe IWA is such an application...

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

There should be no backwards-incompatible changes.

I am open to re-designing this extension.

One alternative way to do what we're trying to do:

 - add TWO new, mutually-exclusive ret_flags and NO new req_flags

   GSS_C_CHANNEL_BOUND_FLAG
   GSS_C_CHANNEL_NOT_BOUND_FLAG

 - newer GSS implementations will set ONE of those ret_flags when the
   application provided channel bindings data

This is simpler as we then don't need to add a context creation
function.

Or we could add a GSS_Inquire_context_channel_binding() to indicate CB
status.

> * I think that it inaccurately describes what current implementations
>   do.
> 
> * 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.

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

That could be done in a separate I-D.

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

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

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

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

Presumably the operator of an MITM proxy would not want to permit
application-layer cryptographic session protection if the proxy cannot
MITM that.

(Most of the web is trending towards bearer tokens with no CB (and no
proof of possession, by definition), so your concern might not be
relevant to the web, but things could change, thus making your concern
relevant again.  :)

> * Please get review from multiple implementors before standardizing the
> create_context stuff.  In particular, do you want to take inputs like a
> credential and/or a flag indicating the context is for initiation or
> acceptor.  If yo,u've gotten review including from folks like Luke and
> they are happy, then this is great.  It seems good for API users at
> least.

Sure.  As it happens the authors include maintainers or contributors to
two of the most common GSS C implementations.

I'll seek Luke's input.

Nico
--