Subject: Re: [Unbearable] Referred token binding IDs

From: =JeffH <[email-masked]>
Date: Fri, 25 Mar 2016 19:56:01 -0700

On Monday, March 21, 2016 at 1:40 PM, Nick wrote:
 > My understanding of the problem in figure 1 is that
 >
 > 1) in the redirect from TC2 to TP3 (step 2b), the referred TBID
 > is TBID2, while the redirect uri is to TC1, and..

yes, this is an issue -- in this case TBID1 needs to be (somehow) relayed.

 > 2) when TP3 redirects to TP4, somehow TBID2 needs to be relayed.

actually, TBID1 needs to be relayed (somehow) rather then TBID2 because that 
is what is being called for in the "fed layer's" authn request's redirect_uri.

 > One way to solve problem 2 is to treat the TP3->TP4 redirect like the
 > "identity-as-a-service" scenario that Dirk mentioned. Instead of TP4
 > redirecting to TC1, it can create a token to be consumed by TP3, and
 > redirect to TP3, which will then create a token to send back to TC1.

IMV it is inappropriate for us to specify a solution like that (i.e., 
chaining IDPs) in -tokbind-https aka HTTPSTB -- such a configuration is up 
to how the fed layer is config'd and deployed. It may or may not be 
appropriate for a given federation.

 > For problem 1, I am going to assume that TC1 and TC2 are cooperating.
 > The easiest way to fix this is to have TC2 transmit to TC1
 > out-of-band what TBID2 is so that TC1 can verify it.

did you mean to say: have TC1 transmit out-of-band TBID1 to TC2 ? ..because 
the issue here in needing to relay TBID1 somehow, unless I'm missing something.

 > Here's another solution (for both problems) that I think could work...
 > ..<elided>..

The above other solution elided due to the below subsequent analysis.

On Thursday, March 24, 2016 at 3:15 PM, Nick wrote:
 > TL;DR: Use Include-Referer-Token-Binding-ID. Binding a token to an
 > ID that hasn't been verified can result in a MitM getting control of
 > a bound token.
 >
 > Dirk and I chatted about my/David's proposal, and how it applies to
 > Jeff's scenario. In steps 3a and 3b from figure 1, TBID3 needs to be
 > referred to TP4 (in addition to conveying TBID2).

actually, conveying TBID3 to TP4 is optional IMV and one would only need to 
do it if TP4 is also minting other bound sec tokens eg cookies with TBID3 in 
'em.

Also, it is TBID1 that actually needs to be referred, in order to properly 
issue the ID Token. The remark in (the old) figure 1 wrt "somehow conveys 
TBID2 ?" is simply a reference to Dirk's comments where he suggested that 
that is what we'd do here. See updated figure 1a below.

 > The problem with the current setup of figure 1 is when there is an
 > attacker MitMing connections to TP3. In step 2b, the
 > TokenBindingMessage contains TBID3' and TBID2', both under attacker
 > control. Then, in step 3b, when the client follows the redirect from
 > (the MitM'd) TP3 to TP4, it includes TBID4, but not TBID3, in the
 > TokenBindingMessage. When TP4 authenticates the user, TBID4 is
 > correct, and then TP4 creates a token for the user's identity with an
 > attacker-controlled TBID. Even if TP3 and TP4 are somehow
 > cooperating, and the provided and referred token bindings from the
 > request in step 2b are passed from TP3 to TP4 out-of-band, the token
 > still has an attacker controlled TBID, since the token bindings sent
 > in step 2b are attacker controlled.

agreed with the above except that it is TBID1 that really needs to be 
conveyed to ultimately to TP4 in order for the latter to correctly issue the 
OIDC ID Token, or SAML assertion or whatever, at the fed layer.

On Friday, March 25, 2016 at 10:49 AM, Dirk wrote:
 > Agreed. Bottom line is that I still believe that a single referred
 > token binding (even on repeated redirects) gives us all we need.

I agree it is "all we need" _if_ we are saying that it is out-of-scope for 
HTTPSTB to specify how, in a multi-redirect scenario such as fig 1a, for the 
correct referred TBID to be conveyed to the TC's point-of-handoff-to-TP, and 
similarly out-of-scope for any redirects among TP entities per HTTPSTB spec 
(i.e., they figger it out themselves).

I.e., we _can_ say the above I think -- tho some may perceive it as 
sub-optimal to just leave it unspecified -- but it may not be that big a 
deal, I don't know. (federation folk please speak up here !)

We could devise some means of signaling in the HTTPSTB header field layer 
from TC-to-TC and TP-to-TP what the correct TBID to use is (hm, it will 
require integrity protection from the postulated MITMs) and that might save 
the fed layer folks from inventing disjoint ways to do it (and hm, however 
they do it will need integrity protection)...

But we may not want to go there, I'm not sure myself.

HTH,

=JeffH
------

Figure 1a:   ( Note: if this fig gets inserted into the spec it will
                      likely _not_ be labeled "fig 1" there )
What: Analysis of redirect hops at RP aka TC and at IDP aka TP

Legend: (see figure 1 in a prior email msg)

Client,                      Token Consumer,         Token Provider,
aka:                         aka:                    aka:
User Agent                   OpenID Client,          OpenID Provider,
                              OIDC Relying Party,     OIDC Provider,
                              SAML Relying Party      SAML Identity Provider
                              [ servers "1", "2" ]    [ servers "3", "4" ]
+--------+                       +-----+  +-----+     +-----+   +-----+
| Client |                       | TC1 |  | TC2 |     | TP3 |   | TP4 |
+--------+                       +-----+  +-----+     +-----+   +-----+
     |                               |        |           |         |
     |                               |        |           |         |
     | 0. Client interacts w/TC1                          |         |
     | over HTTPS, establishes Ks1 & Kp1, TBID1           |         |
     | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]]   |         |
     |------------------------------>|        |           |         |
     |                               |        |           |         |
     |                               |        |           |         |
     | 1a. redirect to TC2 for TC-specific reasons        |         |
     | any security-relevant cookies should contain TBID1 |         |
   +<- - - - - - - - - - - - - - - - |        |           |         |
   . |                               |        |           |         |
   +----------------------------------------->|           |         |
     | 1b. establishes Ks2 & Kp2, TBID2       |           |         |
     | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]]   |         |
     |                               |        |           |         |
     |                               |        |           |         |
     |                               |        |           |         |
     | 2a. OIDC ID Token request,    |        |           |         |
     | aka "Authentication Request" w/ redirect_uri=TC1;  <-- note well
     | conveyed w/ HTTP response header field of:         |         |
     |   Include-Referer-Token-Binding-ID:true            |         |
     | any security-relevant cookies should contain TBID2 |         |
   +<- - - - - - - - - - - - - - - - - - - - -|           |         |
   . | (redirect to TP via 301, 302, |        |           |         |
   . |  303, 307, or 308)            |        |           |         |
   . |                               |        |           |         |
   +----------------------------------------------------->|         |
     | 2b. client opens HTTPS w/ TP3,         |           |         |
     | establishes Ks3, Kp3, TBID3;           |           |         |
     | sends GET or POST with                 |           |         |
     | ID Token request w/ redirect_uri=TC1,  |           |         |
     | ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding],             |
     |       [{EKM3}Ks2,TBID2,referred_token_binding]] <-- but ID Tok request
     |                               |        |        <-- is for TC1
     |                               |        |           |         |
     |                               |        |           |         |
     |                               |        |           |         |
     | 3a. redirect to TP4 for TP-specific reasons        |         |
     | any security-relevant cookies should contain TBID3 |         |
   +<- - - - - - - - - - - - - - - - - - - - - - - - - - -|         |
   . |                               |        |           |         |
   +--------------------------------------------------------------->|
     | 3b. client opens HTTPS w/ TP4,         |           |         |
     | establishes Ks4 & Kp4, TBID4           |           |         |
     | ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]]   |         |
     |         *** as well as the ID Token request w/ redirect_uri=TC1;
     |         *** also, somehow conveys TBID1 to TP4 <-- Need this to
     |                               |        |       <-- issue bound
     |                               |        |       <-- ID Token
     |                               |        |           |         |
     | 4. user authentication (if applicable,             |         |
     |    methods vary, particulars are out of scope)     |         |
     |<============================================================>|
     | (TP generates ID Token for TC1 containing TBID1   <-- Need to get
     |  also set cookie(s) containing TBID4 and/or TBID3 <-- TBID1 here
     |  details vary)                |        |           |         |
     |                               |        |           |         |
     |                               |        |           |         |
     |                               |        |           |         |
     | 5a. ID Token issued for TC1, containing TBID1, <-- how do this if
     |    conveyed via OIDC "Authentication Response" <-- don't have TBID1?
   +<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
   . |   (redirect to TC1)           |        |           |         |
   . |                               |        |           |         |
   +-------------------------------->|        |           |         |
     | 5b. HTTPS GET or POST with    |        |           |         |
     | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]]   |         |
     | conveying Authn Reponse containing ID Token w/TBID1,         |
     |                                    issued for TC1            |
     |                               |        |           |         |
     |                               |        |           |         |
     |                               |        |           |         |
     |                               |        |           |         |
     | 6. user is signed-on, any security-relevant cookie(s)        |
     | that are set SHOULD contain TBID1      |           |         |
     |<------------------------------|        |           |         |
     |                               |        |           |         |
     |                               |        |           |         |

---

From: Nick Harper <[email-masked]>
Date: Fri, 25 Mar 2016 20:33:45 -0700

If you want TP4 to generate a token bound to TBID1, then TP4 needs to
verify that TBID4 and TBID1 are both owned by the same client. IMO, the
easiest way to do this is to have both TBIDs in the same
TokenBindingMessage. I'm curious if this scenario (with TC1, TC2, TP3, and
TP4) is hypothetical, or if there are real-world setups that work like this
where TC1 can't redirect directly to TP4, or you can't have TP4 issue a
token for TP3, which then issues a token for TC2, which issues a token for
TC1 (as Dirk suggests).

I can think of a federated scenario that currently exists where there are
multiple token consumers and producers, but it works with a single referred
token binding from Include-Referer-Token-Binding-ID.
1) Some app A wishes to let users log in with their google account. When
the user clicks A's login button, they get redirected to google's login
page G (with Include-Referer-Token-Binding-ID).
2) The user wishes to log in to google with their university's gmail
account. They start working through the login flow for their
[email-masked] account, and G redirects them to the university's
IdP to log in.
3) The user logs in to the university's IdP, which generates a SAML token
bound to TBID_G. The university's IdP passes this SAML token back to google.
4) Google verifies this token, and now generates an OpenID Connect token to
pass back to A, and binds it to the referred TBID_A that was passed to G in
the initial redirect A->G.
5) A now has a token from G that is bound to TBID_A.

If there are situations where there is a need for TP4 to generate a token
for TC1, then I think changes would be needed to TBHTTPS to support that.
One such change could be for Include-Referer-Token-Binding-ID to pass along
all TBIDs from the previous request instead of just one. This would only
work if there was a single chain of redirects from TC1 all the way to TP4.
Once TP4 receives this TokenBindingMessage with TBID1, TBID2, TBID3, and
TBID4 (and verifies all of them), it could issue a token that is bound to
all of them, and then TC1 iterates through the bound TBIDs to find one that
it recognizes.

On Fri, Mar 25, 2016 at 7:56 PM, =JeffH <[email-masked]>
wrote:

> actually, TBID1 needs to be relayed (somehow) rather then TBID2 because
> that is what is being called for in the "fed layer's" authn request's
> redirect_uri.
>
>
> did you mean to say: have TC1 transmit out-of-band TBID1 to TC2 ?
> ..because the issue here in needing to relay TBID1 somehow, unless I'm
> missing something.
>
>
> actually, conveying TBID3 to TP4 is optional IMV and one would only need
> to do it if TP4 is also minting other bound sec tokens eg cookies with
> TBID3 in 'em.
>
> conveyed to ultimately to TP4 in order for the latter to correctly issue
> the OIDC ID Token, or SAML assertion or whatever, at the fed layer.
>
>
> HTTPSTB to specify how, in a multi-redirect scenario such as fig 1a, for
> the correct referred TBID to be conveyed to the TC's
> point-of-handoff-to-TP, and similarly out-of-scope for any redirects among
> TP entities per HTTPSTB spec (i.e., they figger it out themselves).
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 28 Mar 2016 17:31:15 +0000

I think I’m siding with Dirk on this: if the RP redirects to IDP1, which redirects to IDP2, then IDP2 generates a token for IDP1 to consume, and finally IDP1 may generate a token for the RP to consume. This works with the client proving possession of two TB keys at each step of the redirect.

If we wanted to short-circuit the return path, so that IDP2 can redirect back to the RP, then indeed we’d need to convey TBID_RP to IDP2, but so far in our limited deployment experience here at MS we have not found the need to do this. If someone has redirect scenarios like this, please speak up.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Nick Harper
Sent: Friday, March 25, 2016 8:34 PM
To: =JeffH <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Referred token binding IDs

If you want TP4 to generate a token bound to TBID1, then TP4 needs to verify that TBID4 and TBID1 are both owned by the same client. IMO, the easiest way to do this is to have both TBIDs in the same TokenBindingMessage. I'm curious if this scenario (with TC1, TC2, TP3, and TP4) is hypothetical, or if there are real-world setups that work like this where TC1 can't redirect directly to TP4, or you can't have TP4 issue a token for TP3, which then issues a token for TC2, which issues a token for TC1 (as Dirk suggests).

I can think of a federated scenario that currently exists where there are multiple token consumers and producers, but it works with a single referred token binding from Include-Referer-Token-Binding-ID.
1) Some app A wishes to let users log in with their google account. When the user clicks A's login button, they get redirected to google's login page G (with Include-Referer-Token-Binding-ID).
2) The user wishes to log in to google with their university's gmail account. They start working through the login flow for their [email-masked]<mailto:[email-masked]> account, and G redirects them to the university's IdP to log in.
3) The user logs in to the university's IdP, which generates a SAML token bound to TBID_G. The university's IdP passes this SAML token back to google.
4) Google verifies this token, and now generates an OpenID Connect token to pass back to A, and binds it to the referred TBID_A that was passed to G in the initial redirect A->G.
5) A now has a token from G that is bound to TBID_A.

If there are situations where there is a need for TP4 to generate a token for TC1, then I think changes would be needed to TBHTTPS to support that. One such change could be for Include-Referer-Token-Binding-ID to pass along all TBIDs from the previous request instead of just one. This would only work if there was a single chain of redirects from TC1 all the way to TP4. Once TP4 receives this TokenBindingMessage with TBID1, TBID2, TBID3, and TBID4 (and verifies all of them), it could issue a token that is bound to all of them, and then TC1 iterates through the bound TBIDs to find one that it recognizes.

On Fri, Mar 25, 2016 at 7:56 PM, =JeffH <[email-masked]<mailto:[email-masked]>> wrote:

> 2) when TP3 redirects to TP4, somehow TBID2 needs to be relayed.

actually, TBID1 needs to be relayed (somehow) rather then TBID2 because that is what is being called for in the "fed layer's" authn request's redirect_uri.

> redirect to TP3, which will then create a token to send back to TC1.

IMV it is inappropriate for us to specify a solution like that (i.e., chaining IDPs) in -tokbind-https aka HTTPSTB -- such a configuration is up to how the fed layer is config'd and deployed. It may or may not be appropriate for a given federation.

> out-of-band what TBID2 is so that TC1 can verify it.

did you mean to say: have TC1 transmit out-of-band TBID1 to TC2 ? ..because the issue here in needing to relay TBID1 somehow, unless I'm missing something.

> referred to TP4 (in addition to conveying TBID2).

actually, conveying TBID3 to TP4 is optional IMV and one would only need to do it if TP4 is also minting other bound sec tokens eg cookies with TBID3 in 'em.

Also, it is TBID1 that actually needs to be referred, in order to properly issue the ID Token. The remark in (the old) figure 1 wrt "somehow conveys TBID2 ?" is simply a reference to Dirk's comments where he suggested that that is what we'd do here. See updated figure 1a below.

> in step 2b are attacker controlled.

agreed with the above except that it is TBID1 that really needs to be conveyed to ultimately to TP4 in order for the latter to correctly issue the OIDC ID Token, or SAML assertion or whatever, at the fed layer.

> token binding (even on repeated redirects) gives us all we need.

I agree it is "all we need" _if_ we are saying that it is out-of-scope for HTTPSTB to specify how, in a multi-redirect scenario such as fig 1a, for the correct referred TBID to be conveyed to the TC's point-of-handoff-to-TP, and similarly out-of-scope for any redirects among TP entities per HTTPSTB spec (i.e., they figger it out themselves).

I.e., we _can_ say the above I think -- tho some may perceive it as sub-optimal to just leave it unspecified -- but it may not be that big a deal, I don't know. (federation folk please speak up here !)

We could devise some means of signaling in the HTTPSTB header field layer from TC-to-TC and TP-to-TP what the correct TBID to use is (hm, it will require integrity protection from the postulated MITMs) and that might save the fed layer folks from inventing disjoint ways to do it (and hm, however they do it will need integrity protection)...

HTH,

=JeffH
------

[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%7c56925ca7269148bfed5608d355277faf%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5rnrk2pXiOfdaiKsWiEsKAtKaL6GnvKDlPcsKUR0bCA%3d>