Subject: [Unbearable] migrations of token bindings

From: Subodh Iyengar <[email-masked]>
Date: Tue, 2 Aug 2016 23:47:26 +0000

Davidben and I were chatting during IETF Berlin about token bindings and we discussed some interesting issues around token bindings and migrations.

2 cases come to my mind:
* For example let's say Server 1 negotiates key parameters ecdsa and establishes a token binding with ecdsa params, however the relying party for a referred token binding only supports pkcs1.5.

* A new token binding type is added for example eddsa and the server wants to migrate it's existing ecdsa token binding to an eddsa token binding.

One way to migrate token bindings comes to mind but it's super nasty. For example let's say Server 1 runs on origin server.com which has the original bindings. You could have Server 1 create a new domain migration.server.com (which supports both ecdsa and pkcs1.5) and then server.com could 302 to migration.server.com with a referred token binding. This is really painful to migrate and probably impractical for many services.

However I think there might be a more elegant solution. One proposal could be to change the server token binding extension to be allowed to specify multiple supported token bindings instead of requiring just one. This will allow the server to negotiate not only ecdsa but also pkcs1.5 token bindings and store them together. This would make migration easier. For example if server only supported ecdsa initially and had token binding id = A initially, and needed to support a new party which supported pkcs1.5, it would advertise support for both. Then the client would send it 2 bindings A and B which it can store together.

Has this problem been discussed before?

Subodh

---

From: Nick Harper <[email-masked]>
Date: Tue, 2 Aug 2016 17:26:53 -0700

On Tue, Aug 2, 2016 at 4:47 PM, Subodh Iyengar <[email-masked]> wrote:

> Davidben and I were chatting during IETF Berlin about token bindings and
> we discussed some interesting issues around token bindings and migrations.
>
> 2 cases come to my mind:
> * For example let's say Server 1 negotiates key parameters ecdsa and
> establishes a token binding with ecdsa params, however the relying party
> for a referred token binding only supports pkcs1.5.
>

I agree that current negotiation mechanisms are probably not enough for a
client to know if a relying party will accept a referred token binding that
is sent in an environment with diversity of key types. (I hope there are no
servers that are only going to support pkcs1v1.5 - they should at least
support pss if they're doing rsa.)

>
> * A new token binding type is added for example eddsa and the server wants
> to migrate it's existing ecdsa token binding to an eddsa token binding.
>
> One way to migrate token bindings comes to mind but it's super nasty. For
> example let's say Server 1 runs on origin server.com which has the
> original bindings. You could have Server 1 create a new domain
> migration.server.com (which supports both ecdsa and pkcs1.5) and then
> server.com could 302 to migration.server.com with a referred token
> binding. This is really painful to migrate and probably impractical for
> many services.
>

For this to work, migration.server.com would have to support ecdsa and rsa,
but not advertise support for ecdsa. Otherwise, the client would send an
ecdsa key as the provided key for migration.server.com (and as the referred
key to the relying party that only supports rsa).

>
> However I think there might be a more elegant solution. One proposal could
> be to change the server token binding extension to be allowed to specify
> multiple supported token bindings instead of requiring just one. This will
> allow the server to negotiate not only ecdsa but also pkcs1.5 token
> bindings and store them together. This would make migration easier. For
> example if server only supported ecdsa initially and had token binding id =
> A initially, and needed to support a new party which supported pkcs1.5, it
> would advertise support for both. Then the client would send it 2 bindings
> A and B which it can store together.
>

This sounds like an interesting idea, but I'm concerned that it would
require a client to always compute and send as many signatures as are in
the set of key types the client supports intersected with the key types the
server supports (I imagine this set would start off looking like [pss,
p256], and at some point in the future [pss, p256, Ed25519]). Perpetually
requiring the client to compute and send multiple signatures which have the
same purpose sounds like a waste of computation and bandwidth. If the
requirement is loosened that a client send all signatures that both it and
the server support, then I could imagine a client would never want to use a
new key with that server unless the server drops support for the old key
type.

> Has this problem been discussed before?

There was some discussion in the past,
https://mailarchive.ietf.org/arch/msg/unbearable/RCQpBN0_b-jotGlSJisFUh_K54g
is an example.

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

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 3 Aug 2016 00:37:11 +0000

> For this to work, migration.server.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=> would have to support ecdsa and rsa, but not advertise support for ecdsa. Otherwise, the client would send an ecdsa key as the provided key for migration.server.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=> (and as the referred key to the relying party that only supports rsa).

This is an interesting point. If the migration server would not advertise support for ECDSA, then I think the referred token binding (which would be ecdsa) would probably not be sent, or rather I'm not sure what happens with the referred token binding with a key param which is not negotiated. This was meant to be a strawman solution, and thinking about it again this would probably not work.

>This sounds like an interesting idea, but I'm concerned that it would require a client to always compute and send as many signatures as are in the set of key types the client supports intersected with the key types the server supports

Ya I think this is a tradeoff here. I imagine that this would happen, at least in our case, only when we need to do a migration. In absence of another practical solution (Does one exist?), it seems reasonable to retain this flexibility. The server would probably stop advertising support once it's done with the migration.

Subodh
________________________________
From: Nick Harper [[email-masked]]
Sent: Tuesday, August 02, 2016 5:26 PM
To: Subodh Iyengar
Cc: [email-masked]
Subject: Re: [Unbearable] migrations of token bindings

On Tue, Aug 2, 2016 at 4:47 PM, Subodh Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
Davidben and I were chatting during IETF Berlin about token bindings and we discussed some interesting issues around token bindings and migrations.

2 cases come to my mind:

I agree that current negotiation mechanisms are probably not enough for a client to know if a relying party will accept a referred token binding that is sent in an environment with diversity of key types. (I hope there are no servers that are only going to support pkcs1v1.5 - they should at least support pss if they're doing rsa.)

One way to migrate token bindings comes to mind but it's super nasty. For example let's say Server 1 runs on origin server.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=JY8OTOqhlgLpvTOoCZYcT4cCI1robvKQ-cB2q2GjBLI&e=> which has the original bindings. You could have Server 1 create a new domain migration.server.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=> (which supports both ecdsa and pkcs1.5) and then server.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=JY8OTOqhlgLpvTOoCZYcT4cCI1robvKQ-cB2q2GjBLI&e=> could 302 to migration.server.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=> with a referred token binding. This is really painful to migrate and probably impractical for many services.

For this to work, migration.server.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=> would have to support ecdsa and rsa, but not advertise support for ecdsa. Otherwise, the client would send an ecdsa key as the provided key for migration.server.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=> (and as the referred key to the relying party that only supports rsa).

This sounds like an interesting idea, but I'm concerned that it would require a client to always compute and send as many signatures as are in the set of key types the client supports intersected with the key types the server supports (I imagine this set would start off looking like [pss, p256], and at some point in the future [pss, p256, Ed25519]). Perpetually requiring the client to compute and send multiple signatures which have the same purpose sounds like a waste of computation and bandwidth. If the requirement is loosened that a client send all signatures that both it and the server support, then I could imagine a client would never want to use a new key with that server unless the server drops support for the old key type.

There was some discussion in the past, https://mailarchive.ietf.org/arch/msg/unbearable/RCQpBN0_b-jotGlSJisFUh_K54g<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_unbearable_RCQpBN0-5Fb-2DjotGlSJisFUh-5FK54g&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=-BzyuK3nIcfvdGEHm103hlrsACTXF5S5lkjnYe8K0zc&e=> is an example.

Subodh

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_unbearable&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=vj6DM8ZE0Y4ytQUgW_wMtOExAjogUU6BVbmFUMeQD2w&e=>

---

From: Nick Harper <[email-masked]>
Date: Tue, 2 Aug 2016 17:54:43 -0700

On Tue, Aug 2, 2016 at 5:37 PM, Subodh Iyengar <[email-masked]> wrote:

> > For this to work, migration.server.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=> would
> have to support ecdsa and rsa, but not advertise support for ecdsa.
> Otherwise, the client would send an ecdsa key as the provided key for
> migration.server.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=> (and
> as the referred key to the relying party that only supports rsa).
>
>>
> This is an interesting point. If the migration server would not advertise
> support for ECDSA, then I think the referred token binding (which would be
> ecdsa) would probably not be sent, or rather I'm not sure what happens with
> the referred token binding with a key param which is not negotiated. This
> was meant to be a strawman solution, and thinking about it again this would
> probably not work.
>

My assumption is that a client sends a referred token binding if the
referer indicates to do so, and no consideration is given to what the
relying party supports compared to the key type of the referred TB.

> server supports
> Ya I think this is a tradeoff here. I imagine that this would happen, at
> least in our case, only when we need to do a migration. In absence of
> another practical solution (Does one exist?), it seems reasonable to retain
> this flexibility. The server would probably stop advertising support once
> it's done with the migration.
>

I think some sort of migration negotiation would require more bits of
information to be sent, like the client indicating which types it has keys
for, or the server requesting the client to make a key of a particular
type. I think an ideal solution would require no server state and no client
state past the key store (a table of eTLD+1s, key types, and keys, i.e. no
"migration in progress" bit). An ideal solution would also involve only one
connection with multiple keys in use at the same time (or even better, some
application layer signaling so only one request has both keys in use at the
same time).

I'm doubtful such a thing even exists. Suppose a server runs example.com
and supersecret.example.com, with supersecret.example.com setting some
cookies that are restricted to that domain. Cookies for both example.com
and supersecret.example.com will be bound to the same token binding key K1.
If we do some song-and-dance on a connection to example.com to migrate from
K1 to K2, that will only migrate the bindings for the example.com cookies -
the supersecret.example.com cookies will still be bound to K1. (I'm
assuming that the cookie has some encrypted and integrity-protected
identifier for the token binding key in it, instead of it being some sort
of server-side lookup.)

>
> Subodh
> ------------------------------
> *From:* Nick Harper [[email-masked]]
> *Sent:* Tuesday, August 02, 2016 5:26 PM
> *To:* Subodh Iyengar
> *Cc:* [email-masked]
> *Subject:* Re: [Unbearable] migrations of token bindings
>
>
>
>> * A new token binding type is added for example eddsa and the server
>> wants to migrate it's existing ecdsa token binding to an eddsa token
>> binding.
>>
>> example let's say Server 1 runs on origin server.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=JY8OTOqhlgLpvTOoCZYcT4cCI1robvKQ-cB2q2GjBLI&e=>
>> which has the original bindings. You could have Server 1 create a new
>> domain migration.server.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=>
>> (which supports both ecdsa and pkcs1.5) and then server.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=JY8OTOqhlgLpvTOoCZYcT4cCI1robvKQ-cB2q2GjBLI&e=>
>> could 302 to migration.server.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=>
>> with a referred token binding. This is really painful to migrate and
>> probably impractical for many services.
>>
>
> For this to work, migration.server.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=>
> would have to support ecdsa and rsa, but not advertise support for ecdsa.
> Otherwise, the client would send an ecdsa key as the provided key for
> migration.server.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__migration.server.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=B5FseuF5uGV_rxNfzdrtUlYmPsKz3phiSo5w5PnWGOA&e=>
> (and as the referred key to the relying party that only supports rsa).
>
>>
>> However I think there might be a more elegant solution. One proposal
>> could be to change the server token binding extension to be allowed to
>> specify multiple supported token bindings instead of requiring just one.
>> This will allow the server to negotiate not only ecdsa but also pkcs1.5
>> token bindings and store them together. This would make migration easier.
>> For example if server only supported ecdsa initially and had token binding
>> id = A initially, and needed to support a new party which supported
>> pkcs1.5, it would advertise support for both. Then the client would send it
>> 2 bindings A and B which it can store together.
>>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_unbearable_RCQpBN0-5Fb-2DjotGlSJisFUh-5FK54g&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=-BzyuK3nIcfvdGEHm103hlrsACTXF5S5lkjnYe8K0zc&e=>
> is an example.
>
>>
>> Subodh
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_unbearable&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=NyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=vj6DM8ZE0Y4ytQUgW_wMtOExAjogUU6BVbmFUMeQD2w&e=>
>>
>>
>

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 3 Aug 2016 01:36:46 +0000

> An ideal solution would also involve only one connection with multiple keys in use at the same time (or even better, some application layer signaling so only one request has both keys in use at the same time).

I think there might be a confusion here. The suggested proposal is to have the server say I support pkcs and ecdsa and then the client would send bindings with both ids. During a migration from K1 -> K2 bindings both the ids, old and new, would automatically be in the token binding message. Isn't that exactly what you're asking for?

There are 2 cases here:
1. Migrating from K1 -> K2 which share the same type
2. Migrating from K1 -> K2 which share different types.

(1) is possible even in the current spec because the client can send multiple bindings for the same type.
(2) is not possible in the current spec (I think), hence the proposal.

The token binding cookie would be changed to contain signed(token || K2) when the server validates K1 was correct and a new cookie would be set.  So I don't think additional client or server state is required, just the token would be changed.

>I think some sort of migration negotiation would require more bits of information to be sent, like the client indicating which types it has keys for, or the server requesting the client to make a key of a particular type

I don't think any addition migration in progress state is required. The state of migrations is usually monitored via backed logging of requests and observing how many requests have K2 and K1 vs K1 only (This could technically be considered state, but not in the sense of state that servers need to track strictly for correct operation).

> If we do some song-and-dance on a connection to example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=8hsP4pNCn6DWjYiI8EO_j8tGufhYZzeNkUQHhsdDE_k&e=> to migrate from K1 to K2, that will only migrate the bindings for the example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=8hsP4pNCn6DWjYiI8EO_j8tGufhYZzeNkUQHhsdDE_k&e=> cookies - the supersecret.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__supersecret.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=CvdSmMOHZLeG_7sxPwJcyWiULP8Fn4N8ktNnESndzNA&e=> cookies will still be bound to K1.
The supersecret cookies (specific to supersecret) would also go through the same song and dance of example.com. The first time someone hits supersecret after someone has decided they need to start migrating, they would get the new cookie with the new token binding.

Migration is not be the only case though. There are also cases where both might need to be supported simultaneously forever. For example you want to talk to an identity provider that supports pkcs1.5 only and you only care about ecdsa bindings for your own site. I hope that doesn't happen with pkcs1.5, however in the future this might happen with eddsa where you might want to start binding to curve25519 ids while providers are stuck with ecdsa bindings.

Subodh
________________________________
From: Nick Harper [[email-masked]]
Sent: Tuesday, August 02, 2016 5:54 PM
To: Subodh Iyengar
Cc: [email-masked]
Subject: Re: [Unbearable] migrations of token bindings

My assumption is that a client sends a referred token binding if the referer indicates to do so, and no consideration is given to what the relying party supports compared to the key type of the referred TB.

I think some sort of migration negotiation would require more bits of information to be sent, like the client indicating which types it has keys for, or the server requesting the client to make a key of a particular type. I think an ideal solution would require no server state and no client state past the key store (a table of eTLD+1s, key types, and keys, i.e. no "migration in progress" bit). An ideal solution would also involve only one connection with multiple keys in use at the same time (or even better, some application layer signaling so only one request has both keys in use at the same time).

I'm doubtful such a thing even exists. Suppose a server runs example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=8hsP4pNCn6DWjYiI8EO_j8tGufhYZzeNkUQHhsdDE_k&e=> and supersecret.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__supersecret.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=CvdSmMOHZLeG_7sxPwJcyWiULP8Fn4N8ktNnESndzNA&e=>, with supersecret.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__supersecret.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=CvdSmMOHZLeG_7sxPwJcyWiULP8Fn4N8ktNnESndzNA&e=> setting some cookies that are restricted to that domain. Cookies for both example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=8hsP4pNCn6DWjYiI8EO_j8tGufhYZzeNkUQHhsdDE_k&e=> and supersecret.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__supersecret.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=CvdSmMOHZLeG_7sxPwJcyWiULP8Fn4N8ktNnESndzNA&e=> will be bound to the same token binding key K1. If we do some song-and-dance on a connection to example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=8hsP4pNCn6DWjYiI8EO_j8tGufhYZzeNkUQHhsdDE_k&e=> to migrate from K1 to K2, that will only migrate the bindings for the example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=8hsP4pNCn6DWjYiI8EO_j8tGufhYZzeNkUQHhsdDE_k&e=> cookies - the supersecret.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__supersecret.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=1XYchNa26pSjBLR6WtUm1CkOMH20e1wfvxsmIAKjP_o&s=CvdSmMOHZLeG_7sxPwJcyWiULP8Fn4N8ktNnESndzNA&e=> cookies will still be bound to K1. (I'm assuming that the cookie has some encrypted and integrity-protected identifier for the token binding key in it, instead of it being some sort of server-side lookup.)

Subodh
________________________________
From: Nick Harper [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, August 02, 2016 5:26 PM
To: Subodh Iyengar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Unbearable] migrations of token bindings

2 cases come to my mind:

Subodh

---

From: Nick Harper <[email-masked]>
Date: Wed, 3 Aug 2016 18:04:06 -0700

I chatted with Subodh offline about how to do key migrations for Token
Binding. We came up with the following as a potential change to be able to
support migrating from one key type to another.

When a client sends the Token Binding negotiation TLS extension, it
includes with each key type whether or not it has a key of that type.

Upon receipt of that extension, the server consults its list of supported
key types in preference order (and filters it based on what the client
sent). The server puts one or two values in its key_parameters_list: The
key type at the top of the filtered list, and the highest key type on the
filtered list that a client has a key for (these will be the same thing in
most cases, in which case the server sends only one value). If the server
sends two values, it must do so in this order (to indicate to the client
what the server's preference is).

When a client receives two values in the key_parameters_list from the
server, the client generates a TokenBindingMessage with two provided
TokenBindings. (This means that the client is generating a new keypair for
one of the token bindings.) Once the client receives a successful response
to the application layer request that contained that TokenBindingMessage
(e.g. a 2xx or 3xx HTTP response for a request with a Sec-Token-Binding
header), the client may discard the key of the type that was not first in
the server's key_parameters_list.

When a server receives a TokenBindingMessage with two provided
TokenBindings, it must rebind the tokens sent by the client to be bound to
the new key (this is identified as the key of the type that the server has
ranked higher on its preference list).

There is also some implementation guidance for client HTTPS Token Binding
implementations. Since the same Token Binding key is used for all origins
on an eTLD+1, but a request to one origin might only contain some of the
tokens on that eTLD+1, the client needs to keep track of which keys for the
eTLD+1 are used on which origins, and make sure that a key is not discarded
until it is no longer used on any of the origins for that eTLD+1.
Furthermore, if a key of a type T for an eTLD+1 has never been presented to
a particular origin in that eTLD+1, the client must not indicate that it
has a key of type T in the negotiation extension.

This client side complication is to handle the scenario of multiple
subdomains on an eTLD+1 which have different cookies. Consider a client and
server that support key types T1 and T2 (with T2 preferred over T1), and a
client that currently only has key K1 (of type T1) for multiple domains on
that server. The client and server both wish to migrate to a new key K2 of
type T2. In this example, the server runs foo.example.com and
bar.example.com, which have different cookies.
1. Client sends negotiation extension with (T1, true) and (T2, false) when
connecting to foo.example.com. Server responds with T2, T1.
2. Client generates new key K2 of type T2 for eTLD+1 example.com, no
origin. (K1 is in the key store for eTLD+1 example.com, origins
foo.example.com, bar.example.com.)
3. Client sends Sec-Token-Binding header with K1 and K2 as provided token
bindings; server responds with a 2xx or 3xx response code.
4. Client updates key store so K2 has origin foo.example.com and K1 no
longer has that origin (it only has bar.example.com listed as its origin).
Now, on future connections, the client can send a negotiation extension
with (T1, false), (T2, true) to foo.example.com, and foo.example.com will
only send back T2.
Note that when the client is deciding whether or not to indicate it has a
key of a particular type, it is checking for a key of that type for that
origin, and not for that eTLD+1.
When the server connects to bar.example.com, it continues as follows:
5. Client sends negotiation extension with (T1, true), (T2, false), and
bar.example.com responds with T2, T1.
6. Client sends Sec-Token-Binding header with K1 and K2 as provided token
bindings; server responds with 2xx or 3xx response code.
7. Client updates key store to add bar.example.com as an origin for K2, and
remove bar.example.com as an origin for K1.
8. Client sees that K1 has no more origins, and removes it from the key
store.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 12:38:29 +1000

> ranked higher on its preference list).

What about those tokens that require a third-party to authenticate them?

See also the discussion in ACME regarding the migration of keys.
There's an attack that is described there if you just have independent
signatures.  See
https://mailarchive.ietf.org/arch/msg/acme/-HKly8leUaA_TT6r0mgIkoX52tM

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 8 Aug 2016 18:17:14 +0000

By authenticate them do you me validate their authenticity ? or something different?

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Sunday, August 7, 2016 7:38 PM
To: Nick Harper <[email-masked]>
Cc: [email-masked]; Subodh Iyengar <[email-masked]>
Subject: Re: [Unbearable] migrations of token bindings

On 4 August 2016 at 11:04, Nick Harper <[email-masked]> wrote:
> TokenBindings, it must rebind the tokens sent by the client to be 
> bound to the new key (this is identified as the key of the type that 
> the server has ranked higher on its preference list).

See also the discussion in ACME regarding the migration of keys.
There's an attack that is described there if you just have independent signatures.  See https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmailarchive.ietf.org%2farch%2fmsg%2facme%2f-HKly8leUaA_TT6r0mgIkoX52tM&data=02%7c01%7ctonynad%40microsoft.com%7c216ab9b6547543d4e14408d3bf3518e3%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062207174411173&sdata=bgh22PzOsrFYNdc8sPpitadlucMFqhoULpahKhWHvxI%3d

_______________________________________________
Unbearable mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=02%7c01%7ctonynad%40microsoft.com%7c216ab9b6547543d4e14408d3bf3518e3%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062207174411173&sdata=mNEd%2fw1WSac0Goj9rhina9aIV6DBeR4YN3%2b2AMjIpNA%3d

---

From: Brian Campbell <[email-masked]>
Date: Mon, 8 Aug 2016 12:40:29 -0600

I guess the question that comes to my mind is whether key migration is
something that really needs to be accommodated by the protocol.

How often will it really happen? A new key_parameters type might be
introduced every few years at the most. And even if a client were to
explicitly discard 'old' established bindings to force a change, the impact
is no worse than a user choosing to clear cookies. The authentication
context just has to be reestablished (log in again).

On Wed, Aug 3, 2016 at 7:04 PM, Nick Harper <[email-masked]> wrote:

> type T2. In this example, the server runs foo.example.com and bar.
> example.com, which have different cookies.
> 7. Client updates key store to add bar.example.com as an origin for K2,
> and remove bar.example.com as an origin for K1.

---

From: Nick Harper <[email-masked]>
Date: Mon, 8 Aug 2016 11:53:34 -0700

A related issue to migration is what should a client's behavior be if it
supports multiple key types when it has one key that it can use with a
server and is generating its negotiation extension. More concretely,
suppose a client supports PSS and P256, and has a PSS key for example.com.
When the client is connecting to example.com, should it list just PSS in
its extension, or both PSS and P256? If the client lists PSS followed by
P256 (to indicate that the client prefers PSS, since they are in preference
order), but the server prefers P256 over PSS, should the server negotiate
P256 or PSS? If the server negotiates P256, it just broke the binding it
had for any tokens because the client just made a new key. This could be
viewed as the one-time migration cost (which is a reasonable cost if it
happens only one time), but now imagine that example.com is served by
multiple servers that are slowly rolling out the preference change of
preferring P256 over PSS, and the client is bouncing between servers that
prefer one over the other. Now this "one-time" migration happens every time
the client hits a server that has a different preference list compared to
the previous server.

On Mon, Aug 8, 2016 at 11:40 AM, Brian Campbell <[email-masked]>
wrote:

>> type T2. In this example, the server runs foo.example.com and bar.e
>> xample.com, which have different cookies.
>> 1. Client sends negotiation extension with (T1, true) and (T2, false)
>> when connecting to foo.example.com. Server responds with T2, T1.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 8 Aug 2016 19:17:30 +0000

Is the ability to re-bind tokens to a different key type without reauthentication an important requirement? This increases implementation complexity and computational cost (if multiple signatures are involved) and therefore is not supported in the current specs.

Ø  When the client is connecting to example.com<http://example.com>, should it list just PSS in its extension, or both PSS and P256?
The client indicates all supported TB parameters.

Ø  If the client lists PSS followed by P256 (to indicate that the client prefers PSS, since they are in preference order), but the server prefers P256 over PSS, should the server negotiate P256 or PSS?
Generally, the server should use the server’s preferences. However, there may be configurations where client preferences are honored.

From: Unbearable [mailto:[email-masked]] On Behalf Of Nick Harper
Sent: Monday, August 8, 2016 11:54 AM
To: Brian Campbell <[email-masked]>
Cc: [email-masked]; Subodh Iyengar <[email-masked]>
Subject: Re: [Unbearable] migrations of token bindings

A related issue to migration is what should a client's behavior be if it supports multiple key types when it has one key that it can use with a server and is generating its negotiation extension. More concretely, suppose a client supports PSS and P256, and has a PSS key for example.com<http://example.com>. When the client is connecting to example.com<http://example.com>, should it list just PSS in its extension, or both PSS and P256? If the client lists PSS followed by P256 (to indicate that the client prefers PSS, since they are in preference order), but the server prefers P256 over PSS, should the server negotiate P256 or PSS? If the server negotiates P256, it just broke the binding it had for any tokens because the client just made a new key. This could be viewed as the one-time migration cost (which is a reasonable cost if it happens only one time), but now imagine that example.com<http://example.com> is served by multiple servers that are slowly rolling out the preference change of preferring P256 over PSS, and the client is bouncing between servers that prefer one over the other. Now this "one-time" migration happens every time the client hits a server that has a different preference list compared to the previous server.

On Mon, Aug 8, 2016 at 11:40 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
I guess the question that comes to my mind is whether key migration is something that really needs to be accommodated by the protocol.
How often will it really happen? A new key_parameters type might be introduced every few years at the most. And even if a client were to explicitly discard 'old' established bindings to force a change, the impact is no worse than a user choosing to clear cookies. The authentication context just has to be reestablished (log in again).

On Wed, Aug 3, 2016 at 7:04 PM, Nick Harper <[email-masked]<mailto:[email-masked]>> wrote:
I chatted with Subodh offline about how to do key migrations for Token Binding. We came up with the following as a potential change to be able to support migrating from one key type to another.

When a client sends the Token Binding negotiation TLS extension, it includes with each key type whether or not it has a key of that type.

Upon receipt of that extension, the server consults its list of supported key types in preference order (and filters it based on what the client sent). The server puts one or two values in its key_parameters_list: The key type at the top of the filtered list, and the highest key type on the filtered list that a client has a key for (these will be the same thing in most cases, in which case the server sends only one value). If the server sends two values, it must do so in this order (to indicate to the client what the server's preference is).

When a client receives two values in the key_parameters_list from the server, the client generates a TokenBindingMessage with two provided TokenBindings. (This means that the client is generating a new keypair for one of the token bindings.) Once the client receives a successful response to the application layer request that contained that TokenBindingMessage (e.g. a 2xx or 3xx HTTP response for a request with a Sec-Token-Binding header), the client may discard the key of the type that was not first in the server's key_parameters_list.

When a server receives a TokenBindingMessage with two provided TokenBindings, it must rebind the tokens sent by the client to be bound to the new key (this is identified as the key of the type that the server has ranked higher on its preference list).

There is also some implementation guidance for client HTTPS Token Binding implementations. Since the same Token Binding key is used for all origins on an eTLD+1, but a request to one origin might only contain some of the tokens on that eTLD+1, the client needs to keep track of which keys for the eTLD+1 are used on which origins, and make sure that a key is not discarded until it is no longer used on any of the origins for that eTLD+1. Furthermore, if a key of a type T for an eTLD+1 has never been presented to a particular origin in that eTLD+1, the client must not indicate that it has a key of type T in the negotiation extension.

This client side complication is to handle the scenario of multiple subdomains on an eTLD+1 which have different cookies. Consider a client and server that support key types T1 and T2 (with T2 preferred over T1), and a client that currently only has key K1 (of type T1) for multiple domains on that server. The client and server both wish to migrate to a new key K2 of type T2. In this example, the server runs foo.example.com<http://foo.example.com/> and bar.example.com<http://bar.example.com/>, which have different cookies.
1. Client sends negotiation extension with (T1, true) and (T2, false) when connecting to foo.example.com<http://foo.example.com/>. Server responds with T2, T1.
2. Client generates new key K2 of type T2 for eTLD+1 example.com<http://example.com/>, no origin. (K1 is in the key store for eTLD+1 example.com<http://example.com/>, origins foo.example.com<http://foo.example.com/>, bar.example.com<http://bar.example.com/>.)
3. Client sends Sec-Token-Binding header with K1 and K2 as provided token bindings; server responds with a 2xx or 3xx response code.
4. Client updates key store so K2 has origin foo.example.com<http://foo.example.com/> and K1 no longer has that origin (it only has bar.example.com<http://bar.example.com/> listed as its origin).
Now, on future connections, the client can send a negotiation extension with (T1, false), (T2, true) to foo.example.com<http://foo.example.com/>, and foo.example.com<http://foo.example.com/> will only send back T2.
Note that when the client is deciding whether or not to indicate it has a key of a particular type, it is checking for a key of that type for that origin, and not for that eTLD+1.
When the server connects to bar.example.com<http://bar.example.com/>, it continues as follows:
5. Client sends negotiation extension with (T1, true), (T2, false), and bar.example.com<http://bar.example.com/> responds with T2, T1.
6. Client sends Sec-Token-Binding header with K1 and K2 as provided token bindings; server responds with 2xx or 3xx response code.
7. Client updates key store to add bar.example.com<http://bar.example.com/> as an origin for K2, and remove bar.example.com<http://bar.example.com/> as an origin for K1.
8. Client sees that K1 has no more origins, and removes it from the key store.

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 8 Aug 2016 19:22:21 +0000

Currently we have no requirements for this feature.

From: Unbearable [mailto:[email-masked]] On Behalf Of Andrei Popov
Sent: Monday, August 8, 2016 12:18 PM
To: Nick Harper <[email-masked]>; Brian Campbell <[email-masked]>
Cc: [email-masked]; Subodh Iyengar <[email-masked]>
Subject: Re: [Unbearable] migrations of token bindings

Ø  When the client is connecting to example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fexample.com&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676896201&sdata=%2fKNcz7YyRt2rocPb%2b00JXjsL1uBIu5BOYPUCOmtZW%2bE%3d>, should it list just PSS in its extension, or both PSS and P256?
The client indicates all supported TB parameters.

From: Unbearable [mailto:[email-masked]] On Behalf Of Nick Harper
Sent: Monday, August 8, 2016 11:54 AM
To: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Subodh Iyengar <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] migrations of token bindings

A related issue to migration is what should a client's behavior be if it supports multiple key types when it has one key that it can use with a server and is generating its negotiation extension. More concretely, suppose a client supports PSS and P256, and has a PSS key for example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fexample.com&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676896201&sdata=%2fKNcz7YyRt2rocPb%2b00JXjsL1uBIu5BOYPUCOmtZW%2bE%3d>. When the client is connecting to example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fexample.com&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676896201&sdata=%2fKNcz7YyRt2rocPb%2b00JXjsL1uBIu5BOYPUCOmtZW%2bE%3d>, should it list just PSS in its extension, or both PSS and P256? If the client lists PSS followed by P256 (to indicate that the client prefers PSS, since they are in preference order), but the server prefers P256 over PSS, should the server negotiate P256 or PSS? If the server negotiates P256, it just broke the binding it had for any tokens because the client just made a new key. This could be viewed as the one-time migration cost (which is a reasonable cost if it happens only one time), but now imagine that example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fexample.com&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676896201&sdata=%2fKNcz7YyRt2rocPb%2b00JXjsL1uBIu5BOYPUCOmtZW%2bE%3d> is served by multiple servers that are slowly rolling out the preference change of preferring P256 over PSS, and the client is bouncing between servers that prefer one over the other. Now this "one-time" migration happens every time the client hits a server that has a different preference list compared to the previous server.

This client side complication is to handle the scenario of multiple subdomains on an eTLD+1 which have different cookies. Consider a client and server that support key types T1 and T2 (with T2 preferred over T1), and a client that currently only has key K1 (of type T1) for multiple domains on that server. The client and server both wish to migrate to a new key K2 of type T2. In this example, the server runs foo.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffoo.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676896201&sdata=PIuCnwrCDbSAoVUNY4IG5l1dhusz4JtMqOjWEn%2bEPMY%3d> and bar.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbar.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676896201&sdata=YfwpMcpWOQ%2b0ZDuLdjZyth%2fMVQF1P2XOZ9DAETWuqdE%3d>, which have different cookies.
1. Client sends negotiation extension with (T1, true) and (T2, false) when connecting to foo.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffoo.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676896201&sdata=PIuCnwrCDbSAoVUNY4IG5l1dhusz4JtMqOjWEn%2bEPMY%3d>. Server responds with T2, T1.
2. Client generates new key K2 of type T2 for eTLD+1 example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fexample.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=4TPZfaxfIle7ow1%2fwDv6rojpImCGsl1UzMUOMM%2f0KLg%3d>, no origin. (K1 is in the key store for eTLD+1 example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fexample.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=4TPZfaxfIle7ow1%2fwDv6rojpImCGsl1UzMUOMM%2f0KLg%3d>, origins foo.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffoo.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=CCva97vJxxttv1MA3QISnd1LuoMUJVA89ojb6YYL5rw%3d>, bar.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbar.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=%2fhKQ5ujyhW1senXQyeqibPgONeGCkGbTuTvINHhO5RA%3d>.)
3. Client sends Sec-Token-Binding header with K1 and K2 as provided token bindings; server responds with a 2xx or 3xx response code.
4. Client updates key store so K2 has origin foo.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffoo.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=CCva97vJxxttv1MA3QISnd1LuoMUJVA89ojb6YYL5rw%3d> and K1 no longer has that origin (it only has bar.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbar.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=%2fhKQ5ujyhW1senXQyeqibPgONeGCkGbTuTvINHhO5RA%3d> listed as its origin).
Now, on future connections, the client can send a negotiation extension with (T1, false), (T2, true) to foo.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffoo.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=CCva97vJxxttv1MA3QISnd1LuoMUJVA89ojb6YYL5rw%3d>, and foo.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffoo.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=CCva97vJxxttv1MA3QISnd1LuoMUJVA89ojb6YYL5rw%3d> will only send back T2.
Note that when the client is deciding whether or not to indicate it has a key of a particular type, it is checking for a key of that type for that origin, and not for that eTLD+1.
When the server connects to bar.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbar.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=%2fhKQ5ujyhW1senXQyeqibPgONeGCkGbTuTvINHhO5RA%3d>, it continues as follows:
5. Client sends negotiation extension with (T1, true), (T2, false), and bar.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbar.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=%2fhKQ5ujyhW1senXQyeqibPgONeGCkGbTuTvINHhO5RA%3d> responds with T2, T1.
6. Client sends Sec-Token-Binding header with K1 and K2 as provided token bindings; server responds with 2xx or 3xx response code.
7. Client updates key store to add bar.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbar.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=%2fhKQ5ujyhW1senXQyeqibPgONeGCkGbTuTvINHhO5RA%3d> as an origin for K2, and remove bar.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbar.example.com%2f&data=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=%2fhKQ5ujyhW1senXQyeqibPgONeGCkGbTuTvINHhO5RA%3d> as an origin for K1.
8. Client sees that K1 has no more origins, and removes it from the key store.

_______________________________________________
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=02%7c01%7ctonynad%40microsoft.com%7cb241356f13334b0b0bcc08d3bfc0ae61%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062806676906214&sdata=SCEaaD%2bS0yv2brlbjk4lQ%2f1NRp5H1xYMBJIvnMhzm%2fk%3d>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Aug 2016 12:04:15 +1000

> By authenticate them do you me validate their authenticity ? or something different?

I meant to refer to referred token bindings.  Migration there is harder.