< draft-ietf-tls-session-hash-00.txt   draft-ietf-tls-session-hash-01.txt >
Network Working Group K. Bhargavan Network Working Group K. Bhargavan
Internet-Draft A. Delignat-Lavaud Internet-Draft A. Delignat-Lavaud
Expires: February 20, 2015 A. Pironti Expires: February 23, 2015 A. Pironti
Inria Paris-Rocquencourt Inria Paris-Rocquencourt
A. Langley A. Langley
Google Inc. Google Inc.
M. Ray M. Ray
Microsoft Corp. Microsoft Corp.
August 19, 2014 August 22, 2014
Transport Layer Security (TLS) Session Hash and Transport Layer Security (TLS) Session Hash and
Extended Master Secret Extension Extended Master Secret Extension
draft-ietf-tls-session-hash-00 draft-ietf-tls-session-hash-01
Abstract Abstract
The Transport Layer Security (TLS) master secret is not The Transport Layer Security (TLS) master secret is not
cryptographically bound to important session parameters such as the cryptographically bound to important session parameters such as the
client and server identities. Consequently, it is possible for an client and server identities. Consequently, it is possible for an
active attacker to set up two sessions, one with a client and another 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 with a server, such that the master secrets on the two sessions are
the same. Thereafter, any mechanism that relies on the master secret the same. Thereafter, any mechanism that relies on the master secret
for authentication, including renegotiation after session resumption, for authentication, including session resumption, becomes vulnerable
becomes vulnerable to a man-in-the-middle attack, where the attacker to a man-in-the-middle attack, where the attacker can simply forward
can simply forward messages back and forth between the client and messages back and forth between the client and server. This
server. This specification defines a TLS extension that contextually specification defines a TLS extension that contextually binds the
binds the master secret to a log of the full handshake that computes master secret to a log of the full handshake that computes it, thus
it, thus preventing such attacks. preventing such attacks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 20, 2015. This Internet-Draft will expire on February 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 5 3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 5
4. The extended master secret . . . . . . . . . . . . . . . . . 5 4. The extended master secret . . . . . . . . . . . . . . . . . 5
5. Extension negotiation . . . . . . . . . . . . . . . . . . . . 6 5. Extension negotiation . . . . . . . . . . . . . . . . . . . . 6
5.1. Extension definition . . . . . . . . . . . . . . . . . . 6 5.1. Extension definition . . . . . . . . . . . . . . . . . . 6
5.2. Client and Server Behavior . . . . . . . . . . . . . . . 6 5.2. Client and Server Behavior . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
In TLS [RFC5246], every session has a "master_secret" computed as: In TLS [RFC5246], every session has a "master_secret" computed as:
master_secret = PRF(pre_master_secret, "master secret", master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random) ClientHello.random + ServerHello.random)
[0..47]; [0..47];
where the "pre_master_secret" is the result of some key exchange where the "pre_master_secret" is the result of some key exchange
skipping to change at page 3, line 30 skipping to change at page 3, line 31
"pre_master_secret", encrypted with A's public key. A decrypts "pre_master_secret", encrypted with A's public key. A decrypts
the "pre_master_secret", re-encrypts it with S's public key and the "pre_master_secret", re-encrypts it with S's public key and
sends it on to S. sends it on to S.
6. C sends a "Finished" to A. A computes a "Finished" for its 6. C sends a "Finished" to A. A computes a "Finished" for its
connection with S, and sends it to S. connection with S, and sends it to S.
7. S sends a "Finished" to A. A computes a "Finished" for its 7. S sends a "Finished" to A. A computes a "Finished" for its
connection with C, and sends it to C. connection with C, and sends it to C.
At this point, both connection (between C and A, and between A and S) At this point, both connections (between C and A, and between A and
have new sessions that share the same "pre_master_secret", S) have new sessions that share the same "pre_master_secret",
"ClientHello.random", "ServerHello.random", as well as other session "ClientHello.random", "ServerHello.random", as well as other session
parameters, including the session identifier and, optionally, the parameters, including the session identifier and, optionally, the
session ticket. Hence, the "master_secret" value will be equal for session ticket. Hence, the "master_secret" value will be equal for
the two sessions and it will be associated both at C and S with the 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 same session ID, even though the server identities on the two
connections are different. Moreover, the record keys on the two connections are different. Moreover, the record keys on the two
connections will also be the same. connections will also be the same.
Similar scenarios can be achieved when the handshake uses a DHE Similar scenarios can be achieved when the handshake uses a DHE
ciphersuite, or an ECDHE ciphersuite with an arbitrary explicit ciphersuite, or an ECDHE ciphersuite with an arbitrary explicit
curves. Even if the client or server does not prefer using RSA or curve. 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, the attacker can force them to use it by offering only RSA or
DHE in its hello messages. Other key exchanges may also be DHE in its hello messages. Other key exchanges may also be
vulnerable. If client authentication is used, the attack still vulnerable. If client authentication is used, the attack still
works, except that the two sessions now differ on both client and works, except that the two sessions now differ on both client and
server identities. server identities.
Once A has synchronized the two connections, since the keys are the Once A has synchronized the two connections, since the keys are the
same on the two sides, it can step away and transparently forward same on the two sides, it can step away and transparently forward
messages between C and S, reading and modifying when it desires. In messages between C and S, reading and modifying when it desires. In
the key exchange literature, such occurrences are called unknown key- the key exchange literature, such occurrences are called unknown key-
share attacks, since C and S share a secret but they both think that share attacks, since C and S share a secret but they both think that
their secret is shared only with A. In itself, these attacks do not their secret is shared only with A. In themselves, these attacks do
break integrity or confidentiality between honest parties, but they not break integrity or confidentiality between honest parties, but
offer a useful starting point from which to mount impersonation they offer a useful starting point from which to mount impersonation
attacks on C and S. attacks on C and S.
Suppose C tries to resume its session on a new connection with A. A 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 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 messages unchanged between C and S. Since
the abbreviated handshake only relies on the master secret for the abbreviated handshake only relies on the master secret for
authentication, and does not mention client or server identities, authentication, and does not mention client or server identities,
both handshakes complete successfully, resulting in the same session both handshakes complete successfully, resulting in the same session
keys and the same handshake log. A still knows the connection keys keys and the same handshake log. A still knows the connection keys
and can send messages to both C and S. and can send messages to both C and S.
skipping to change at page 6, line 46 skipping to change at page 6, line 46
extension to be included anyway makes the extension negotiation logic extension to be included anyway makes the extension negotiation logic
easier, because it does not depend on whether resumption is accepted easier, because it does not depend on whether resumption is accepted
or not. Moreover, a client may find useful to learn that the server or not. Moreover, a client may find useful to learn that the server
supports this extension anyway. supports this extension anyway.
6. Security Considerations 6. Security Considerations
This entire document is about security, see [TRIPLE-HS] for more This entire document is about security, see [TRIPLE-HS] for more
details. details.
7. Acknowledgments 7. IANA Considerations
IANA is requested to assign an extension code point for the
extended_master_secret extension to the TLS ExtensionType values
registry as specified in TLS [RFC5246].
8. Acknowledgments
The triple handshake attacks were originally discovered by Antoine The triple handshake attacks were originally discovered by Antoine
Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were
further developed by the miTLS team: Cedric Fournet, Pierre-Yves further developed by the miTLS team: Cedric Fournet, Pierre-Yves
Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the
ideas in this draft emerged from discussions with Martin Abadi, Ben ideas in this draft emerged from discussions with Martin Abadi, Ben
Laurie, Eric Rescorla, Martin Rex, Brian Smith. Laurie, Eric Rescorla, Martin Rex, Brian Smith.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
8.2. Informative References 9.2. Informative References
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication "Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010. Extension", RFC 5746, February 2010.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010. Layer Security (TLS)", RFC 5705, March 2010.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010. for TLS", RFC 5929, July 2010.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006. Protocol Architecture", RFC 4251, January 2006.
[TRIPLE-HS] [TRIPLE-HS]
Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
A., and P. Strub, "Triple Handshakes and Cookie Cutters: A., and P. Strub, "Triple Handshakes and Cookie Cutters:
Breaking and Fixing Authentication over TLS", IEEE Breaking and Fixing Authentication over TLS", IEEE
Symposium on Security and Privacy, to appear , 2014. Symposium on Security and Privacy, pages 98-113 , 2014.
[sp800-108] [sp800-108]
Chen, L., "NIST Special Publication 800-108: Chen, L., "NIST Special Publication 800-108:
Recommendation for Key Derivation Using Pseudorandom Recommendation for Key Derivation Using Pseudorandom
Functions", Unpublished draft , 2009. Functions", Unpublished draft , 2009.
Authors' Addresses Authors' Addresses
Karthikeyan Bhargavan Karthikeyan Bhargavan
Inria Paris-Rocquencourt Inria Paris-Rocquencourt
 End of changes. 15 change blocks. 
27 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/