Re: [Unbearable] reviewing our 00's

Hi Dean,

Thanks for the editorial comments; will rephrase in the next revision.

Ø  What happens if exactly at that moment the the client clears thier cache after the token/cookie is received?

Ø  I still have the same conceptual problem with cache flushing, if the cookie is gone the whole process has to start from the beginning and the client has to prove they are still the same client. In other words re-establish the 3rd leg of a challenge response protocol.
If the cookie is gone, the server will have to authenticate this client again. This is the case today; I don’t think Token Binding is changing anything WRT this case.

Cheers,

Andrei

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of D.Rogers@gmx.net
Sent: Saturday, April 18, 2015 1:11 PM
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] reviewing our 00's

Dear All,

http://tools.ietf.org/html/draft-ietf-tokbind-https-00

perhaps its a bit late to be raising this point but:
Abstract:
"an HTTP server issues a security token (such as a cookie) to a client, and expects the client to send the security token back to the server at a later time in order to authenticate."

What happens if exactly at that moment the the client clears thier cache after the token/cookie is received?
Something in the challenge-response mechanism is missing here. Why does the HTTP Server issue the token, at this point there is no mention of a challenge prompting this response. What should the challenge look like? Basically this does not belong in the abstract.

"Binding the token to the TLS connection between client and server protects the security token from theft, and ensures that the security token can only be used by the client that it was issued to."
This binding is not yet established, so ... "and would ensure that the security token..."

Please, I may have misunderstood something, but are we saying that a token issued by server A to client X may possibly be accepted by server B, surely this can only be the case on implicit trust between servers A and B?
Further, "the client proves possession of (private key) to the server, and is long-lived (i.e., subsequent TLS connections between the same client and server have the same Token Binding ID."
I still have the same conceptual problem with cache flushing, if the cookie is gone the whole process has to start from the beginning and the client has to prove they are still the same client. In other words re-establish the 3rd leg of a challenge response protocol. Where this is still the same client only time is lost. but I am afraid that should an attacker be able to generate such a failure they may be able to hijack the session.

Section 3.1 suggests that each client operate a large scale Key-management system, "clients use different private keys to establish Provided Token Binding IDs with different servers".
Clients are clients and this should not be thier business.
It was with this, to my mind, major architectural conceptual misdiection that stoped my reading further.

Salutem
Dean

Gesendet: Samstag, 18. April 2015 um 17:21 Uhr
Von: "Brian Campbell" <bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>>
An: D.Rogers@gmx.net<mailto:D.Rogers@gmx.net>
Cc: "unbearable@ietf.org<mailto:unbearable@ietf.org>" <unbearable@ietf.org<mailto:unbearable@ietf.org>>
Betreff: Re: [Unbearable] reviewing our 00's
Some links:

http://tools.ietf.org/html/draft-ietf-tokbind-protocol-00
http://tools.ietf.org/html/draft-ietf-tokbind-https-00

https://github.com/TokenBinding/

On Sat, Apr 18, 2015 at 9:16 AM, <D.Rogers@gmx.net> wrote:
Sorry,

but like a lot of people we are all busy,

can you repeat the links,
without wishing to sound like Dr Who, you catch me at a time when I have time,
possibly its the same for others, quick links without having to mine them would be most useful brigadier :-)

best
Dean
Gesendet: Samstag, 18. April 2015 um 15:33 Uhr
Von: "Leif Johansson" <leifj@sunet.se>
An: "unbearable@ietf.org" <unbearable@ietf.org>
Betreff: [Unbearable] reviewing our 00's

Folks,

The core drafts have been out and published as WG documents for a couple
of weeks now. Please review!

Cheers Leif

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________ Unbearable mailing list Unbearable@ietf.org<mailto:Unbearable@ietf.org> https://www.ietf.org/mailman/listinfo/unbearable