Subject: [Unbearable] We need a MitM extension

From: Bill Cox <[email-masked]>
Date: Wed, 23 Mar 2016 06:19:57 -0700

I think of this as a thing we should consider when we upgrade token binding
to support TLS 1.3.  Since TLS 1.3 seems to be getting close to finalized,
is this a reasonable time to start discussing a MitM extension?

I've written up an internal proposal for this, but in short, for token
binding to be enforced globally, we have to deal with the problem of
corporate proxies and anti-virus MitMs.  We can do this with a token
binding extension that provides the material signed by the client.  It
would be used whenever the client detects that it is being MitM-ed with a
locally installed cert.  I've evaluated every attack I can think of, and in
each case this is at least as secure as the alternative: issuing unbound
auth tokens.

There are further steps that can improve security, such as having the
server initiate a proof-of-possession at the application layer when a MitM
extension is received from the client.  However, this is above the
token-binding layer, and does not need to be an official part of token
binding.

Bill

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 24 Mar 2016 02:51:37 +1300

> each case this is at least as secure as the alternative: issuing unbound

Having a locally installed cert is no guaratee of MITM being performed.
Nor a reliable indicator that an MITM isn't using a rogue CA cert.

A more reliable indicator is that these active MITM use different TLS
keying material on the server connection as compared to the client
connection. So the signed tokens should be detectible.

Passive MITM (if possible) are not touching the TLS content, so the
clients tokens will get through anyway.

> token-binding layer, and does not need to be an official part of token

IMHO, any active MITM which is legitimately present should be able to
hook into the system as a federated agent. Being known to the Identity
Provider as a client in its own right allows it to generate its own
tokens for the server connection and replace the ones the end-client is
using.

This allows the MITM to operate, as well as still detecting any
unexpected ones that try to MITM the traffic.

Amos

---

From: Bill Cox <[email-masked]>
Date: Wed, 23 Mar 2016 08:47:21 -0700

We have a chicken-and-the-egg problem.  Legit MitM boxes will only support
TB once TB is both widely deployed and enforced.  On the other hand, we
cannot enforce TB globally until we have a solution for users who travel to
work and back so that they often connect direct, and often through a
corporate proxy.  This MitM extension is needed to get past this deadlock.

I think we should "detect" a MitM this way:

If the browser has a valid TB key pair for the eTLD+1 domain, yet the
server failed to negotiate token binding using the TLS extension, then it
is likely that there is a MitM that does not speak TB.  In this case,
enable the MitM extension and send TB headers anyway.  The server will see
TB headers from a client that did not negotiate TB, and the signature will
mismatch.  However, the server can verify the TB signature over the value
in the extension.  If requests contain an auth token specifically
authorizing use behind this MitM, then the server should allow requests to
be processed.

The following detail is important: When a server sees the TB extension and
a mismatch of the TLS-unique vs the value in the extension, but the auth
token does not authorize this MitM, it needs to authenticate the user and
issue an enhanced auth token that additionally authenticates the user
behind this MitM.  Otherwise, attackers could simply MitM themselves and
authenticate with stolen auth tokens.

Bill

On Wed, Mar 23, 2016 at 6:51 AM, Amos Jeffries <[email-masked]> wrote:

> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 23 Mar 2016 17:41:33 +0000

Extending a MITM-defeating feature to support “legitimate” MITM makes me sad. It reminds me of the “double certificate” TLS authentication schemes used by some national TLS standards. In the past, both TLS WG and HTTPbis WG have repeatedly rejected proposals that enable “legitimate” MITM.

Ø  On the other hand, we cannot enforce TB globally until we have a solution for users who travel to work and back so that they often connect direct, and often through a corporate proxy.

I think there are at least two different cases here: servers that are associated with the MITM and servers that aren’t. The former can probably use the scheme that Amos described, avoiding the need for the extension. The latter could issue less privileged/short-time bearer tokens when TB is not used and more privileged/longer-term bound tokens when TB is negotiated. Bill, do you think this would work for you?

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Wednesday, March 23, 2016 8:47 AM
To: Amos Jeffries <[email-masked]>
Cc: Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] We need a MitM extension

We have a chicken-and-the-egg problem.  Legit MitM boxes will only support TB once TB is both widely deployed and enforced.  On the other hand, we cannot enforce TB globally until we have a solution for users who travel to work and back so that they often connect direct, and often through a corporate proxy.  This MitM extension is needed to get past this deadlock.

If the browser has a valid TB key pair for the eTLD+1 domain, yet the server failed to negotiate token binding using the TLS extension, then it is likely that there is a MitM that does not speak TB.  In this case, enable the MitM extension and send TB headers anyway.  The server will see TB headers from a client that did not negotiate TB, and the signature will mismatch.  However, the server can verify the TB signature over the value in the extension.  If requests contain an auth token specifically authorizing use behind this MitM, then the server should allow requests to be processed.

The following detail is important: When a server sees the TB extension and a mismatch of the TLS-unique vs the value in the extension, but the auth token does not authorize this MitM, it needs to authenticate the user and issue an enhanced auth token that additionally authenticates the user behind this MitM.  Otherwise, attackers could simply MitM themselves and authenticate with stolen auth tokens.

Bill

On Wed, Mar 23, 2016 at 6:51 AM, Amos Jeffries <[email-masked]<mailto:[email-masked]>> wrote:

Amos

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cf25adc15855a4ecb239208d353326fde%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rJs%2fLJn%2bmsDXYWjurl%2bTYyU1fQGlN7rW9yz1B2Ry01k%3d>

---

From: Bill Cox <[email-masked]>
Date: Wed, 23 Mar 2016 11:24:30 -0700

On Wed, Mar 23, 2016 at 10:41 AM, Andrei Popov <[email-masked]>
wrote:

> Extending a MITM-defeating feature to support “legitimate” MITM makes me
> sad.
>

Me, too...

I think there are at least two different cases here: servers that are
> associated with the MITM and servers that aren’t. The former can probably
> use the scheme that Amos described, avoiding the need for the extension.
> The latter could issue less privileged/short-time bearer tokens when TB is
> not used and more privileged/longer-term bound tokens when TB is
> negotiated. Bill, do you think this would work for you?
>

That is the current default plan, I think.  The new auth token would
authorize non-TB-enabled access for a while, and TB-enabled access for
longer.  This is a bit less secure, since the auth token can be used from
anywhere, not just behind the specific MitM.

Bill

---

From: Nick Harper <[email-masked]>
Date: Wed, 23 Mar 2016 11:54:02 -0700

I'm having trouble figuring out how this provides any more security than
not doing it at all. My understanding of this MitM proposal is as follows:
1. Client establishes (direct) connection to server with TBID1; server
replies with cookie C1 bound to TBID1
2. User changes networks, and is now behind a MitM
3. Client connects to server (thru MitM), tries (and fails) to negotiate TB
in TLS handshake.
4. Client sends Sec-Token-Binding header anyways, with MitM extension, and
TBID1. Client also sends cookie C1.
5. Server has user re-auth, and issues new cookie C2 that is half-bound to
TBID1 (i.e. the server either expects it to be bound to TBID1, or to see
the token binding message with the MitM extension with TBID1)
6. Client can use C2 with TBID1 with or without MitM extension to
authenticate to the server.

In steps 5 and 6, C2 plus the value of the Sec-Token-Binding header
effectively becomes a bearer token.

If we don't do any sort of MitM extension, steps 1 thru 3 stay the same. In
step 4, the client doesn't send a Sec-Token-Binding header, but still sends
cookie C1. Step 5 still has the server asking the user to re-auth, but now
the new cookie C2 is unbound.

On Wed, Mar 23, 2016 at 11:24 AM, Bill Cox <[email-masked]> wrote:

> On Wed, Mar 23, 2016 at 10:41 AM, Andrei Popov <[email-masked]
> > wrote:
>

---

