Token Binding over HTTP
draft-balfanz-https-token-binding-00
| Document | Type |
Replaced Internet-Draft
(tokbind WG)
Expired & archived
|
|
|---|---|---|---|
| Authors | Andrei Popov , Magnus Nyström , Dirk Balfanz , Adam Langley | ||
| Last updated | 2015-10-14 (Latest revision 2014-10-13) | ||
| Replaced by | draft-ietf-tokbind-https | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Adopted by a WG | |
| Document shepherd | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-tokbind-https | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such as cookies and OAuth tokens) to a TLS [RFC5246] connection. We describe both _first-party_ as well as _federated_ scenarios. In a first-party scenario, 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. 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. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS [RFC5246] connection that the client has with a _different_ server than the one issuing the token. This Internet-Draft is a companion document to The Token Binding Protocol [DraftPopov]
Authors
Andrei Popov
Magnus Nyström
Dirk Balfanz
Adam Langley
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)