One document matched: draft-ietf-tls-session-hash-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY RFC5746 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5746.xml'>
<!ENTITY RFC5705 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5705.xml'>
<!ENTITY RFC5929 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml'>
<!ENTITY RFC4251 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml'>
<!ENTITY RFC5077 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml'>
<!ENTITY RFC6101 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6101.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" symrefs="yes"?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-tls-session-hash-05">
<front>
<title abbrev="TLS Session Hash Extension">Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension</title>
<author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan" role="editor">
<organization>Inria Paris-Rocquencourt</organization>
<address>
<postal>
<street>23, Avenue d'Italie</street>
<city>Paris</city>
<region/>
<code>75214 CEDEX 13</code>
<country>France</country>
</postal>
<email>karthikeyan.bhargavan@inria.fr</email>
</address>
</author>
<author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud">
<organization>Inria Paris-Rocquencourt</organization>
<address>
<postal>
<street>23, Avenue d'Italie</street>
<city>Paris</city>
<region/>
<code>75214 CEDEX 13</code>
<country>France</country>
</postal>
<email>antoine.delignat-lavaud@inria.fr</email>
</address>
</author>
<author initials="A." surname="Pironti" fullname="Alfredo Pironti">
<organization>Inria Paris-Rocquencourt</organization>
<address>
<postal>
<street>23, Avenue d'Italie</street>
<city>Paris</city>
<region/>
<code>75214 CEDEX 13</code>
<country>France</country>
</postal>
<email>alfredo.pironti@inria.fr</email>
</address>
</author>
<author initials="A." surname="Langley" fullname="Adam Langley">
<organization>Google Inc.</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>agl@google.com</email>
</address>
</author>
<author initials="M." surname="Ray" fullname="Marsh Ray">
<organization>Microsoft Corp.</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>USA</country>
</postal>
<email>maray@microsoft.com</email>
</address>
</author>
<date month="April" year="2015" />
<area>Security</area>
<abstract>
<t>
The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>
In <xref target="RFC5246">TLS</xref>, every session has a <spanx style="verb">master_secret</spanx> computed
as:
<figure><artwork>
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
</artwork></figure>
where the <spanx style="verb">pre_master_secret</spanx> is the result of some key exchange protocol. For example, when the handshake uses an RSA ciphersuite, this value is generated uniformly at random by the client, whereas for DHE ciphersuites, it is the result of a Diffie-Hellman key agreement.
</t>
<t>
As described in <xref target="TRIPLE-HS"/>, in both the RSA and DHE key exchanges, an active attacker can synchronize two TLS sessions so that they share the same <spanx style="verb">master_secret</spanx>. For an RSA key exchange where the client is unauthenticated, this is achieved as follows.
Suppose a client C connects to a server A. C does not realize that A
is malicious and that A connects in the background to an honest
server S and completes both handshakes.
For simplicity, assume that C and S only use RSA ciphersuites.
<list style="numbers">
<t>C sends a <spanx style="verb">ClientHello</spanx> to A, and A forwards it to S.</t>
<t>S sends a <spanx style="verb">ServerHello</spanx> to A, and A forwards it to C.</t>
<t>S sends a <spanx style="verb">Certificate</spanx>, containing its certificate chain, to A.
A replaces it with its own certificate chain and sends it to C.</t>
<t>S sends a <spanx style="verb">ServerHelloDone</spanx> to A, and A forwards it to C.</t>
<t>C sends a <spanx style="verb">ClientKeyExchange</spanx> to A, containing the <spanx style="verb">pre_master_secret</spanx>, encrypted with A's public key.
A decrypts the <spanx style="verb">pre_master_secret</spanx>, re-encrypts it with S's public key and sends it on to S.</t>
<t>C sends a <spanx style="verb">Finished</spanx> to A. A computes
a <spanx style="verb">Finished</spanx> for its connection with S, and sends it to S.</t>
<t>S sends a <spanx style="verb">Finished</spanx> to A. A computes
a <spanx style="verb">Finished</spanx> for its connection with C, and sends it to C.</t>
</list>
At this point, both connections (between C and A, and between A and S) have new sessions that
share the same <spanx style="verb">pre_master_secret</spanx>,
<spanx style="verb">ClientHello.random</spanx>,
<spanx style="verb">ServerHello.random</spanx>,
as well as other session parameters, including the session identifier and, optionally, the session ticket.
Hence, the <spanx style="verb">master_secret</spanx> value
will be equal for the two sessions and it will be associated
both at C and S with the same session ID, even though the
server identities on the two connections are different.
Recall that C only sees A's certificate and is unaware
of A's connection with S. Moreover, the record keys on the
two connections will also be the same.
</t>
<t>
The above scenario shows that TLS does not guarantee that the
master secrets and keys used on different connections will be
different. Even if client authentication is used, the scenario
still works, except that the two sessions now differ on both
client and server identities.
</t>
<t>
A similar scenario can be achieved when the handshake uses a DHE ciphersuite. Note that even if the client or server does not prefer using RSA or DHE, the attacker can force them to use it by offering only RSA or DHE in its hello messages. Handshakes using ECDHE ciphersuites are also vulnerable if they allow arbitrary explicit curves or use curves with small subgroups. Against more powerful adversaries, other key exchanges, such as SRP and PSK, have also been shown to be vulnerable <xref target="VERIFIED-BINDINGS"/>.
</t>
<t>
Once A has synchronized the two connections, since the keys are the same on the two sides,
it can step away and transparently forward messages between C and S, reading and modifying
when it desires. In the key exchange literature, such occurrences are called unknown key-share attacks,
since C and S share a secret but they both think that their secret is shared only with A.
In themselves, these attacks do not break integrity or confidentiality between honest parties,
but they offer a useful starting point from which to mount impersonation attacks on C and S.
</t>
<t>
Suppose C tries to resume its session on a new connection with A. A can then
resume its session with S on a new connection and forward the abbreviated handshake
messages unchanged between C and S. Since the abbreviated handshake only relies on
the master secret for authentication, and does not mention client or server identities,
both handshakes complete successfully, resulting in the same session keys and the same
handshake log. A still knows the connection keys and can send messages to both C and S.
</t>
<t>
Critically, on the new connection, even the handshake log is the same on C and S, thus defeating
any man-in-the-middle protection scheme that relies on the uniqueness of finished messages, such
as the secure renegotiation indication extension <xref target="RFC5746"/> or
TLS channel bindings <xref target="RFC5929" />.
<xref target="TRIPLE-HS"/> describes several exploits based on such session synchronization
attacks. In particular, it describes a man-in-the-middle attack that circumvents the protections
of <xref target="RFC5746"/> to break client-authenticated TLS renegotiation after session resumption.
Similar attacks apply to application-level authentication mechanisms that rely on channel
bindings <xref target="RFC5929"/> or on key material exported from TLS <xref target="RFC5705"/>.
</t>
<t>
The underlying protocol issue leading to these attacks is that
the TLS master secret is not guaranteed to be unique across
sessions, since it is not context-bound to the full handshake
that generated it. If we fix this problem in the initial
master secret computation, all these attacks can be prevented.
This specification introduces a TLS extension that changes the
way the <spanx style="verb">master_secret</spanx> value is computed in
a full handshake by including the log of the handshake messages,
so that different sessions will, by construction, have different master
secrets.
</t>
</section>
<section title="Requirements Notation">
<t>
This document uses the same notation and terminology used in the
<xref target="RFC5246">TLS Protocol specification</xref>.
</t>
<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">RFC 2119</xref>.
</t>
</section>
<section title="The TLS Session Hash">
<t>
When a full TLS handshake takes place, we define
<figure><artwork>
session_hash = Hash(handshake_messages)
</artwork></figure>
where <spanx style="verb">handshake_messages</spanx> refers to all handshake messages sent or
received, starting at the ClientHello up to and including the ClientKeyExchange message, including the type and length fields of the handshake
messages. This is the concatenation of all the exchanged Handshake structures,
as defined in Section 7.4 of <xref target="RFC5246"/>.
</t>
<t>
For TLS 1.2, the <spanx style="verb">Hash</spanx> function is the one defined in Section 7.4.9 of <xref target="RFC5246"/> for the Finished message computation.
For all previous versions of TLS, the <spanx style="verb">Hash</spanx> function computes the concatenation of MD5 and SHA1.
</t>
<t>
There is no <spanx style="verb">session_hash</spanx> for resumed handshakes, as they do not lead to the creation of a new session.
</t>
</section>
<section anchor="ext_ms" title="The Extended Master Secret">
<t>
When the extended master secret extension is negotiated in a full handshake,
the <spanx style="verb">master_secret</spanx> is computed as
<figure><artwork>
master_secret = PRF(pre_master_secret, "extended master secret",
session_hash)
[0..47];
</artwork></figure>
The extended master secret computation differs from the <xref target="RFC5246"/> in the following ways:
<list style="symbols">
<t> The <spanx style="verb">extended master secret</spanx> label is used instead of <spanx style="verb">master secret</spanx>;</t>
<t> The <spanx style="verb">session_hash</spanx> is used instead of the <spanx style="verb">ClientHello.random</spanx> and <spanx style="verb">ServerHello.random</spanx>.</t>
</list>
</t>
<t>
The <spanx style="verb">session_hash</spanx> depends upon a handshake log that
includes <spanx style="verb">ClientHello.random</spanx> and <spanx style="verb">ServerHello.random</spanx>,
in addition to ciphersuites, key exchange information,
and certificates (if any) from the client and server. Consequently, the extended
master secret depends upon the choice of all these session parameters.
</t>
<t>
This design reflects the recommendation that keys should be bound to the security
contexts that compute them <xref target="SP800-108"/>. The technique of mixing a hash of
the key exchange messages into master key derivation is already used in other well-known
protocols such as SSH <xref target="RFC4251"/>.
</t>
<t>
Clients and servers SHOULD NOT accept handshakes that do not use the extended master secret,
especially if they rely on features like compound authentication that fall into the
vulnerable cases described in <xref target="impact"/>.
</t>
</section>
<section title="Extension Negotiation">
<section title="Extension Definition">
<t>
This document defines a new TLS extension, <spanx style="verb">extended_master_secret</spanx>
(with extension type 0x0017), which is used to signal both
client and server to use the extended master secret computation.
The <spanx style="verb">extension_data</spanx> field of this extension is empty.
Thus, the entire encoding of the extension is 00 17 00 00 (in hexadecimal.)
</t>
<t>
If the client and server agree on this extension,
and a full handshake takes place,
both client and server MUST use the extended master secret
derivation algorithm, as defined in <xref target="ext_ms"/>.
</t>
<t>
If an abbreviated handshake takes place, the new connection keys
are derived as usual from the (extended) master secret of the
original handshake that created the resumed session.
</t>
</section>
<section title="Client and Server Behavior: Full Handshake">
<t>
In the following, we use "aborting the handshake" as shorthand for
terminating the handshake by sending a fatal
<spanx style="verb">handshake_failure</spanx> alert.
</t>
<t>
In all handshakes, a client implementing this document MUST
send the <spanx style="verb">extended_master_secret</spanx> extension
in its ClientHello.
</t>
<t>
If a server implementing this document
receives the <spanx style="verb">extended_master_secret</spanx> extension,
it MUST include the <spanx style="verb">extended_master_secret</spanx> extension
in its ServerHello message.
</t>
<t>
If the server receives a ClientHello without the extension, it
SHOULD abort the handshake.
If it chooses to continue, then it MUST NOT include the extension
in the ServerHello.
</t>
<t>
If a client receives a ServerHello without the extension,
it SHOULD abort the handshake.
</t>
<t>
In a full handshake, if both the ClientHello and ServerHello
contain the extension, the new session uses the
extended master secret computation.
</t>
<t>
Some clients and servers may choose to continue a full handshake
without the extension, in order to interoperate with legacy peers.
In this case, they use the standard master secret derivation for the new session,
and the considerations in <xref target="interop" /> apply.
</t>
</section>
<section title="Client and Server Behavior: Abbreviated Handshake">
<t>
The client SHOULD NOT offer an abbreviated handshake to resume
a session that does not use an extended master secret.
The client MUST send the <spanx style="verb">extended_master_secret</spanx> extension
in its ClientHello.
</t>
<t>
If a server receives a ClientHello for an abbreviated handshake
offering to resume a previous session, it behaves as follows.
<list style="symbols">
<t>
If the new ClientHello does not contain
the <spanx style="verb">extended_master_secret</spanx>
extension, the server SHOULD abort the handshake.
If it continues with an abbreviated handshake
in order to interoperate with legacy peers,
then the considerations in <xref target="interop" /> apply.
</t>
<t>
If the original session did not use an extended master secret
but the new ClientHello does contain
the <spanx style="verb">extended_master_secret</spanx>
extension, the server MUST NOT perform the abbreviated handshake.
Instead, it SHOULD continue with a full handshake to negotiate
a new session.
</t>
<t>
If the ClientHello contains the extension and the server decides
to accept the abbreviated handshake, then the server
MUST include the <spanx style="verb">extended_master_secret</spanx>
extension in its ServerHello message.
</t>
</list>
</t>
<t>
If a client receives a ServerHello that accepts an abbreviated handshake,
it behaves as follows.
<list style="symbols">
<t>
If the original session did not use an extended master secret
but the new ServerHello does contain
the <spanx style="verb">extended_master_secret</spanx>
extension, the client MUST abort the handshake.
</t>
<t>
If the new ServerHello does not contain
the <spanx style="verb">extended_master_secret</spanx>
extension, the client SHOULD abort the handshake.
If it continues with an abbreviated handshake
in order to interoperate with legacy peers, then
the considerations in <xref target="interop" /> apply.
</t>
</list>
</t>
<t>
If the client and server continue the abbreviated handshake,
they derive the connection keys for the new session as usual
from the master secret of the original connection.
</t>
</section>
<section title="Interoperability Considerations" anchor="interop">
<t>
To allow interoperability with legacy clients and servers,
a TLS peer may decide to accept handshakes that use
the legacy master secret computation. If so, they
need to differentiate between sessions that use legacy
and extended master secrets by adding a flag to the session state.
</t>
<t>
If a client or server chooses to continue with a full handshake
without the extended master secret extension, the new session
is vulnerable to the man-in-the-middle key synchronization attack
described in <xref target="intro"/>.
Hence, the client or server MUST NOT export any key material based
on the new master secret for any subsequent
application-level authentication. In particular, it MUST
disable <xref target="RFC5705"/> and any EAP
protocol relying on compound authentication <xref target="COMPOUND-AUTH"/>.
</t>
<t>
If a client or server chooses to continue an abbreviated handshake
to resume a session that does not use the extended master secret,
then the current connection is vulnerable to a man-in-the-middle
handshake log synchronization attack as described in <xref target="intro"/>.
Hence, the client or server MUST NOT use the
current handshake's <spanx style="verb">verify_data</spanx>
for application-level authentication. In particular,
the client should disable renegotiation and
any use of the <spanx style="verb">tls-unique</spanx>
channel binding <xref target="RFC5929"/> on the current connection.
</t>
<t>
If the original session uses an extended master secret, but
the ClientHello or ServerHello in the abbreviated handshake
does not include the extension, it MAY be safe to continue
the abbreviated handshake since it is protected from the
man-in-the-middle attack by the extended master secret.
This scenario may occur, for example, when a server
that implements this extension establishes a session,
but the session is subsequently resumed at a different
server that does not support the extension.
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<section title="Triple Handshake Preconditions and Impact" anchor="impact">
<t>
One way to mount a triple handshake attack has been described in <xref target="intro"/>,
along with a mention of the security mechanisms that break due to the attack;
more in-depth discussion
and diagrams can be found in <xref target="TRIPLE-HS"/>. Here, some further discussion is
presented about attack preconditions and impact.
</t>
<t>
To mount a triple handshake attack, it must be possible to force
the same master secret on two different sessions. For this to happen,
two preconditions must be met:
<list style="symbols">
<t>The client, C, must be willing to connect to a malicious server, A. In certain contexts, like the web, this can be easily achieved,
since a browser can be instructed to load content from an untrusted origin.</t>
<t>The pre-master secret must be synchronized on the two sessions. This is particularly easy to achieve
with the RSA and DHE key exchanges, but under some conditions, ECDHE, SRP, and PSK
key exchanges can be exploited to this effect as well.</t>
</list>
Once the master secret is synchronized on two sessions, any security property that relies on the uniqueness of the master
secret is compromised. For example, a TLS exporter <xref target="RFC5705"/> no longer provides a unique key bound to the current
session.
</t>
<t>
TLS session resumption also relies on the uniqueness of the master secret to authenticate the resuming peers. Hence,
if a synchronized session is resumed, the peers cannot be sure about each other's identities, and the attacker knows
the connection keys. Clearly, a precondition to this step of the attack is that both client and server support
session resumption (either via session identifier or session tickets <xref target="RFC5077"/>).
</t>
<t> Additionally, in a synchronized abbreviated handshake, the whole transcript is synchronized, which includes the <spanx style="verb">verify_data</spanx>
values. So, after an abbreviated handshake, channel bindings like <spanx style="verb">tls-unique</spanx> <xref target="RFC5929"/> will not
identify uniquely the connection anymore.
</t>
<t>
Synchronization of the <spanx style="verb">verify_data</spanx> in abbreviated handshakes also undermines the
security guarantees of the renegotiation indication extension <xref target="RFC5746"/>,
re-enabling a prefix-injection flaw similar to the renegotiation attack <xref target="Ray09"/>.
However, in a triple handshake attack, the client sees the server certificate changing across different full handshakes.
Hence, a precondition to mount this stage of the
attack is that the client accepts different certificates at each handshake, even if their common names do not match. Before
the triple handshake attack was discovered, this used to be widespread behavior, at least among some web browsers, that
were hence vulnerable to the attack.
</t>
<t>
The extended master secret extension thwarts triple handshake attacks at their first stage, by ensuring that
different sessions necessarily end up with different master secret values. Hence, all security properties
relying on the uniqueness of the master secret are now expected to hold. In particular, if a TLS session
is protected by the extended master secret extension, it is safe to resume it, to use its channel bindings,
and to allow for certificate changes across renegotiation, meaning that all certificates are controlled by the same
peer. A symbolic cryptographic protocol analysis justifying the extended master secret extension appears in
<xref target="VERIFIED-BINDINGS" />.
</t>
</section>
<section title="Cryptographic Properties of the Hash Function">
<t>
The session hashes of two different sessions need to be distinct, hence
the <spanx style="verb">Hash</spanx> function used to compute the
<spanx style="verb">session_hash</spanx> needs to be collision resistant.
As such, hash functions such as MD5 or SHA1 are NOT RECOMMENDED.
</t>
<t>
We observe that the <spanx style="verb">Hash</spanx> function
used in the Finished message computation already needs to be
collision resistant for the renegotiation indication
extension <xref target="RFC5746"/> to work, because a meaningful
collision on the handshake messages (and hence on
the <spanx style="verb">verify_data</spanx>) may re-enable the
renegotiation attack <xref target="Ray09"/>.
</t>
<t>
The hash function used to compute the session hash depends on the TLS protocol version.
All current ciphersuites defined for TLS 1.2 use SHA256 or better, and
so does the session hash.
For earlier versions of the protocol, only MD5 and SHA1 can be assumed to be supported,
and this document does not require legacy implementations to add support for new hash functions.
In these versions, the session hash uses the concatenation of MD5 and SHA1,
as in the Finished message.
</t>
</section>
<section title="Handshake Messages included in the Session Hash">
<t>
The <spanx style="verb">session_hash</spanx> is intended to
encompass all relevant session information, including
ciphersuite negotiation, key exchange messages and client and
server identities. The session hash needs to be available
to compute the extended master secret before the Finished
messages.
</t>
<t>
This document sets
the <spanx style="verb">session_hash</spanx> to cover all
handshake messages up to and including the
ClientKeyExchange. For existing TLS ciphersuites, these
messages include all the significant contents of the new
session---CertificateVerify does not change the
session content. At the same time, this allows the extended
master secret to be computed immediately after the pre-master secret,
so that implementations can shred the temporary
pre-master secret from memory as early as possible.
</t>
<t>
It is possible that new ciphersuites or TLS extensions may
include additional messages between ClientKeyExchange and
Finished that add important session context. In such cases,
some of the security guarantees of this specification may no
longer apply, and new man-in-the-middle attacks may be
possible. For example, if the client and server support the
session ticket extension <xref target="RFC5077"/>, the session
hash does not cover the new session ticket sent by the server.
Hence, a man-in-the-middle may be able to cause a client to
store a session ticket that was not meant for the current
session. Attacks based on this vector are not yet known, but
applications that store additional information in session
tickets beyond those covered in the session hash require
careful analysis.
</t>
</section>
<section title="No SSL 3.0 Support">
<t>
SSL 3.0 <xref target="RFC6101"/> is a predecessor of the TLS protocol, and it is equally vulnerable to the
triple handshake attacks, alongside other vulnerabilities stemming from its use of obsolete
cryptographic constructions that are now considered weak.
</t>
<t>
The countermeasure described in this document relies on a TLS extension and hence cannot be
used with SSL 3.0. Clients and servers implementing this document SHOULD refuse SSL 3.0
handshakes. If they choose to support SSL 3.0, the resulting sessions MUST
use the legacy master secret computation, and the interoperability considerations
of <xref target="interop"/> apply.
</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
IANA has added the extension code point 23 (0x0017), which has
been used by prototype implementations, for the "extended_master_secret"
extension to the TLS ExtensionType values registry
as specified in <xref target="RFC5246">TLS</xref>.
</t>
</section>
<section anchor="acknowledgements" title="Acknowledgments">
<t>
The triple handshake attacks were originally discovered by Antoine Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were further developed by the miTLS team: Cédric Fournet, Pierre-Yves Strub, Markulf Kohlweiss, Santiago Zanella-Béguelin. Many of the ideas in this draft emerged from discussions with
Martín Abadi,
Ben Laurie,
Nikos Mavrogiannopoulos,
Manuel Pégourié-Gonnard,
Eric Rescorla,
Martin Rex,
Brian Smith.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="bibxml/reference.RFC.2119.xml"?>
<?rfc include="bibxml/reference.RFC.5246.xml"?>
</references>
<references title="Informative References">
<?rfc include="bibxml/reference.RFC.5746.xml"?>
<?rfc include="bibxml/reference.RFC.5705.xml"?>
<?rfc include="bibxml/reference.RFC.5929.xml"?>
<?rfc include="bibxml/reference.RFC.4251.xml"?>
<?rfc include="bibxml/reference.RFC.5077.xml"?>
<?rfc include="bibxml/reference.RFC.6101.xml"?>
<reference anchor='TRIPLE-HS'>
<front>
<title>Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS</title>
<author initials='K.' surname='Bhargavan'
fullname='Karthikeyan Bhargavan'>
</author>
<author initials='A.' surname='Delignat-Lavaud'
fullname='Antoine Delignat-Lavaud'>
</author>
<author initials='C.' surname='Fournet'
fullname='Cédric Fournet'>
</author>
<author initials='A.' surname='Pironti'
fullname='Alfredo Pironti'>
</author>
<author initials='P-Y.' surname='Strub'
fullname='Pierre-Yves Strub'>
</author>
<date year='2014' />
</front>
<seriesInfo name="IEEE Symposium on Security and Privacy (Oakland)" value=""/>
</reference>
<reference anchor='VERIFIED-BINDINGS'>
<front>
<title>Verified Contributive Channel Bindings for Compound Authentication</title>
<author initials='K.' surname='Bhargavan'
fullname='Karthikeyan Bhargavan'>
</author>
<author initials='A.' surname='Delignat-Lavaud'
fullname='Antoine Delignat-Lavaud'>
</author>
<author initials='A.' surname='Pironti'
fullname='Alfredo Pironti'>
</author>
<date year='2015' />
</front>
<seriesInfo name="Network and Distributed System Security Symposium (NDSS)" value=""/>
</reference>
<reference anchor='SP800-108'>
<front>
<title>Recommendation for Key Derivation Using Pseudorandom Functions (Revised)</title>
<author initials='L.' surname='Chen'
fullname='Lidong Chen'>
</author>
<date year='2009' />
</front>
<seriesInfo name = "NIST Special Publication 800-108" value=""/>
</reference>
<reference anchor='COMPOUND-AUTH'>
<front>
<title>Man-in-the-middle in tunnelled authentication protocols</title>
<author initials='N.' surname='Asokan' fullname='Nadarajah Asokan'></author>
<author initials='N.' surname='Valtteri' fullname='Niemi Valtteri'></author>
<author initials='K.' surname='Nyberg' fullname='Kaisa Nyberg'></author>
<date year='2005' />
</front>
<seriesInfo name="Security Protocols, Springer LNCS Volume 3364" value=""/>
</reference>
<reference anchor='Ray09'>
<front>
<title>Authentication Gap in TLS Renegotiation</title>
<author initials='M.' surname='Ray' fullname='Marsh Ray'></author>
<date year='2009' />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:11:21 |