Re: [Unbearable] reviewing our 00's

[[e-mail]]

I just found a presentation of yours written together with Vinod "The Token Binding Protocol." This is most useful.

 

"In this case, the new cookie will be bound to the new Token Binding Key (assuming the client and server have negotiated the use of Token Binding)."

 

This is now diagressing too far, but what I meant was that TLS relying on certs in a controlled environment may be fine, but I am not so happy about it in the wilder Internet. But I think I have answered my own question, which was that combining this with say HIP would not get us any further.

 

"Can you elaborate on the specific client-side scalability concerns?"

 

Sorry, no, no experimental data to share, just general concern. By scalability I dont just mean the volume of cookies on any one client machine, but also from home I use three different machines. different OS's, different browsers or versions, and add to that at work and at clients. I would like the servers I visit all to securely recognise me as the same person. Perhaps this was already addressed and I missed it.

 

all the best

Dean

 

Gesendet: Mittwoch, 22. April 2015 um 19:29 Uhr
Von: "Andrei Popov" <[e-mail]>
An: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Betreff: Re: [Unbearable] reviewing our 00's

Ø  Which mechanism are we relying on to prevent hyjacking the returned cookie? 

Are you talking about a scenario where the client deletes cookies (and token bindings), re-authenticates with the web site, and receives a new cookie? In this case, the new cookie will be bound to the new Token Binding Key (assuming the client and server have negotiated the use of Token Binding).

Ø  But I was more concerned with the key-management client-side issue.

Ø  I am just thinking that scaleability should be built into solutions at an early stage.

If the client can manage cookies in a scalable manner, this client can probably be enhanced to also manage Token Binding keys in a scalable manner. Can you elaborate on the specific client-side scalability concerns?

 

Cheers,

 

Andrei

 

From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, April 22, 2015 7:14 AM
To: Andrei Popov
Cc: [e-mail]
Subject: Aw: Re: [Unbearable] reviewing our 00's

 

Hi Andrea,

 

yes, quite right, and of course if they perviously had the relevant cookie, resetablishing it is trivial. And someone not accepting cookies on principle would not have been authenticated in the first place. Bu this is more or less what I wrote previously. Which mechanism are we relying on to prevent hyjacking the returned cookie? 

 

But I was more concerned with the key-management client-side issue. I have no proposed solution up my sleave, but it concerns me that like many others very often I am in hundreds of web-sites per day.

Added to this during any particular day I am using a Win-8 desktop, a Win-7 laptop, and an Android based Tablet. I am just thinking that scaleability should be built into solutions at an early stage.

 

best,

Dean  

 

Gesendet: Dienstag, 21. April 2015 um 00:03 Uhr
Von: "Andrei Popov" <[e-mail]" target="_parent" rel="nofollow">[e-mail]>
An: "[e-mail]" target="_parent" rel="nofollow">[e-mail]" <[e-mail]" target="_parent" rel="nofollow">[e-mail]>
Cc: "[e-mail]" target="_parent" rel="nofollow">[e-mail]" <[e-mail]" target="_parent" rel="nofollow">[e-mail]>
Betreff: 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 [[e-mail]" target="_parent" rel="nofollow">mailto:[e-mail]] On Behalf Of [e-mail]" target="_parent" rel="nofollow">[e-mail]
Sent: Saturday, April 18, 2015 1:11 PM
Cc: [e-mail]" target="_parent" rel="nofollow">[e-mail]
Subject: Re: [Unbearable] reviewing our 00's

 

Dear All,

 

http://tools.ietf.org/html/draft-ietf-tokbind-https-00" target="_blank" rel="nofollow">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" <[e-mail]>
An: [e-mail]
Cc: "[e-mail]" <[e-mail]>
Betreff: Re: [Unbearable] reviewing our 00's

Some links:

http://tools.ietf.org/html/draft-ietf-tokbind-protocol-00" target="_blank" rel="nofollow">http://tools.ietf.org/html/draft-ietf-tokbind-protocol-00
http://tools.ietf.org/html/draft-ietf-tokbind-https-00" target="_blank" rel="nofollow">http://tools.ietf.org/html/draft-ietf-tokbind-https-00

https://github.com/TokenBinding/" target="_blank" rel="nofollow">https://github.com/TokenBinding/

 

On Sat, Apr 18, 2015 at 9:16 AM, <[e-mail]" target="_parent" rel="nofollow">[e-mail]> 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" <[e-mail]" target="_parent" rel="nofollow">[e-mail]>
An: "[e-mail]" target="_parent" rel="nofollow">[e-mail]" <[e-mail]" target="_parent" rel="nofollow">[e-mail]>
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
[e-mail]" target="_parent" rel="nofollow">[e-mail]
https://www.ietf.org/mailman/listinfo/unbearable" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________
Unbearable mailing list
[e-mail]" target="_parent" rel="nofollow">[e-mail]
https://www.ietf.org/mailman/listinfo/unbearable" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/unbearable
 

_______________________________________________ Unbearable mailing list [e-mail] https://www.ietf.org/mailman/listinfo/unbearable" target="_blank" rel="nofollow"> https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________ Unbearable mailing list [e-mail]" target="_parent" rel="nofollow">[e-mail] https://www.ietf.org/mailman/listinfo/unbearable" target="_blank" rel="nofollow"> https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________ Unbearable mailing list [e-mail] https://www.ietf.org/mailman/listinfo/unbearable" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/unbearable