Re: [Unbearable] one proposal for a charter - please dicsuss

[Andrei Popov <[e-mail]>]

Hi Phillip,


Ø  In particular I don't think we are getting away from bearer tokens, we are just hiding them different.

The Token Binding Protocol I-D<http://tools.ietf.org/html/draft-popov-token-binding-00> provides a mechanism for binding security tokens to the TLS layer. When a bound token is presented to a server, the server verifies the token binding and rejects the token if the binding verification fails. Therefore, such bound tokens are not bearer tokens: they are resistant to export and replay attacks.


Ø  This is a draft I have been working on for a while. It allows a token to be bound to a HTTP/TLS channel.

I agree that your draft is designed to solve a similar problem, although the approach you’ve taken is different in multiple ways. We can discuss these differences, but perhaps we should first focus on establishing the WG charter.

Cheers,

Andrei

From: Unbearable [mailto:[e-mail]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, December 8, 2014 3:42 PM
To: Stephen Farrell
Cc: [e-mail]
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss



On Mon, Dec 8, 2014 at 6:19 PM, Stephen Farrell <[e-mail]<mailto:[e-mail]>> wrote:

Hi all,

There's about 70+ people on the list now so let's kick off.

Andrei sent Kathleen and I the charter proposal below a while
ago. For myself I don't think its quite right yet but I'd
rather hear what you all think. So please discuss...

Cheers,
S.


Token Binding (TB)

Charter for Working Group

Web services generate various security tokens (e.g.  HTTP cookies, OAuth
tokens, etc.) for web applications to access protected resources.
Currently these are bearer tokens, i.e. any party in possession of such
token gains access to the protected resource. Attackers export bearer
tokens from client machines or from compromised network connections,
present these bearer tokens to Web services, and impersonate
authenticated users. The idea of Token Binding is to prevent such
attacks by cryptographically binding security tokens to the TLS layer.

The tasks of this working group are as follows:
1.            Specify the Token Binding protocol v1.0.
2.            Specify the use of the Token Binding protocol in
combination with HTTPS.

It is a goal of this working group to prevent security token export and
replay attacks, but other issues associated with the use of security
tokens are out of scope. It is a goal of this working group to design
the Token Binding protocol such that it would be also useable with
application protocols other than HTTPS, however specifying such uses is
not a primary goal.

Umm, I am still rather fuzzy about what is proposed here Stephen.

In particular I don't think we are getting away from bearer tokens, we are just hiding them different.

This is a draft I have been working on for a while. It allows a token to be bound to a HTTP/TLS channel.

http://tools.ietf.org/html/draft-hallambaker-httpsession-03


It might help if we had a definition of bearer token. I don't think that formulation is helping. The problem is not that we have bearer tokens, it is that our proofs of possession force them to be disclosed in plaintext to the party checking them.

Is an RSA private key a bearer token?
How about a kerberos ticket?


Presenting this as a problem with the token puts us off track. The problem is with the way we use them.