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

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sam Hartman-5

I've reviewed this document at the request of one of the authors, and
here are my comments:

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.

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.

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.

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.

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.

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.

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

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

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

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

Here are my specific comments:




>Note that it would be useless to allow security context
>   establishment to succeed when the initiator does not provide channel
>   bindings but the acceptor does, at least as long as there's no
>   outward indication of whether channel binding was used!

An exclamation in an IETF document is a good sign that you're letting
your emotions get ahead of your technical content and perhaps you should
take a step back.
I think the above quote is a good example.
You don't get MITM protection if the initiator provides channel binding
and the acceptor does, but it can be useful none-the-less.
Assuming that an attacker cannot convert a context token that has
channel bindings into one that does not, and initiators know acceptors
are providing channel bindings, then initiators know that if they
provide channel bindings then the channel bindings are validated.
That can provide you defense in depth, for example, binding channels to
a TLS channel binding in applications where you also validate the PKI
and have good trust anchors.
It cannot be sufficient alone to provide MITM defense.
However, additional layers of defense (provided they do not trigger
false negatives) are valuable in security.
Please rephrase to focus on the characteristics of the system rather
than judgments of those characteristics.

>   o  Whenever both the initiator and acceptor have provided
>      input_channel_bindings to GSS_Init/Accept_sec_context() and the
>      channel bindings do not match, then the mechanism MUST fail to
>      establish a security context token.  (This is a restatement of an
>      existing requirement in the base specification.)

Actually, as best I can tell, RFC 2743section 1.1.6 disagrees with
this.  It looks in RFC 2743 like channel bindings are optional for a
mechanism to use.
I think it's reasonable that if a mechanism supports channel bindings,
then if both the initiator and acceptor provide channel bindings they
must validate for context establishment to succeed.

>   o  Whenever the acceptor application has a) provided channel 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.

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

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

I

>   o  Whenever the application has a) provided channel bindings to
>      GSS_Init_sec_context() or GSS_Accept_sec_context(), and b)
>      indicated support for the ret_channel_bound_flag flag, then the
>      mechanism SHOULD NOT fail to establish a security context just
>      because the peer did not provide channel bindings data.  The
>      mechanism MUST output the ret_channel_bound_flag if both peers
>      provided the same input_channel_bindings to GSS_Init_sec_context()
>      and GSS_Accept_sec_context().  The mechanism MUST NOT output the
>      ret_channel_bound_flag if either (or both) peer did not provide
>      input_channel_bindings to GSS_Init/Accept_sec_context().  This
>      requirement restores the original base GSS-API specified behavior,
>      with the addition of the ret_channel_bound_flag flag.
I think we need to consider the transition period here.
What happens when you have a new initiator talking to an old acceptor or
vice versa.Are you planning on introducing new over-the-wire signaling
so that an acceptor  can say something like "I'm setting up your
context, but your channel binding didn't verify?"
For example in RFC 7055, the channel binding data is sent as a checksum
from initiator to acceptor.  The acceptor either sends back a final
token or sends back an error depending on whether it accepts the
bindings.
How, without protocol changes would we meet this requirement.
Similarly, I think Kerberos works the same way in the mutual
authentication case.  In the non mutual authentication case, I don't
think the initiator even learns whether the acceptor validated the
channel bindings.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

hartmans
>>>>> "Sam" == Sam Hartman <[hidden email]> 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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard
In reply to this post by Sam Hartman-5

On 18 Feb 2019, at 10:29 pm, Sam Hartman <[hidden email]> wrote:

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

gss_create_sec_context() and gss_set_context_flags() could be subsumed into gss_set_sec_context_option() which is supported by both Heimdal and MIT. But perhaps not as easy to use for the caller.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
In reply to this post by hartmans
On 2/18/19 4:39 PM, Sam Hartman wrote:
> 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.

I think the practical motivation for this draft is a desire to add
channel bindings to application protocols which do not currently use
them.  I believe HTTP Negotiate is commonly given as a candidate.  So,
while I am not sure there are any applications in this category today,
there is a desire to (at least temporarily) create some in the future.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Sam Hartman-5
>>>>> "Greg" == Greg Hudson <[hidden email]> writes:

    Greg> On 2/18/19 4:39 PM, Sam Hartman wrote:
    >> 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.

    Greg> I think the practical motivation for this draft is a desire to
    Greg> add channel bindings to application protocols which do not
    Greg> currently use them.  I believe HTTP Negotiate is commonly
    Greg> given as a candidate.  So, while I am not sure there are any
    Greg> applications in this category today, there is a desire to (at
    Greg> least temporarily) create some in the future.

HTTP negotiate seems like it will be an interesting design thought
exercise.

While working on Moonshot we spent some time trying to figure out how we
would approach channel binding for HTTP negotiate.

It seemed like deployment considerations made it kind of tricky.

Do I use unique or endpoint channel bindings?  That depends on several
factors:

* To use unique channel bindings I need to produce the GSS-API token on
  the client after the TLS connection is established.  That assumes a
  certain model for how the HTTP and TLS libraries interact.

* To use unique channel bindings on the server, I need access to  the
  appropriate hashes; that assumes my HTTP library and my TLS library
  make that available to whoever is producing the GSS token.  (In many
  but not all cases that will be part of the HTTP library)

OK, so just use endpoint channel bindings and be done with it.

Does the server actually know its endpoint channel binding?  If it's
behind a reverse proxy, that may depend a lot on the configuration.  TLS
may terminate at the reverse proxy.  The connection behind the reverse
proxy may be unencrypted, or it may be encrypted using a different
certificate.

We don't want to break things that work today.  Yes, channel bindings
would make that situation more secure, but HTTP negotiate has value
without channel bindings, demonstrated by the people who use it today.

Also, we've already found bugs in channel bindings (even for TLS).  So,
we probably want some sort of transition strategy.

So, it seems like you're almost always going to want some application
layer something to figure out whether channel bindings are supported on
both ends and whether to use them.  (And probably if they get used a
lot, which channel binding to use).
That's frustrating because it makes channel bindings not so simple.

Some thoughts:

The Moonshot behavior (null acceptor bindings ignores any initiator
  CB) makes it easier for people to withdraw from the channel binding
  process when  local configuration does not support channel binding.
If it weren't for there being multiple types of channel binding and a
  need to think about transitions, I'd argue that makes the Moonshot
  behavior clearly supperior especially if there are not currently
  applications that don't know whether they are doing CB.

Given that we probably should care about those issues, I'm not at all
sure I know what the right behavior should be for applications that do
not support this flag.

I'm still definitely in favor of the flag.  The more I look at this, I
don't think this is fixing a flaw in GSS-API, and I especially am not
seeing the security flaw.
I think it's adding a new capability with some tricky interoperability
and deployment considerations.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Martin Rex-2
In reply to this post by Sam Hartman-5
Just a quick comment, I haven't been following IETF work for months...

Sam Hartman <[hidden email]> 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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
1. Sam suggested that we consider allowing context establishment in the
acceptor-only binding case (i.e. where the acceptor caller provided
channel bindings but the initiator caller did not).  Sam notes that
Moonshot's GSS-EAP implementation allows this, and that policing a
legitimate initiator's decision to provide channel bindings isn't
security-critical in common scenarios.  He nevertheless supports a
mechanism to inform the acceptor whether channel bindings were used.

I discovered recently that Heimdal's krb5 mechanism permits
acceptor-only bindings, if I read the code correctly.  So it may be that
MIT's krb5 mech is unusual in rejecting the acceptor-only bindings case.
 (GNU Shishi's GSS krb5 mech does as well.)

Relaxing implementations to allow acceptor-only bindings solves the
original problem of allowing channel bindings to be introduced at
acceptors when not all initiators provide them.  But without some kind
of signalling, application code can't be certain in advance that it's
running against a relaxed implementation.  A mechanism attribute is the
most robust way to signal this.

2. Nico noted (out of band) that with a relaxed implementation, we can
communicate channel binding state very simply: allocate two ret_flags,
one for "channel bindings were used" and one for "channel bindings were
not used".  If you don't get either flag back, you're running against an
old implementation (or, on the initiator side, the mechanism protocol
doesn't provide confirmation).

In this model, we don't need a ret_flags_understood input to
accept_sec_context, and therefore don't need gss_create_sec_context().

3. Martin argues against channel bindings altogether, on the basis that
they break proxies and that it's better to use a channel security layer
tied to the authentication mechanism.  This viewpoint seems out of step
with the decision not to provide a security layer in SASL GS2.

Practically speaking, the most common underlying secure channel is TLS,
whose server authentication (when the client actually performs it)
prevents MITM attacks in most cases.  It is of some concern that TLS
does not have the same server naming or trust roots as the GSS
mechanism.  I'm not sure that amounts to a pressing need for channel
bindings, but I do see some value in them as a defense-in-depth measure
when it's not desirable to allow proxies.

I don't see much value in endpoint channel bindings.

Separately from all of this, I am a bit concerned that we are fulfilling
a need to upgrade from no-channel-bindings to channel-bindings, but once
an application protocol starts using channel bindings of any type, there
is no practical way to upgrade to a different type of channel bindings
without application-layer signalling.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Sam Hartman-5
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
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
How about a much simpler proposal:

   If the application provided channel bindings, and channel binding
   succeeded, then the mechanism MUST include GSS_C_CHANNEL_BOUND_FLAG
   in the ret_flags.

   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.

That would be the entirety of the normative text.

The "MAY" in the third paragraph involves an optional  backwards-
incompatible change, allowing implementations to choose whether to make
it, possibly based on local configuration, or on usage of the non-
standard gss_set_cred_option().

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Sam Hartman-5
In reply to this post by Nico Williams
>>>>> "Nico" == Nico Williams <[hidden email]> 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]
   
   

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten