One document matched: draft-popov-token-binding-00.xml
<?xml version="1.0" encoding="utf-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC7301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7301.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC5929 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml">
<!ENTITY RFC4492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4492.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-popov-token-binding-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>The Token Binding Protocol Version 1.0</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Andrei Popov" initials="A."
surname="Popov" role="editor">
<organization>Microsoft Corp.</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>andreipo@microsoft.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Magnus Nyström" initials="M."
surname="Nyström">
<organization>Microsoft Corp.</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>mnystrom@microsoft.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dirk Balfanz" initials="D."
surname="Balfanz">
<organization>Google Inc.</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>balfanz@google.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Adam Langley" initials="A."
surname="Langley">
<organization>Google Inc.</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>agl@google.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>draft</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document specifies Version 1.0 of the Token Binding protocol. The Token Binding
protocol allows client/server applications to create long-lived, uniquely identifiable TLS
<xref target="RFC5246" /> bindings spanning multiple TLS sessions and connections.
Applications are then enabled to cryptographically bind security tokens to the TLS layer,
preventing token export and replay attacks. To protect privacy, the TLS Token Binding
identifiers are only transmitted encrypted and can be reset by the user at any time.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Web services generate various security tokens (e.g. HTTP cookies, OAuth tokens) for
web applications to access protected resources. Any party in possession of such token
gains access to the protected resource. Attackers export bearer tokens from the user’s
machine, present them 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.</t>
<t>A TLS Token Binding is established by the user agent generating a private-public key
pair (possibly within a secure hardware module, such as TPM) per target server, and
proving possession of the private key on every TLS connection to the target server. The
proof of possession involves signing the tls_unique value <xref target="RFC5929" /> for
the TLS connection with the private key. Such TLS Token Binding is identified by the
corresponding public key. TLS Token Bindings are long-lived, i.e. they encompass multiple
TLS connections and TLS sessions between a given client and server. To protect privacy,
TLS Token Binding identifiers are never transmitted in clear text and can be reset by the
user at any time, e.g. when clearing browser cookies.</t>
<t>When issuing a security token to a client that supports TLS Token Binding, a server
includes the client’s TLS Token Binding ID in the token. Later on, when a client presents
a security token containing a TLS Token Binding ID, the server makes sure the ID in the
token matches the ID of the TLS Token Binding established with the client. In the case of
a mismatch, the server discards the token.</t>
<t>In order to successfully export and replay 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.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119" />.</t>
</section>
</section>
<section title="Token Binding Protocol Overview">
<t>The client and server use ALPN protocol IDs <xref target="RFC7301" /> to negotiate the
use of the Token Binding protocol, in addition to the actual application protocol such as
HTTP/1.1 <xref target="RFC2616"/> or HTTP/2 <xref target="I-D.ietf-httpbis-http2"/>.
ALPN IDs are also used to negotiate the parameters (signature algorithm, length) of the
Token Binding key. This negotiation does not require TLS protocol changes or additional
round-trips.</t>
<t>The "IANA Considerations" section of this document defines an initial set of ALPN
protocol IDs that allow the use of the Token Binding protocol with HTTP/1.1 and HTTP/2. The
initial set of supported key parameters includes ECDSA with NIST P256 curve and 2048-bit
RSA. New ALPN protocol IDs can be defined in the future to support Token Binding usage with
other application protocols and key parameters.</t>
<t>The Token Binding protocol consists of one message sent by the client to the server,
proving possession of one or more client-generated asymmetric keys. This message is
only sent if the client and server agree on the use of the Token Binding protocol and the
key parameters. The Token Binding message is sent with the application protocol data in TLS
application_data records.</t>
<t>A server receiving the Token Binding message verifies that the key parameters in the
message match the Token Binding parameters negotiated via ALPN, and then validates the
signatures contained in the Token Binding message. If either of these checks fails, the
server terminates the connection, otherwise the TLS Token Binding is successfully
established with the ID contained in the Token Binding message.</t>
<t>When a server supporting the Token Binding protocol receives a bound token, the server
compares the TLS Token Binding ID in the security token with the TLS Token Binding ID
established with the client. If the bound token came from a TLS connection without a Token
Binding, or if the IDs don't match, the token is discarded.</t>
<t>This document describes the negotiation of the Token Binding protocol and key
parameters, the format of the Token Binding protocol message, the process of establishing
a TLS Token Binding, the format of the Token Binding ID, and the process of validating a
security token. Token Binding over HTTP <xref target="HTTPSTB" /> explains how the Token
Binding message is encapsulated within application protocol messages.
<xref target="HTTPSTB" /> also describes Token Binding between multiple communicating
parties: User Agent, Identity Provider and Relying Party.</t>
</section>
<section title="Negotiating the Token Binding Protocol and Key Parameters">
<t>The Token Binding protocol is used within TLS connections, in combination with an
application protocol such as HTTP/1.1 or HTTP/2. The "IANA Considerations" section of this
document defines a set of ALPN protocol IDs that combine application protocol and token
binding key parameters:</t>
<t>
<list style="symbols">
<t>"h2_tb_p256" indicates support for HTTP/2 with Token Binding using ECDSA key and
NIST P256 curve;</t>
<t>"h2_tb_rsa2048" indicates support for HTTP/2 with Token Binding using 2048-bit RSA
key;</t>
<t>"http/1.1_tb_p256" indicates support for HTTP/1.1 with Token Binding using ECDSA key
and NIST P256 curve;</t>
<t>"http/1.1_tb_rsa2048" indicates support for HTTP/1.1 with Token Binding using
2048-bit RSA key.</t>
</list>
</t>
<t>The client advertises support of the Token Binding protocol by sending some of these IDs
in the ALPN extension in the ClientHello. Application protocol IDs without Token Binding,
such as "http/1.1" and "h2", can also be included for compatibility with the servers that
do not support the Token Binding protocol.</t>
<t>The server indicates support of the Token Binding protocol by sending one of the above
IDs in the ALPN extension in the ServerHello. The server implements the protocol selection
logic as described in section 3.2 "Protocol Selection" of <xref target="RFC7301" />, taking
into account the application protocols and key parameters supported by the server.</t>
</section>
<section title="Token Binding Protocol Message">
<figure>
<preamble>The Token Binding message is sent by the client and proves possession of one or
more private keys held by the client. This message MUST be sent if the client and server
successfully negotiated the use of the Token Binding protocol via ALPN, and MUST NOT be
sent otherwise. This message MUST be sent in the client's first application protocol
message. This message MAY also be sent in subsequent application protocol messages,
proving possession of other keys by the same client, to facilitate token binding between
more than two communicating parties. Token Binding over HTTP <xref target="HTTPSTB" />
specifies the encapsulation of the Token Binding message in the application protocol
messages, and the scenarios involving more than two communicating parties. The Token
Binding message format is defined using TLS specification language, and reuses existing
TLS structures and IANA registrations where possible:</preamble>
<artwork><![CDATA[
enum {
sha256(4), (255)
} HashAlgorithm;
enum {
rsa(1), ecdsap256(3), (255)
} SignatureAlgorithm;
struct {
HashAlgorithm hash;
SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
struct {
opaque modulus<1..2^16-1>;
opaque publicexponent<1..2^8-1>;
} RSAPublicKey;
enum {
secp256r1 (23), (0xFFFF)
} NamedCurve;
struct {
opaque point <1..2^8-1>;
} ECPoint;
struct {
NamedCurve namedcurve;
ECPoint point; // Uncompressed format
} ECDSAParams;
enum {
provided_token_binding(0), referred_token_binding(1), (255)
} TokenBindingType;
struct {
TokenBindingType tokenbinding_type;
SignatureAndHashAlgorithm algorithm;
select (algorithm.signature) {
case rsa: RSAPublicKey rsapubkey;
case ecdsa: ECDSAParams ecdsaparams;
}
} TokenBindingID;
enum {
(255) // No initial ExtensionType registrations
} ExtensionType;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
struct {
TokenBindingID tokenbindingid;
opaque signature<0..2^16-1>;// Signature over hashed ("token binding", tls_unique)
Extension extensions<0..2^16-1>;
} TokenBinding;
struct {
TokenBinding tokenbindings<0..2^16-1>;
} TokenBindingMessage;
]]></artwork>
<postamble>The Token Binding message consists of a series of TokenBinding structures
containing the TokenBindingID, a signature over the hash of the NUL-terminated, ASCII
label (“token binding”) and the tls_unique, optionally followed by Extension structures.
An implementation MUST ignore any unknown extensions. Initially, no extension types are
defined. At least one TokenBinding MUST be included in the Token Binding message. The
signature algorithm and key length used in the TokenBinding MUST match the parameters
negotiated via ALPN. The client SHOULD generate and store Token Binding keys in a secure
manner that prevents key export. In order to prevent cooperating servers from linking
user identities, different keys SHOULD be used by the client for connections to
different servers, according to the token scoping rules of the application protocol.
</postamble>
</figure>
</section>
<section title="Establishing a TLS Token Binding">
<t>Triple handshake vulnerability in the TLS protocol affects the security of the Token
Binding protocol, as described in the "Security Considerations" section below. Therefore,
the server MUST NOT negotiate the use of the Token Binding protocol unless the server also
negotiates Extended Master Secret TLS extension
<xref target="I-D.ietf-tls-session-hash"/>.</t>
<t>The server MUST terminate the connection if the use of the Token Binding protocol has
been successfully negotiated via ALPN within the TLS handshake, but the client's first
application message does not contain the Token Binding message. The server MUST terminate
the connection if the use of the Token Binding protocol was not negotiated, but the client
sends the Token Binding message.</t>
<t>If the Token Binding type is "provided_token_binding", the server MUST verify that the
signature algorithm (including elliptic curve in the case of ECDSA) and key length in the
Token Binding message match those negotiated via ALPN. In the case of a mismatch, the
server MUST terminate the connection. As described in <xref target="HTTPSTB" />, Token
Bindings of type "referred_token_binding" may have different key parameters than those
negotiated via ALPN.</t>
<t>If the Token Binding message does not contain at least one TokenBinding structure,
or the signature contained in a TokenBinding structure is invalid, the server MUST
terminate the connection. Otherwise, the TLS Token Binding is successfully established and
its ID can be provided to the application for security token validation.</t>
</section>
<section title="TLS Token Binding ID Format">
<figure>
<preamble>The ID of the TLS Token Binding established as a result of Token Binding
message processing is a binary representation of the following structure:</preamble>
<artwork><![CDATA[
struct {
TokenBindingType tokenbinding_type;
SignatureAndHashAlgorithm algorithm;
select (algorithm.signature) {
case rsa: RSAPublicKey rsapubkey;
case ecdsa: ECDSAParams ecdsaparams;
}
} TokenBindingID;
]]></artwork>
<postamble>TokenBindingID includes the type of the token binding and the key parameters
negotiated via ALPN. This document defines two token binding types:
provided_token_binding used to establish a Token Binding when connecting to a server,
and referred_token_binding used when requesting tokens to be presented to a different
server. Token Binding over HTTP <xref target="HTTPSTB" /> describes Token Binding between
multiple communicating parties: User Agent, Identity Provider and Relying Party. TLS
Token Binding ID can be obtained from the TokenBinding structure described in the "Token
Binding Protocol Message" section of this document by discarding the signature and
extensions. TLS Token Binding ID will be available at the application layer and used by
the server to generate and verify bound tokens.</postamble>
</figure>
</section>
<section title="Security Token Validation">
<t>Security tokens can be bound to the TLS layer either by embedding the Token Binding ID
in the token, or by maintaining a database mapping tokens to Token Binding IDs. The
specific method of generating bound security tokens is application-defined and beyond the
scope of this document.</t>
<t>Upon receipt of a security token, the server attempts to retrieve TLS Token Binding ID
information from the token and from the TLS connection with the client.
Application-provided policy determines whether to honor non-bound (bearer) tokens. If the
token is bound and a TLS Token Binding has not been established for the client connection,
the server MUST discard the token. If the TLS Token Binding ID for the token does not
match the TLS Token Binding ID established for the client connection, the server MUST
discard the token.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document establishes a registry for Token Binding type identifiers entitled "Token
Binding Types" under the "Token Binding Protocol" heading.</t>
<t>Entries in this registry require the following fields:
<list style="symbols">
<t>Value: The octet value that identifies the Token Binding type (0-255).</t>
<t>Description: The description of the Token Binding type.</t>
<t>Specification: A reference to a specification that defines the Token Binding
type.</t>
</list>
</t>
<t>This registry operates under the "Expert Review" policy as defined in
<xref target="RFC5226"/>. The designated expert is advised to encourage the inclusion of a
reference to a permanent and readily available specification that enables the creation of
interoperable implementations using the identified Token Binding type.</t>
<t>An initial set of registrations for this registry follows:
<list style="empty">
<t>Value: 0</t>
<t>Description: provided_token_binding</t>
<t>Specification: this document</t>
</list>
<list style="empty">
<t>Value: 1</t>
<t>Description: referred_token_binding</t>
<t>Specification: this document</t>
</list>
</t>
<t>This document establishes a registry for Token Binding extensions entitled "Token
Binding Extensions" under the "Token Binding Protocol" heading.</t>
<t>Entries in this registry require the following fields:
<list style="symbols">
<t>Value: The octet value that identifies the Token Binding extension (0-255).</t>
<t>Description: The description of the Token Binding extension.</t>
<t>Specification: A reference to a specification that defines the Token Binding
extension.</t>
</list>
</t>
<t>This registry operates under the "Expert Review" policy as defined in
<xref target="RFC5226"/>. The designated expert is advised to encourage the inclusion of a
reference to a permanent and readily available specification that enables the creation of
interoperable implementations using the identified Token Binding extension. This document
creates no initial registrations in the "Token Binding Extensions" registry.</t>
<t>This document creates the following registrations for the identification of the Token
Binding protocol in the "Application Layer Protocol Negotiation (ALPN) Protocol IDs"
registry originally created in <xref target="RFC7301" />:</t>
<t>
<list style="empty">
<t>Protocol: HTTP/2 with Token Binding using ECDSA key and NIST P256 curve</t>
<t>Identification Sequence: 0x68 0x32 0x5f 0x74 0x62 0x5f 0x70 0x32 0x35 0x36
("h2_tb_p256")</t>
<t>Specification: this document</t>
</list>
<list style="empty">
<t>Protocol: HTTP/2 with Token Binding using 2048-bit RSA key</t>
<t>Identification Sequence: 0x68 0x32 0x5f 0x74 0x62 0x5f 0x72 0x73 0x61 0x32 0x30 0x34
0x38 ("h2_tb_rsa2048")</t>
<t>Specification: this document</t>
</list>
<list style="empty">
<t>Protocol: HTTP/1.1 with Token Binding using ECDSA key and NIST P256 curve</t>
<t>Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 0x5f 0x74 0x62 0x5f
0x70 0x32 0x35 0x36 ("http/1.1_tb_p256")</t>
<t>Specification: this document</t>
</list>
<list style="empty">
<t>Protocol: HTTP/1.1 with Token Binding using 2048-bit RSA key</t>
<t>Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 0x5f 0x74 0x62 0x5f
0x72 0x73 0x61 0x32 0x30 0x34 0x38 ("http/1.1_tb_rsa2048")</t>
<t>Specification: this document</t>
</list>
</t>
<t>This document uses "TLS SignatureAlgorithm" and "TLS HashAlgorithm" registries
originally created in <xref target="RFC5246" />, and "TLS NamedCurve" registry originally
created in <xref target="RFC4492" />. This document creates no new registrations in these
registries.</t>
</section>
<section anchor="Security" title="Security Considerations">
<section title="Security Token Replay">
<t>The goal of the Token Binding protocol is to prevent attackers from exporting and
replaying security tokens, thereby impersonating legitimate users and gaining access to
protected resources. Bound tokens can still be replayed by the malware present in the
User Agent. In order to export the token to another machine and successfully replay it,
the attacker also needs to export the corresponding private key. Token Binding private
keys are therefore high-value assets and SHOULD be strongly protected, ideally by
generating them in a hardware security module that prevents key export.</t>
</section>
<section title="Downgrade Attacks">
<t>The Token Binding protocol is only used when negotiated via ALPN within the TLS
handshake. TLS prevents active attackers from modifying the messages of the TLS
handshake, therefore it is not possible for the attacker to remove or modify the ALPN IDs
used to negotiate the Token Binding protocol and key parameters. The signature algorithm
and key length used in the TokenBinding of type "provided_token_binding" MUST match the
parameters negotiated via ALPN.</t>
</section>
<section title="Privacy Considerations">
<t>The Token Binding protocol uses persistent, long-lived TLS Token Binding IDs. To
protect privacy, TLS Token Binding IDs are never transmitted in clear text and can be
reset by the user at any time, e.g. when clearing browser cookies. In order to prevent
cooperating servers from linking user identities, different keys SHOULD be used by the
client for connections to different servers, according to the token scoping rules of the
application protocol.</t>
</section>
<section title="Triple Handshake Vulnerability in TLS">
<t>The Token Binding protocol relies on the tls_unique value to associate a TLS
connection with a TLS Token Binding. The triple handshake attack
<xref target="TRIPLE-HS" /> is a known TLS protocol vulnerability allowing the attacker
to synchronize tls_unique values between TLS connections. The attacker can then
successfully replay bound tokens. For this reason, the Token Binding protocol MUST NOT be
negotiated unless the Extended Master Secret TLS extension
<xref target="I-D.ietf-tls-session-hash"/> has also been negotiated.</t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC2119;
&RFC5246;
&RFC7301;
&RFC2616;
&RFC5929;
&RFC4492;
&RFC5226;
<reference anchor="HTTPSTB">
<front>
<title>Token Binding over HTTP</title>
<author initials="D." surname="Balfanz">
<organization>Google Inc.</organization>
</author>
<author initials="A." surname="Langley">
<organization>Google Inc.</organization>
</author>
<author initials="A." surname="Popov">
<organization>Microsoft Corp.</organization>
</author>
<author initials="M." surname="Nyström">
<organization>Microsoft Corp.</organization>
</author>
<date year="2014" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-httpbis-http2.xml"?>
<?rfc include="reference.I-D.ietf-tls-session-hash.xml"?>
<reference anchor="TRIPLE-HS">
<front>
<title>Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over
TLS. IEEE Symposium on Security and Privacy</title>
<author initials="K." surname="Bhargavan">
<organization>Inria Paris-Rocquencourt</organization>
</author>
<author initials="A." surname="Delignat-Lavaud">
<organization>Inria Paris-Rocquencourt</organization>
</author>
<author initials="C." surname="Fournet">
<organization>Inria Paris-Rocquencourt</organization>
</author>
<author initials="A." surname="Pironti">
<organization>Inria Paris-Rocquencourt</organization>
</author>
<author initials="P." surname="Strub">
<organization>Inria Paris-Rocquencourt</organization>
</author>
<date year="2014" />
</front>
</reference>
</references>
<!-- Change Log
v00 2014-08-21 Andrei Popov Initial version-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:47 |