This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Token Binding Protocol
Token Binding Protocol

Version management

Difference between version and

At line 1 added 21 lines
!!! Overview
[{$pagename}] ([RFC 8471]) is established by the [user-agent] generating a [Private Key]-[Public Key] pair (possibly within a [Hardware Security Module] ([HSM]), or a [TPM]) per target server, and proving possession of the private key on every [TLS] connection to the target server. [{$pagename}] in the course of a [TLS Handshake], a [client] and [server] can use the [Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation] ([RFC 8472]) to negotiate the [{$pagename}] [version] and the parameters (signature algorithm, length) of the Token Binding [key]. This negotiation does not require additional [Round-trips].[{$pagename}] enables client/server applications to create long-lived, uniquely identifiable [TLS] bindings spanning multiple [TLS] sessions and connections. [Applications] are then enabled to [Cryptographically|Cryptographic] bind [Security Tokens] to the [TLS] layer, preventing [token] export and [Replay attacks].
[{$pagename}] uses [Application-Layer Protocol Negotiation] ([ALPN]) protocol IDs to negotiate the use of [{$pagename}], in addition to the actual application [protocol].
Unlike TLS client [certificates], the use of Token Binding keys does not require any interaction with the user. This is because:[1]
* it is always clear which Token Binding key to use (so the user doesn't have to be consulted), and
* the [browser] always uses a different key with different [Websites] (so the user doesn't need to give consent to use a Token Binding key).
The [Proof-of-Possession] involves signing the exported keying material [RFC 5705] for the [TLS] connection with the [Private Key]. The corresponding [Public Key] is included in the [Token Binding ID] structure (described in the "[Token Binding ID] Format" section of this [RFC 8471]). Token Bindings are long-lived, i.e. they encompass multiple [TLS] connections and [TLS] sessions between a given client and server. To protect [privacy], [Token Binding ID]s are __NEVER__ transmitted in [Cleartext] and can be reset by the user at any time, e.g. when clearing browser cookies.
When issuing a [Security Token] to a client that supports [{$pagename}], a server includes the client's [Token Binding ID] in the [token]. Later on, when a client presents a security [token] containing a [Token Binding ID], the server makes sure the ID in the token matches the ID of the Token Binding established with the client. In the case of a mismatch, the server discards the [token].
[Servers] generate various [Security Tokens] (e.g. HTTP [cookies], [OAuth] [tokens]) for applications to access [Protected Resources]. Any party in possession of such [token] gains access to the [Protected Resources]. [Attackers] export [Bearer Tokens] from the user's machine, present them to the servers, and impersonate authenticated users. The idea of [{$pagename}] is to prevent such [attacks] by [cryptographically|Cryptography] binding [Security Tokens|Security Token] to the [TLS] layer.
In order to successfully export and [Replay attack] a bound security token, the [attacker] needs to also be able to export the client's [Private Key], which is hard to do in the case of the key generated in a secure hardware module.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Token Binding|http://www.browserauth.net/token-binding|target='_blank'] - based on information obtained 2017-03-15
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop