Subject: [Unbearable] FWD: Status of draft-ietf-tokbind-https

From: =JeffH <[email-masked]>
Date: Thu, 16 Nov 2017 10:40:31 +0800

[ I'm posting to the list a thread EKR had earlier this week with 
draft-ietf-tokbind-https editors.  this thread is the reason for the 
recent PR:
[TokenBinding/Internet-Drafts] 633587: Adding fed sign-on considerations 
to Security Cons...,
<https://www.ietf.org/mail-archive/web/unbearable/current/msg01507.html>

..and the publishing of -tokbind-https-11:

<https://www.ietf.org/mail-archive/web/unbearable/current/msg01509.html>

Am fwd'g this, and reply(s), w/EKR's and editors' permission...

]

From: Eric Rescorla <[email-masked]>
Date: Monday, November 13, 2017 at 9:00 PM
To: "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
Subject: Status of draft-ietf-tokbind-https
Resent-From: <[email-masked]>, Eric Rescorla <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Dirk 
Balfanz <[email-masked]>, Adam Langley <[email-masked]>, 
<[email-masked]>, Jeff Hodges <[email-masked]>, 
<[email-masked]>
Resent-Date: Monday, November 13, 2017 at 9:00 PM

Hi folks,

I have made a first pass through this document and while I have some
comments it appears generally sound. My one concern is the complexity
of the federated version. It's complicated enough that it's not obviously
secure and I don't know how much analysis there has been of it.

One thing I noticed that is a bit concerning is a potential way for an
attacker to get a confused token. As I understand it, the objective of
the flow is for the client to get a token which he can provide to the
Token Consumer that has in it the TBID for the key which he will use
to do a provided token binding to the Token Consumer. However, the
Token Provider's notion of who the TC is (the audience) usually comes
from some kind of redirect argument.

Specifically, consider the case where Alice is for some reason trying
to authenticate to the attacker, you can then get the following flow:

Alice                        Attacker                  Token Provider

Request ------------------------>

<-------------  Redirect to TP w/
Include-Referred-Token-Binding-ID:true
Audience identity = Victim

GET ---------------------------------------------------------->
EBTMS([K_tp, provided_binding],
       [K_attacker, referred_binding])
Audience identity = Victim

<-------------------------------------------------------- Token

So at this point, the Provider issues a token he thinks is for
the Victim but actually has the TBID for the attacker. I don't
see how to make this an attack, but it seems like it has the TP
being confused and (if the token has an audience value in it)
a token which is confused too, which doesn't seem ideal. Am I
wrong about this?

Anyway, my question really is: how can we make sure we have reasonable
confidence that this piece of token binding is secure? How much
analysis has there been? is there anything I can read? Or do we
just have whatever is in the draft?

Happy to sync up before the session tomorrow if that's useful

Thanks,
-Ekr

---

From: =JeffH <[email-masked]>
Date: Thu, 16 Nov 2017 10:42:10 +0800

From: Leif Johansson <[email-masked]>
Date: Monday, November 13, 2017 at 9:10 PM
To: Eric Rescorla <[email-masked]>, 
"[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
Subject: Re: Status of draft-ietf-tokbind-https
Resent-From: <[email-masked]>, Leif Johansson <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Dirk 
Balfanz <[email-masked]>, Adam Langley <[email-masked]>, 
<[email-masked]>, Jeff Hodges <[email-masked]>, 
<[email-masked]>
Resent-Date: Monday, November 13, 2017 at 9:10 PM

 > On 2017-11-13 14:00, Eric Rescorla wrote:
 > Hi folks,

Have we gotten a secdir review yet? I confess I haven't seen one yet but
I may have missed something...

 > Happy to sync up before the session tomorrow if that's useful

I don't have anything pressing in the morning. Happy to meet up
to talk about this. JB, Nick and Brian is here but I haven't
seen any of the key folks behind the core protocol yet.

	Cheers Leif

---

From: =JeffH <[email-masked]>
Date: Thu, 16 Nov 2017 10:50:15 +0800

From: Eric Rescorla <[email-masked]>
Date: Monday, November 13, 2017 at 9:12 PM
To: Leif Johansson <[email-masked]>
Cc: "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
Subject: Re: Status of draft-ietf-tokbind-https
Resent-From: <[email-masked]>, Eric Rescorla <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Dirk 
Balfanz <[email-masked]>, Adam Langley <[email-masked]>, 
<[email-masked]>, Jeff Hodges <[email-masked]>, 
<[email-masked]>
Resent-Date: Monday, November 13, 2017 at 9:13 PM

 > On Mon, Nov 13, 2017 at 9:10 PM, Leif Johansson <[email-masked]> wrote:

No, I don't think so, but generally I wouldn't expect that thorough a 
review from that, at least not at the level of real protocol analysis.

-Ekr

---

From: =JeffH <[email-masked]>
Date: Thu, 16 Nov 2017 10:51:21 +0800