From: Bill Cox <[email-masked]>
Date: Wed, 23 Mar 2016 12:35:01 -0700

You are reading it correctly.  The partially bound cookie + TB header
become a bearer token.  There are places in the pipeline where only the
cookie exists.

Bill

On Wed, Mar 23, 2016 at 11:54 AM, Nick Harper <[email-masked]> wrote:

> 3. Client connects to server (thru MitM), tries (and fails) to negotiate
> TB in TLS handshake.
> If we don't do any sort of MitM extension, steps 1 thru 3 stay the same.
> In step 4, the client doesn't send a Sec-Token-Binding header, but still
> sends cookie C1. Step 5 still has the server asking the user to re-auth,
> but now the new cookie C2 is unbound.
>
>> On Wed, Mar 23, 2016 at 10:41 AM, Andrei Popov <
>> [email-masked]> wrote:
>>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 23 Mar 2016 19:50:05 +0000

I thought there was an additional piece in Bill’s proposal: the server knows about the specific MITM, authenticates the MITM, and authorizes the use of a token through this particular MITM. Did I get this wrong? Otherwise, Nick is right and a MITM TB extension is not buying us much.

From: Bill Cox [mailto:[email-masked]]
Sent: Wednesday, March 23, 2016 12:35 PM
To: Nick Harper <[email-masked]>
Cc: Andrei Popov <[email-masked]>; Amos Jeffries <[email-masked]>; Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] We need a MitM extension

You are reading it correctly.  The partially bound cookie + TB header become a bearer token.  There are places in the pipeline where only the cookie exists.

Bill

On Wed, Mar 23, 2016 at 11:54 AM, Nick Harper <[email-masked]<mailto:[email-masked]>> wrote:
I'm having trouble figuring out how this provides any more security than not doing it at all. My understanding of this MitM proposal is as follows:
1. Client establishes (direct) connection to server with TBID1; server replies with cookie C1 bound to TBID1
2. User changes networks, and is now behind a MitM
3. Client connects to server (thru MitM), tries (and fails) to negotiate TB in TLS handshake.
4. Client sends Sec-Token-Binding header anyways, with MitM extension, and TBID1. Client also sends cookie C1.
5. Server has user re-auth, and issues new cookie C2 that is half-bound to TBID1 (i.e. the server either expects it to be bound to TBID1, or to see the token binding message with the MitM extension with TBID1)
6. Client can use C2 with TBID1 with or without MitM extension to authenticate to the server.

In steps 5 and 6, C2 plus the value of the Sec-Token-Binding header effectively becomes a bearer token.

If we don't do any sort of MitM extension, steps 1 thru 3 stay the same. In step 4, the client doesn't send a Sec-Token-Binding header, but still sends cookie C1. Step 5 still has the server asking the user to re-auth, but now the new cookie C2 is unbound.

On Wed, Mar 23, 2016 at 11:24 AM, Bill Cox <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Mar 23, 2016 at 10:41 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Extending a MITM-defeating feature to support “legitimate” MITM makes me sad.

Me, too...

That is the current default plan, I think.  The new auth token would authorize non-TB-enabled access for a while, and TB-enabled access for longer.  This is a bit less secure, since the auth token can be used from anywhere, not just behind the specific MitM.

Bill

---

From: Bill Cox <[email-masked]>
Date: Wed, 23 Mar 2016 12:56:02 -0700

On Wed, Mar 23, 2016 at 12:50 PM, Andrei Popov <[email-masked]>
wrote:

> I thought there was an additional piece in Bill’s proposal: the server
> knows about the specific MITM, authenticates the MITM, and authorizes the
> use of a token through this particular MITM. Did I get this wrong?
> Otherwise, Nick is right and a MITM TB extension is not buying us much.
>

By itself, the extension would not buy much.  I think I'm OK with just
issuing authorizing non-TB access for a shorter time.

Nick is correct that given the cookie and also a plain-text version of the
TB header with MitM extension, an attacker can authenticate without being
behind the MitM.  This isn't quite as bad as an unbound auth token, but it
does not buy a lot of protection.

Bill

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Mar 2016 20:24:13 +0000

> does not buy a lot of protection.

(no hats, but with an openly-declared bias I've publicly
stated many times now;-)

I don't see how there's any real scenario where any browser
or server can "authenticate" an HTTP MitM as being an HTTP
MieM, whether or not that is supposedly legitimate.

So I'm very confused by the above.

Bill - can you re-state the security and privacy benefits
of what you're proposing? Maybe phrasing it differently will
help but I'm just not seeing how anyone benefits from basically
pretending to not notice a MitM. Wouldn't doing so really call
into question the whole point of TB and put us back to to
where the name of this list becomes relevant?

Ta,
S.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Mar 2016 17:08:58 +1100

> Extending a MITM-defeating feature to support “legitimate” MITM makes me

I know that Stephen has said it, but I think that it behooves me to +1
this.  I'm opposed to "fixing" this "problem".

---

From: Leif Johansson <[email-masked]>
Date: Thu, 24 Mar 2016 09:09:13 +0100

> this.  I'm opposed to "fixing" this "problem".

Reading the thread (as chair) I don't see this proposal getting
the level support it needs to have for the WG to spend resources
on it.

Feel free to disagree but lets also get the rest of the work done.

	Cheers Leif

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 24 Mar 2016 21:31:57 +1300

On 24/03/2016 7:08 p.m., Martin Thomson wrote:
> On 24 March 2016 at 04:41, Andrei Popov wrote:

"Me too" +1 on not lowering this security barrier, however painful.

And I'm saying that with my hat on as maintainer of software commonly
used as an MITM for TLS traffic.

AYJ

---

From: Karthik Bhargavan <[email-masked]>
Date: Thu, 24 Mar 2016 09:36:11 +0100

Is there value in designing a secure protocol “extension” that plays nice
with middle-boxes? How common/important is this problem?

(with the researcher hat on)
-Karthik

> On 24 Mar 2016, at 09:31, Amos Jeffries <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Thu, 24 Mar 2016 08:38:49 +0000

+1

> On Mar 24, 2016, at 8:09 AM, Leif Johansson <[email-masked]> wrote:
>

---

From: Bill Cox <[email-masked]>
Date: Thu, 24 Mar 2016 08:02:22 -0700

I agree.  Let's let this idea drop.  Thanks for considering it.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 24 Mar 2016 18:15:15 +0200

> On 24 Mar 2016, at 10:36 AM, Karthik Bhargavan <[email-masked]> wrote:
> 

I use the same laptop both when I’m at home (where there is not TLS proxy) and at work (where there is one).

My situation is not unique. We don’t necessarily need a protocol extension to play nice with these proxies, but we need some kind of good story of how things work for such a use case. If websites that use our protocol will fail to display when I go to work, then major websites will not deploy it.

If OTOH security is only degraded when behind the proxy (similar to how we lose the EV indication) then it’s probably fine.

Yoav

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 24 Mar 2016 10:08:16 -0700

What about client side proxies? Such as when employees take laptops in and out of work?

Web gateways/balancers that terminate tls are also an issue but I understand the challenge. Can binding still be extended to the web service?

Probably need to cover the limitations in detail even if not addressed or addressable. 

Phil

> On Mar 24, 2016, at 09:15, Yoav Nir <[email-masked]> wrote:
> 
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 24 Mar 2016 19:48:15 +0200

> On 24 Mar 2016, at 7:08 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> 

server-side proxies can share as much server-side state (including private keys) with the server and/or with each other. They might need to be upgraded, but they will work. Whatever implementers do to share state between them and the servers is also fine because those  proxies are as trusted as the servers - they’re part of the stack.

Client-side proxies are not part of the stack. They can forward tokens (such as cookies) from client to server and back again, but any kind of channel binding or key pinning will defeat them. 

> Probably need to cover the limitations in detail even if not addressed or addressable. 

I agree.