Subject: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp

From: Leif Johansson <[email-masked]>
Date: Fri, 14 Sep 2018 00:06:21 +0200

This message marks the start of a 2 week WGLC on
draft-ietf-tokbind-ttrp-06 as agreed in Montreal but only now effected
by your chair.

Please provide your final comments, voices of support or objections
by COB Fri 28 Sept in any TZ.

	Best R
	Leif

---

From: Denis <[email-masked]>
Date: Mon, 17 Sep 2018 11:32:37 +0200

Comments on draft-ietf-tokbind-ttrp-06: HTTPS Token Binding with TLS 
Terminating Reverse Proxies

The introduction states:

    An HTTP server issuing cookies or other security tokens can
    associate them with the Token Binding ID, which ensures those tokens
    cannot be used successfully over a different TLS connection or by a
    different client than the one to which they were issued.

When there are only external attackers, the sentence is correct but is 
incorrect when there is a collusion between a legitimate client and 
another client.
The sentence should be corrected. Here is a proposal:

    An HTTP server issuing cookies or other security tokens can
    associate them with the Token Binding ID, which ensures those tokens
    cannot be used successfully over a different TLS connection or by a
    different client than the one to which they were issued, as long as
    there is no collusion between the legitimate client and another client.

In the "Security Considerations" section (section 4), some explanations 
should be added. Here is a proposal:

    The token binding mechanism is efficient against external attackers,
    but, in case a legitimate client collaborates with another client,
    the mechanism can be defeated since the legitimate client, using the
    private key which proves possession of the security token, can perform
    all the cryptographic computations that the other client needs to
    demonstrate the possession of that security token.

Denis

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

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 17 Sep 2018 11:53:34 +0200

Can we please stop adding text that says "don't share your private key with
others" to IETF drafts? That is an inherent part of PKI and does not need
to be repeated everywhere IMO, just like text about how verifying TLS
server certificate should work is not repeated in drafts where TLS is a
requirement. Perhaps a reference to generic PKI principles and guidelines
may be included?

Hans.

On Mon, Sep 17, 2018 at 11:32 AM Denis <[email-masked]> wrote:

> An HTTP server issuing cookies or other security tokens can associate them
> with the Token Binding ID, which ensures those tokens
> incorrect when there is a collusion between a legitimate client and another
> client.
> An HTTP server issuing cookies or other security tokens can associate them
> with the Token Binding ID, which ensures those tokens
> The token binding mechanism is efficient against external attackers, but,
> in case a legitimate client collaborates with another client,
> Unbearable mailing [email-masked]://www.ietf.org/mailman/listinfo/unbearable
>
>

-- 
[email-masked]
ZmartZone IAM - www.zmartzone.eu

---

From: Denis <[email-masked]>
Date: Mon, 17 Sep 2018 12:43:27 +0200

Hans,

This has nothing to do with "private key sharing". Private keys are 
usually protected by some hardware device which does not allow to export 
these keys.
However, a legitimate user can *use* his hardware device which means 
that he can ask to his device to perform some cryptographic computation 
with the private keys
that are stored in it.

In the past, when doing a threat analysis, only external attackers were 
being considered. Collaborative attacks is a different kind of threat 
that should also be considered.
However, it only applies to some specific contexts:

    If the security token contains a sufficient number of attributes
    that allows to fully identify the bearer, the bearer will probably
    refuse to collaborate with anybody else,
    because that other body could fully impersonate him.

    If the security token contains one or more attributes that do not
    allow to fully identify the bearer, the bearer may accept to
    collaborate with somebody else, because
    he cannot be identified. Typical examples of such an attribute are:
    "over 18" or "resident of Florida". Such attributes may allow to
    access to a service.

Any solution using software only is unable to counter collaborative 
attacks. Any solution using hardware devices that are only protecting 
the private keys, /but not their usag//e/,
are also unable to counter collaborative attacks. The topic has nothing 
to do with generic PKI principles and guidelines. However, adding some 
additional explanations into
the security considerations section along those provided above could be 
useful.

Denis

> Can we please stop adding text that says "don't share your private key 
> with others" to IETF drafts? That is an inherent part of PKI and does 
> not need to be repeated everywhere IMO, just like text about how 
> verifying TLS server certificate should work is not repeated in drafts 
> where TLS is a requirement. Perhaps a reference to generic PKI 
> principles and guidelines may be included?
>
> Hans.
>
> On Mon, Sep 17, 2018 at 11:32 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Comments on draft-ietf-tokbind-ttrp-06: HTTPS Token Binding with
>     TLS Terminating Reverse Proxies
>
>     The introduction states:
>
>         cannot be used successfully over a different TLS connection or
>         by a different client than the one to which they were issued.
>
>     When there are only external attackers, the sentence is correct
>     but is incorrect when there is a collusion between a legitimate
>     client and another client.
>         cannot be used successfully over a different TLS connection or
>         by a different client than the one to which they were issued,
>         as long as
>     In the "Security Considerations" section (section 4), some
>     explanations should be added. Here is a proposal:
>
>         The token binding mechanism is efficient against external
>         attackers, but, in case a legitimate client collaborates with
>         another client,
>         the mechanism can be defeated since the legitimate client,
>         using the private key which proves possession of the security
>         token, can perform
>         all the cryptographic computations that the other client needs
>         to demonstrate the possession of that security token.
>
>     Denis
>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 17 Sep 2018 17:57:23 +0000

Hi Denis,

IMHO this is already addressed in the security considerations:

“The Token Binding protocol does not prevent cooperating clients from
   sharing a bound token.  A client could intentionally export a bound
   token with the corresponding Token Binding private key, or perform
   signatures using this key on behalf of another client.”

Cheers,

Andrei

From: Unbearable <[email-masked]> On Behalf Of Denis
Sent: Monday, September 17, 2018 3:43 AM
To: Hans Zandbelt <[email-masked]>
Cc: Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp

Hans,

This has nothing to do with "private key sharing". Private keys are usually protected by some hardware device which does not allow to export these keys.
However, a legitimate user can use his hardware device which means that he can ask to his device to perform some cryptographic computation with the private keys
that are stored in it.

In the past, when doing a threat analysis, only external attackers were being considered. Collaborative attacks is a different kind of threat that should also be considered.
However, it only applies to some specific contexts:
If the security token contains a sufficient number of attributes that allows to fully identify the bearer, the bearer will probably refuse to collaborate with anybody else,
because that other body could fully impersonate him.

If the security token contains one or more attributes that do not allow to fully identify the bearer, the bearer may accept to collaborate with somebody else, because
he cannot be identified. Typical examples of such an attribute are: "over 18" or "resident of Florida". Such attributes may allow to access to a service.
Any solution using software only is unable to counter collaborative attacks. Any solution using hardware devices that are only protecting the private keys, but not their usage,
are also unable to counter collaborative attacks. The topic has nothing to do with generic PKI principles and guidelines. However, adding some additional explanations into
the security considerations section along those provided above could be useful.

Denis
Can we please stop adding text that says "don't share your private key with others" to IETF drafts? That is an inherent part of PKI and does not need to be repeated everywhere IMO, just like text about how verifying TLS server certificate should work is not repeated in drafts where TLS is a requirement. Perhaps a reference to generic PKI principles and guidelines may be included?

Hans.

On Mon, Sep 17, 2018 at 11:32 AM Denis <[email-masked]<mailto:[email-masked]>> wrote:
Comments on draft-ietf-tokbind-ttrp-06: HTTPS Token Binding with TLS Terminating Reverse Proxies

The introduction states:
An HTTP server issuing cookies or other security tokens can associate them with the Token Binding ID, which ensures those tokens
cannot be used successfully over a different TLS connection or by a different client than the one to which they were issued.
When there are only external attackers, the sentence is correct but is incorrect when there is a collusion between a legitimate client and another client.
The sentence should be corrected. Here is a proposal:
An HTTP server issuing cookies or other security tokens can associate them with the Token Binding ID, which ensures those tokens
cannot be used successfully over a different TLS connection or by a different client than the one to which they were issued, as long as
there is no collusion between the legitimate client and another client.
In the "Security Considerations" section (section 4), some explanations should be added. Here is a proposal:
The token binding mechanism is efficient against external attackers, but, in case a legitimate client collaborates with another client,
the mechanism can be defeated since the legitimate client, using the private key which proves possession of the security token, can perform
all the cryptographic computations that the other client needs to demonstrate the possession of that security token.
Denis

by your chair.

 Best R

 Leif

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%7CAndrei.Popov%40microsoft.com%7C0f190bc7a19c4c92014f08d61c8a6cdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636727778196060990&sdata=wp0JA58IzQoYFIB0QVMNtyWSjiAhAJr8EHGvXs1fwLc%3D&reserved=0>

_______________________________________________
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%7CAndrei.Popov%40microsoft.com%7C0f190bc7a19c4c92014f08d61c8a6cdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636727778196071002&sdata=CFnNEkHXp9X1RnN9HJij32YLB3IS3NQJ%2FJveXArXOp4%3D&reserved=0>

--
[email-masked]<mailto:[email-masked]>
ZmartZone IAM - www.zmartzone.eu<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zmartzone.eu&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C0f190bc7a19c4c92014f08d61c8a6cdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636727778196081011&sdata=30pxo8BATC47jY8%2FM6%2FIK4J84FKsoGYGv776w%2FKboJ0%3D&reserved=0>

---

From: Denis <[email-masked]>
Date: Mon, 17 Sep 2018 20:23:07 +0200

Hi Andrei,

Such a sentence is present in draft-ietf-tokbind-protocol-19 (The Token 
Binding Protocol Version 1.0), but not
in draft-ietf-tokbind-ttrp-06: HTTPS Token Binding with TLS Terminating 
Reverse Proxies.

Denis

> *From:*Unbearable <[email-masked]> *On Behalf Of *Denis
> *Sent:* Monday, September 17, 2018 3:43 AM
> *To:* Hans Zandbelt <[email-masked]>
> *Cc:* Tokbind WG <[email-masked]>
> *Subject:* Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp
>
> Hans,
>
> usually protected by some hardware device which does not allow to 
> export these keys.
> that he can ask to his device to perform some cryptographic 
> computation with the private keys
> that are stored in it.
>
> In the past, when doing a threat analysis, only external attackers 
> were being considered. Collaborative attacks is a different kind of 
> threat that should also be considered.
>     he cannot be identified. Typical examples of such an attribute
>     are: "over 18" or "resident of Florida". Such attributes may allow
>     to access to a service.
>
> the private keys, /but not their usage/,
> are also unable to counter collaborative attacks. The topic has 
> nothing to do with generic PKI principles and guidelines. However, 
> adding some additional explanations into
>     Can we please stop adding text that says "don't share your private
>     key with others" to IETF drafts? That is an inherent part of PKI
>     and does not need to be repeated everywhere IMO, just like text
>     about how verifying TLS server certificate should work is not
>     repeated in drafts where TLS is a requirement. Perhaps a reference
>     to generic PKI principles and guidelines may be included?
>
>     Hans.
>
>             An HTTP server issuing cookies or other security tokens
>             can associate them with the Token Binding ID, which
>             ensures those tokens
>             cannot be used successfully over a different TLS
>             connection or by a different client than the one to which
>             they were issued.
>
>         When there are only external attackers, the sentence is
>         correct but is incorrect when there is a collusion between a
>         legitimate client and another client.
>             An HTTP server issuing cookies or other security tokens
>             can associate them with the Token Binding ID, which
>             ensures those tokens
>             cannot be used successfully over a different TLS
>             connection or by a different client than the one to which
>             they were issued, as long as
>             attackers, but, in case a legitimate client collaborates
>             with another client,
>             using the private key which proves possession of the
>             security token, can perform
>             all the cryptographic computations that the other client
>             needs to demonstrate the possession of that security token.
>
>         Denis
>
>             <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C0f190bc7a19c4c92014f08d61c8a6cdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636727778196060990&sdata=wp0JA58IzQoYFIB0QVMNtyWSjiAhAJr8EHGvXs1fwLc%3D&reserved=0>
>
>         <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C0f190bc7a19c4c92014f08d61c8a6cdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636727778196071002&sdata=CFnNEkHXp9X1RnN9HJij32YLB3IS3NQJ%2FJveXArXOp4%3D&reserved=0>
>
>
>     -- 
>
>     <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zmartzone.eu&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C0f190bc7a19c4c92014f08d61c8a6cdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636727778196081011&sdata=30pxo8BATC47jY8%2FM6%2FIK4J84FKsoGYGv776w%2FKboJ0%3D&reserved=0>
>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 17 Sep 2018 18:36:30 +0000

Yes, but arguably, since TTRP references TBPROTO, it does not have to copy all of the security considerations from the base protocol document. Otherwise, any Internet-Draft would have to contain a superset of the security considerations from all referenced documents…

From: Unbearable <[email-masked]> On Behalf Of Denis
Sent: Monday, September 17, 2018 11:23 AM
To: Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp

Hi Andrei,

Such a sentence is present in draft-ietf-tokbind-protocol-19 (The Token Binding Protocol Version 1.0), but not
in draft-ietf-tokbind-ttrp-06: HTTPS Token Binding with TLS Terminating Reverse Proxies.

Denis
Hi Denis,

Cheers,

Andrei

From: Unbearable <[email-masked]><mailto:[email-masked]> On Behalf Of Denis
Sent: Monday, September 17, 2018 3:43 AM
To: Hans Zandbelt <[email-masked]><mailto:[email-masked]>
Cc: Tokbind WG <[email-masked]><mailto:[email-masked]>
Subject: Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp

Hans,

Denis

Hans.

The introduction states:

by your chair.

 Best R

 Leif

Unbearable mailing list

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%7CAndrei.Popov%40microsoft.com%7Cab8af6eb738948ea918908d61ccaa431%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636728054009097353&sdata=nAYXebh8MnuGb4AqFSnfgn7w03gTobnP5pHjPfRB%2FR4%3D&reserved=0>

_______________________________________________
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%7CAndrei.Popov%40microsoft.com%7Cab8af6eb738948ea918908d61ccaa431%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636728054009097353&sdata=nAYXebh8MnuGb4AqFSnfgn7w03gTobnP5pHjPfRB%2FR4%3D&reserved=0>

--
[email-masked]<mailto:[email-masked]>
ZmartZone IAM - www.zmartzone.eu<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zmartzone.eu&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cab8af6eb738948ea918908d61ccaa431%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636728054009097353&sdata=qCQp1us41uMQ3TXbXjN7rzY0ZXIwFJNa3v40dfVvaeQ%3D&reserved=0>

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 17 Sep 2018 21:12:10 +0200

same reasoning holds for "don't share your HSM" with others, "don't share
your access tokens with others" and really "don't share the information you
got with the access token with others" (the latter being a more effective
"attack" than "colluding" on the access token); do we really want to spell
this out everywhere instead of referring to it?

Hans.

On Mon, Sep 17, 2018 at 12:43 PM Denis <[email-masked]> wrote:

> However, a legitimate user can *use* his hardware device which means that
> he can ask to his device to perform some cryptographic computation with the
> private keys
> that are stored in it.
>
> being considered. Collaborative attacks is a different kind of threat that
> should also be considered.
> If the security token contains a sufficient number of attributes that
> allows to fully identify the bearer, the bearer will probably refuse to
> collaborate with anybody else,
> If the security token contains one or more attributes that do not allow to
> fully identify the bearer, the bearer may accept to collaborate with
> somebody else, because
> he cannot be identified. Typical examples of such an attribute are: "over
> 18" or "resident of Florida". Such attributes may allow to access to a
> service.
>
> attacks. Any solution using hardware devices that are only protecting the
> private keys, *but not their usag**e*,
> are also unable to counter collaborative attacks. The topic has nothing to
> do with generic PKI principles and guidelines. However, adding some
> with others" to IETF drafts? That is an inherent part of PKI and does not
> need to be repeated everywhere IMO, just like text about how verifying TLS
>> An HTTP server issuing cookies or other security tokens can associate
>> them with the Token Binding ID, which ensures those tokens
>> An HTTP server issuing cookies or other security tokens can associate
>> them with the Token Binding ID, which ensures those tokens

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 17 Sep 2018 21:12:10 +0200

Hans.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 18 Sep 2018 09:17:49 -0600

Agreed that the reference to TBPROTO, which already has security
considerations about it, is more than sufficient.  The security
considerations in TTRP are only about the issues relating specifically to
that deployment model.

On Mon, Sep 17, 2018 at 12:36 PM Andrei Popov <[email-masked]>
wrote:

> Yes, but arguably, since TTRP references TBPROTO, it does not have to copy
> all of the security considerations from the base protocol document.
> Otherwise, any Internet-Draft would have to contain a superset of the
> security considerations from all referenced documents…
>
>
>
> *From:* Unbearable <[email-masked]> *On Behalf Of *Denis
> *Sent:* Monday, September 17, 2018 11:23 AM
> *To:* Tokbind WG <[email-masked]>
> *From:* Unbearable <[email-masked]>
> <[email-masked]> * On Behalf Of *Denis
> <[email-masked]>
> *Cc:* Tokbind WG <[email-masked]> <[email-masked]>
> private keys, *but not their usage*,
> 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%7CAndrei.Popov%40microsoft.com%7Cab8af6eb738948ea918908d61ccaa431%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636728054009097353&sdata=nAYXebh8MnuGb4AqFSnfgn7w03gTobnP5pHjPfRB%2FR4%3D&reserved=0>
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cab8af6eb738948ea918908d61ccaa431%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636728054009097353&sdata=nAYXebh8MnuGb4AqFSnfgn7w03gTobnP5pHjPfRB%2FR4%3D&reserved=0>
>
>
>
>
> --
>
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zmartzone.eu&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cab8af6eb738948ea918908d61ccaa431%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636728054009097353&sdata=qCQp1us41uMQ3TXbXjN7rzY0ZXIwFJNa3v40dfVvaeQ%3D&reserved=0>
>
>
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._