Subject: [Unbearable] Referred token binding IDs

From: Nick Harper <[email-masked]>
Date: Mon, 7 Mar 2016 16:24:59 -0800

If a client receives an "Include-Referer-Token-Binding-ID" header in
response to a request that already had a referred TBID in the
TokenBindingMessage, should it include both of those TBIDs as referred
TBIDs in the next request?

I.e.
- client sends request to server A w/ provided TBID A
- gets back Include-Referer-Token-Binding-ID header on a redirect to B
- client sends request to B w/ provided TBID B, referred TBID A
- gets back Include-Referer-Token-Binding-ID header on a redirect to C
Possible behaviors:
i) client sends request to C w/ provided TBID C, referred TBID B, referred
TBID A
ii) client sends request to C w/ provided TBID C, referred TBID B
iii) client sends request to C w/ provided TBID C, referred TBID A,
referred TBID B

I don't know what a use case for this situation might be, but the spec
seems unclear to me on what to do. Option (i) seems most likely, followed
by option (ii). One potential way this might happen is if an identity
provider changes the URL for their endpoint that generates tokens and sets
up a redirect from the old URL to the new URL. In that case, option (ii)
wouldn't work because both B and C are the IdP.

---

From: "Hodges, Jeff" <[email-masked]>
Date: Tue, 8 Mar 2016 22:43:27 +0000

On 3/7/16, 4:24 PM [email-masked]> wrote:
>i) client sends request to C w/ provided TBID C, referred TBID B,
>referred TBID A
>by option (ii). 

>One potential way this might happen is if an identity provider changes
>the URL for their endpoint that generates tokens and sets up a redirect
>from the old URL to the new URL. In that case, option (ii) wouldn't work
>because both B and C are the IdP.

In this latter case it seems all C needs in the TBMsg, if it is just going
to redirect back to A with an "id token w/TBID A", is {provided TBID C,
referred TBID A}, yes?

though, as presently specified in -tokbind-https, there's no way for B to
signal to the client that the client needs to present TBID A to C as
'referred' rather than presenting TBID B as referred. Also, presently,
-tokbind-protocol-04 does not indicate there's any particular ordering of
TokenBinding structs within TBMsg. It's offhand plausible for the client
to just keep appending referred TBIDs to the TBMsg, and whichever entity
is the ultimate "token provider" to incorporate the correct (i.e.,
"first") referred TBID in whatever federation token it is issuing, but
then there'd be the chance for some sort of "redirect loop" (either
accidentally or maliciously) and having a size-unbounded TBMsg.

perhaps a way to create the necessary signaling is: instead of just a
boolean, the Include-Referer-Token-Binding-ID header field could convey
the TBID to be referred? i.e., in the above use case, B knows that it
isn't the present Token Provider, and can be configured to indicate to the
client which TBID to include in the TBMsg to C as "referred" (which in
this case is TBID A)...?

perhaps we need to have folks familiar with actual federated ID
deployments (such as the tokbind wg chairs :)  hold forth on the sorts of
use cases they are aware of that -tokbind-https doesn't (yet) address, but
perhaps should at least mention and maybe at least provide some guidance
about?  

HTH, 

=JeffH

---

From: Andrei Popov <[email-masked]>
Date: Tue, 8 Mar 2016 23:02:43 +0000

The current HTTPSTB says: 
" The TokenBindingMessage SHOULD contain a TokenBinding with
   TokenBindingType referred_token_binding.  If included, this
   TokenBinding MUST be signed with the Token Binding key used by the
   client for connections between itself and the Token Consumer...

   As described above, the TokenBindingMessage MUST additionally contain
   a Provided Token Binding ID..."

Based on the above, currently only option ii) exists. Dirk, please correct me if I'm wrong, but I believe this means that IDP C would generate a token for IDP B, which would then generate a token for RP A. HTTPSTB does not explicitly discuss multiple-redirect scenarios (perhaps we should add some language).

> Also, presently,
> -tokbind-protocol-04 does not indicate there's any particular ordering of TokenBinding structs within TBMsg.

>From the TBPROTO perspective, there should be at least one binding in the TB message, no other constraints on TB type or ordering. The idea is for the basic protocol to accommodate cases other than HTTPS-style federation.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Hodges, Jeff
Sent: Tuesday, March 8, 2016 2:43 PM
To: Nick Harper <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Referred token binding IDs

On 3/7/16, 4:24 PM [email-masked]> wrote:
>seems unclear to me on what to do. Option (i) seems most likely, 
>followed by option (ii).

>from the old URL to the new URL. In that case, option (ii) wouldn't 
>work because both B and C are the IdP.

In this latter case it seems all C needs in the TBMsg, if it is just going to redirect back to A with an "id token w/TBID A", is {provided TBID C, referred TBID A}, yes?

though, as presently specified in -tokbind-https, there's no way for B to signal to the client that the client needs to present TBID A to C as 'referred' rather than presenting TBID B as referred. Also, presently,
-tokbind-protocol-04 does not indicate there's any particular ordering of TokenBinding structs within TBMsg. It's offhand plausible for the client to just keep appending referred TBIDs to the TBMsg, and whichever entity is the ultimate "token provider" to incorporate the correct (i.e.,
"first") referred TBID in whatever federation token it is issuing, but then there'd be the chance for some sort of "redirect loop" (either accidentally or maliciously) and having a size-unbounded TBMsg.

perhaps a way to create the necessary signaling is: instead of just a boolean, the Include-Referer-Token-Binding-ID header field could convey the TBID to be referred? i.e., in the above use case, B knows that it isn't the present Token Provider, and can be configured to indicate to the client which TBID to include in the TBMsg to C as "referred" (which in this case is TBID A)...?

perhaps we need to have folks familiar with actual federated ID deployments (such as the tokbind wg chairs :)  hold forth on the sorts of use cases they are aware of that -tokbind-https doesn't (yet) address, but perhaps should at least mention and maybe at least provide some guidance about?  

HTH, 

=JeffH

_______________________________________________
Unbearable mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c29ccc4b816964749c50708d347a3156f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UfJy3GD5cEOSaRSMQzxoHYzR2JPv0RHmtHam4ijqqE4%3d

---

From: "Hodges, Jeff" <[email-masked]>
Date: Fri, 11 Mar 2016 21:57:37 +0000

On 3/8/16, 3:02 PM, "Andrei Popov" <[email-masked]<mailto:[email-masked]>> wrote:

Based on the above, currently only option ii) exists.

Well, what you are asserting above is only implied by the text and the redirect pattern: the text does not say anything explicit about how many TokenBindingMessage.TokenBinding's of which type may be present in a given TokenBindingMessage. I.e. it does not explicitly say to create a new  TokenBindingMessage containing only two TokenBindings when the client follows a redirect response containing the Include-Referer-Token-Binding-ID response header field (as opposed to adding a TokenBinding to the TokenBindingMessage its been using).

Dirk, please correct me if I'm wrong, but I believe this means that IDP C would generate a token for IDP B, which would then generate a token for RP A.

Not necessarily -- the message exchange pattern is overall governed by the federation protocol profile in use, as are the roles of the sending/receiving entities, and it's all subject to how a deployment is configured in actuality:  i.e., Nick's scenario of an IDP changing the URL for their security token generation endpoint is plausible. Plus, the "return address" for the IDP to redirect to, in order to deliver the generated security token, is typcially specified in the fed protocol's authn request message (which is generated by A) and typically will point back to A (ie not B).  [ saml: AssertionConsumerServiceURL, see S 3.4.1 in [1]; OIDC: redirect_uri, see S 3.1.2.1 in [2] ]

thus I continue to think that the flexibility in fed protocols (and their deployments) requires a bit more flexibility in -tokbind-https's mechanism, we should think about adding an explicit signal from server to client wrt which TBID is to be referred.

[1] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
[2] http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

HTTPSTB does not explicitly discuss multiple-redirect scenarios (perhaps we should add some language).

Also, presently,

>From the TBPROTO perspective, there should be at least one binding in the TB message, no other constraints on TB type or ordering. The idea is for the basic protocol to accommodate cases other than…

agreed wrt TBPROTO.

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Hodges, Jeff
Sent: Tuesday, March 8, 2016 2:43 PM
To: Nick Harper <[email-masked]<mailto:[email-masked]>>
Cc: IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] Referred token binding IDs

On 3/7/16, 4:24 PM [email-masked]<mailto:[email-masked]>> wrote:

I.e.

HTH,

=JeffH

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

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 11 Mar 2016 22:42:15 +0000

Sorry for chiming in late. The intended semantics in the current spec is
ii).

I believe that covers all the use cases that you're describing: Let's first
consider the case where there is one Relying Party, and one Identity
Provider. The RP might go through a bunch of redirects before ultimately
handing things off to the IdP, and the IdP might go through a bunch of
redirects before ultimately handling the RP request. Same on the way back
from the IdP to the RP.

The one redirect where the referred token binding is necessary is the
redirect that crosses functional boundaries: from the RP to the IdP. If the
first endpoint at the IdP isn't the one that is processing the RP request
(because, say, it's the old one and it's now redirecting to the new one),
that endpoint needs to encode the information it learns (i.e., what is the
public key that the client is using with the RP) in some way (which can be
proprietary to the IdP) and pass that along as the request is handed off.

On the way back, after the IdP redirects back to the RP, the RP just needs
to make sure that one of the endpoints in the redirect chain is on the same
eTLD+1 as the endpoint that did the hand-off to the IdP, so it can process
the IdP response there.

Next, let's consider what happens if there are multiple IdP's involved, say
something like rp.com -> identity-as-a-service.com -> idp.com. In that
case, identity-as-a-service.com acts like an IdP to rp.com, and as an RP to
idp.com, so we play the game described above twice. It wouldn't make sense
here if idp.com somehow knew what public key the client is using with rp.com
- it's useless information. In a scenario like this, idp.com needs to
strongly authenticate the client to identity-as-a-service.com, not to rp.com
.

Does this make sense?

Dirk.

On Fri, Mar 11, 2016 at 1:57 PM Hodges, Jeff <[email-masked]> wrote:

> On 3/8/16, 3:02 PM, "Andrei Popov" <[email-masked]> wrote:
>
> Well, what you are asserting above is only implied by the text and the
> redirect pattern: the text does not say anything explicit about how many
> TokenBindingMessage.TokenBinding's of which type may be present in a given
> TokenBindingMessage. I.e. it does not explicitly say to create a new
>  TokenBindingMessage containing only two TokenBindings when the client
> follows a redirect response containing the Include-Referer-Token-Binding-ID
> response header field (as opposed to adding a TokenBinding to the
> TokenBindingMessage its been using).
>
>
> Dirk, please correct me if I'm wrong, but I believe this means that IDP C
> would generate a token for IDP B, which would then generate a token for RP
> A.
>
>
> Not necessarily -- the message exchange pattern is overall governed by the
> federation protocol profile in use, as are the roles of the
> sending/receiving entities, and it's all subject to how a deployment is
> configured in actuality:  i.e., Nick's scenario of an IDP changing the
> URL for their security token generation endpoint is plausible. Plus, the
> "return address" for the IDP to redirect to, in order to deliver the
> generated security token, is typcially specified in the fed protocol's
> authn request message (which is generated by A) and typically will point
> back to A (ie not B).  [ saml: AssertionConsumerServiceURL, see S 3.4.1
> in [1]; OIDC: redirect_uri, see S 3.1.2.1 in [2] ]
>
> thus I continue to think that the flexibility in fed protocols (and their
> deployments) requires a bit more flexibility in -tokbind-https's mechanism,
> we should think about adding an explicit signal from server to client wrt
> which TBID is to be referred.
>
>
> TokenBinding structs within TBMsg.
>
>
> From the TBPROTO perspective, there should be at least one binding in the
> TB message, no other constraints on TB type or ordering. The idea is for
> the basic protocol to accommodate cases other than HTTPS-style federation.
>
>
> agreed wrt TBPROTO.
>
>
>
> From: Unbearable [mailto:[email-masked]
> <[email-masked]>] On Behalf Of Hodges, Jeff
> TokenBinding structs within TBMsg. It's offhand plausible for the client to
> just keep appending referred TBIDs to the TBMsg, and whichever entity is
> the ultimate "token provider" to incorporate the correct (i.e.,
> boolean, the Include-Referer-Token-Binding-ID header field could convey the
> TBID to be referred? i.e., in the above use case, B knows that it isn't the
> present Token Provider, and can be configured to indicate to the client
> which TBID to include in the TBMsg to C as "referred" (which in this case
> is TBID A)...?
>

---

From: Nick Harper <[email-masked]>
Date: Fri, 11 Mar 2016 14:45:01 -0800

Yes, that all makes sense.

On Fri, Mar 11, 2016 at 2:42 PM, Dirk Balfanz <[email-masked]> wrote:

> I believe that covers all the use cases that you're describing: Let's
> first consider the case where there is one Relying Party, and one Identity
> Next, let's consider what happens if there are multiple IdP's involved,
> say something like rp.com -> identity-as-a-service.com -> idp.com. In
> that case, identity-as-a-service.com acts like an IdP to rp.com, and as
> an RP to idp.com, so we play the game described above twice. It wouldn't
> make sense here if idp.com somehow knew what public key the client is
> using with rp.com - it's useless information. In a scenario like this,
> idp.com needs to strongly authenticate the client to
> identity-as-a-service.com, not to rp.com.
>
> Does this make sense?
>
> Dirk.
>
>
>> Not necessarily -- the message exchange pattern is overall governed by
>> the federation protocol profile in use, as are the roles of the
>> In this latter case it seems all C needs in the TBMsg, if it is just
>> going to redirect back to A with an "id token w/TBID A", is {provided TBID
>> C, referred TBID A}, yes?
>>
> https://www.ietf.org/mailman/listinfo/unbearable
>
>