From: Andrei Popov <[email-masked]>
Date: Monday, November 13, 2017 at 10:50 PM
To: Eric Rescorla <[email-masked]>, Leif Johansson <[email-masked]>, Vinod 
Anupam <[email-masked]>
Cc: "[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
Subject: RE: Status of draft-ietf-tokbind-https
Resent-From: <[email-masked]>, Andrei Popov 
<[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Dirk 
Balfanz <[email-masked]>, Adam Langley <[email-masked]>, 
<[email-masked]>, Jeff Hodges <[email-masked]>, 
<[email-masked]>
Resent-Date: Tuesday, November 14, 2017 at 12:23 AM

I’m available in the morning; unfortunately, Dirk is not here, but 
Anupam can represent him.

Regarding the attack, it is not quite clear to me:
Even assuming the TP is willing to issue a token for Alice to connect to 
the Attacker (which probably means the Attacker is a server known to the 
TP), this token will be bound to the TB key Alice has created for use 
with the attacker.
So the attacker cannot use this token to impersonate Alice to another 
server (without also stealing the corresponding private key).
Or am I missing something?

What time should we meet tomorrow?

Cheers,

Andrei

---

From: =JeffH <[email-masked]>
Date: Thu, 16 Nov 2017 10:53:26 +0800

From: Eric Rescorla <[email-masked]>
Date: Tuesday, November 14, 2017 at 4:11 AM
To: Andrei Popov <[email-masked]>
Cc: Leif Johansson <[email-masked]>, Vinod Anupam <[email-masked]>, 
"[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
Subject: Re: Status of draft-ietf-tokbind-https
Resent-From: <[email-masked]>, Eric Rescorla <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Dirk 
Balfanz <[email-masked]>, Adam Langley <[email-masked]>, 
<[email-masked]>, Jeff Hodges <[email-masked]>, 
<[email-masked]>
Resent-Date: Tuesday, November 14, 2017 at 4:12 AM

On Mon, Nov 13, 2017 at 2:50 PM, Andrei Popov 
<[email-masked]> wrote:> I’m available in the morning; 
unfortunately, Dirk is not here, b>
 > Regarding the attack, it is not quite clear to me: Even assuming the
 > TP is willing to issue a token for Alice to connect to the Attacker
 > (which probably means the Attacker is a server known to the TP), this
 > token will be bound to the TB key Alice has created for use with the
 > attacker.
 >
 > server (without also stealing the corresponding private key). Or am I
 > missing something?

I don't think so. I agree it's not an attack, it's just creating a 
confused token. I just worry whenever we have a protocol which allows 
this kind of confusion that either (a) we can turn it into an attack or 
(b) there's some other way to create confusion that is an attack.

-Ekr

---

From: =JeffH <[email-masked]>
Date: Thu, 16 Nov 2017 10:54:45 +0800

From: Jeff Hodges <[email-masked]>
Date: Tuesday, November 14, 2017 at 1:26 PM
To: Eric Rescorla <[email-masked]>, 
"[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
Cc: "Jeff Hodges (phone & @kingsmountain)" <[email-masked]>
Subject: Re: Status of draft-ietf-tokbind-https

thanks for the question EKR. I did not see this until during the first 
session this morning.

did you folks discuss and are there notes?

In any case seems to me that the below should have gone to unbearable@ 
such that everyone can consider it. probably ought to be sent there with 
any conclusions y'all reached in any case.

I also do not see an attack here, but agree that the attacker would 
ostensibly end up with a security token ("token" in EKR's diagram below) 
having an audience not matching the TBID included in the sec token. 
However, the audience is a notion of the federation protocol, not of 
token binding. So actually obtaining a sec token with an incorrect 
audience depends upon characteristics of the fed protocol and its 
implementation.  I suppose one could argue that we ought to add to 
draft-ietf-tokbind-https' sec cons an explicit admonition that one's fed 
protocol implementation really needs to be correct, otherwise one might 
issue such "confused tokens".  We do have fairly detailed sec analysis 
in sections 7.3 and 7.4, the latter of which is wrt fed protocols. I 
/think/ this issue is at least implicitly addressed in there, but do not 
have fine-tooth-comb time right now. something to perhaps do, tho.
	
thanks,

=JeffH

---

From: =JeffH <[email-masked]>
Date: Thu, 16 Nov 2017 11:01:36 +0800

From: Eric Rescorla <[email-masked]>
Date: Thursday, November 16, 2017 at 8:07 AM
To: Andrei Popov <[email-masked]>
Cc: Leif Johansson <[email-masked]>, Vinod Anupam <[email-masked]>, 
"[email-masked]" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, Dirk Balfanz <[email-masked]>
Subject: Re: Status of draft-ietf-tokbind-https
Resent-From: <[email-masked]>, Eric Rescorla <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Dirk 
Balfanz <[email-masked]>, Adam Langley <[email-masked]>, 
<[email-masked]>, Jeff Hodges <[email-masked]>, 
<[email-masked]>
Resent-Date: Thursday, November 16, 2017 at 8:08 AM

Thanks. As you can imagine, this week is terrible, but I should be able 
to finish my read-through next week.

-Ekr

On Thu, Nov 16, 2017 at 7:56 AM, Andrei Popov 
<[email-masked]> wrote:
Hi Eric,

Dirk has uploaded HTTPSTB-11 with additional language at the end of 
section 7.4 “ Securing Federated Sign-On Protocols”:

“Note that the presence of Token Binding does not relieve the Token
    Provider and Token Consumer from performing various checks to ensure
    the security of clients during federated sign-on protocols.  These
    include the following:

    o  The Token Provider should not issue tokens to Token Consumers that
       have been shown to act maliciously.  To aid in this, the
       federation protocol should identify the Token Consumer to the
       Token Provider (e.g., through OAuth client IDs or similar
       mechanisms), and the Token Provider should ensure that tokens are
       indeed issued to the Token Consumer identified in the token
       request (e.g., by verifying that the redirect URI is associated
       with the OAuth client ID.)

    o  The Token Consumer should verify that the tokens were issued for
       it, and not some other token consumer.  To aid in this, the
       federation protocol should include an audience parameter in the
       token response, or apply equivalent mechanisms (the implicit OAuth
       flow requires Token Consumers to identify themselves when they
       exchange OAuth authorization codes for OAuth refresh tokens,
       leaving it up to the Token Provider to verify that the OAuth
       authorization was delivered to the correct Token Consumer).“

Cheers,

Andrei