idnits 2.17.1 draft-mavrogiannopoulos-tls-cross-protocol-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 9, 2012) is 4157 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Mavrogiannopoulos 3 Internet-Draft B. Preneel 4 Intended status: Standards Track KU Leuven - IBBT 5 Expires: May 13, 2013 November 9, 2012 7 Preventing cross-protocol attacks on the TLS protocol 8 draft-mavrogiannopoulos-tls-cross-protocol-03 10 Abstract 12 This memo proposes a fix in the TLS key exchange signature generation 13 to prevent cross-protocol attacks. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on May 13, 2013. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 1. Introduction 49 The TLS protocol [RFC5246] suffers from an issue in the 50 ServerKeyExchange message signature discovered by Wagner and Schneier 51 in [WS-ATTACK]. They describe a cross-protocol attack on the SSL 3.0 52 [RFC6101] protocol, that re-uses a signed ServerKeyExchange packet in 53 another session with a different key exchange algorithm. In effect 54 the attack uses a server as an oracle to obtain signed 55 ServerKeyExchange messages that are relayed to another, unrelated, 56 session. The described attack turned to be impossible to implement 57 in practice, but the underlying idea is applicable to all TLS 58 protocol versions, and it provides a tool for new attacks on the 59 protocol. The [CROSS-PROTOCOL] attack is a prominent example, which 60 takes advantage of interactions between the Diffie-Hellman and 61 Elliptic Curve Diffie-Hellman ciphersuites to perform a TLS server 62 impersonation after obtaining 2^40 signed messages. 64 In this document we propose a fix for the TLS protocol which makes it 65 immune to these attacks, but does not require a protocol version 66 upgrade. 68 2. Terminology 70 This document uses the same notation and terminology used in the TLS 71 Protocol specification [RFC5246]. 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 3. The new ServerKeyExchange signature 79 The goal of this memo is to restrict the applicability of the server 80 provided signed ServerKeyExchange to the current session. A simple 81 fix may be to include the negotiated ciphersuite into the signature. 82 However, the TLS protocol is complex and a key exchange method does 83 not always imply a single format of the ServerKeyExchange signature. 84 For example, the elliptic curves key exchange method may be used with 85 an arbitrary elliptic curve [RFC4492] which requires different data 86 in the ServerKeyExchange than when used with a named curve. Such key 87 exchange suboptions are negotiated using TLS extensions and such 88 extensions should be covered by the signature to prevent any attack 89 that takes advantage of the different signature format. 91 For that we propose that the signature of the ServerKeyExchange 92 message to be modified to include in addition to explicit identifiers 93 of the algorithms, all the previously exchanged messages. The 94 proposed signature for a ServerKeyExchange message is shown below. 96 enum { server (0), client (1) } ConnectionEnd; 98 enum { dhe_dss (0), dhe_rsa (1), 99 ec_diffie_hellman (2) 100 } KeyExchangeAlgorithm; 102 struct { 103 KeyExchangeAlgorithm kx_algorithm; 104 select (KeyExchangeAlgorithm) { 105 case dhe_dss: 106 case dhe_rsa: 107 ServerDHParams params; 108 case ec_diffie_hellman: 109 ServerECDHParams; 110 } 111 } Parameters; 113 struct { 114 Parameters params; 115 digitally-signed struct { 116 ConnectionEnd entity; 117 Parameters params; 118 opaque handshake_messages<0..2^24-1>; 119 } 120 } ServerKeyExchange; 122 The new format includes explicit indicators of the entity (server), 123 the key exchange algorithm used, the parameters of the key exchange, 124 and the previously exchanged handshake messages. This modification 125 will be negotiated by using a new TLS extension to allow backwards 126 compatibility. 128 4. The extension 130 In order for a client to advertise its support for the new 131 ServerKeyExchange format we add a new extension 132 "new_server_key_exchange", with value TBD-BY-IANA, to the enumerated 133 ExtensionType defined in [RFC5246]. The "extension_data" field of 134 this extension is empty. 136 5. Server and client behavior 138 Clients, that wish to protect against cross-protocol attacks, SHOULD 139 include the extension of type "new_server_key_exchange" in the 140 (extended) client hello. 142 Servers that receive an extended client hello containing a 143 "new_server_key_exchange" extension, MAY accept the request for the 144 new ServerKeyExchange format by including an extension of type 145 "new_server_key_exchange" in the extended server hello. 147 Servers compliant to this document, that did not receive the 148 extension MUST set the gmt_unix_time part of the Random value 149 included in ServerHello to zero. Because in cross-protocol attacks 150 the server's random value is redirected to the client, this is a way 151 for the server to indicate support for the extension even in the 152 presence of an adversary. 154 Clients compliant to this document, that advertised this extension 155 but didn't receive a corresponding extension from the server, MUST 156 check the gmt_unix_time part of the Random value included in 157 ServerHello message for the value zero. If the gmt_unix_time is zero 158 the client MUST abort the handshake with an "illegal_parameter" fatal 159 alert. 161 Note that this extension is applies to all versions of the TLS 162 protocol including TLS 1.2 [RFC5246] and SSL 3.0 [RFC6101]. 164 6. Security considerations 166 This extension modifies the ServerKeyExchange message in order to 167 prevent attacks to the protocol similar in nature with the Wagner and 168 Schneier attack. In order for the protection to be applicable, both 169 the client and the server must support this extension. 171 Compliant servers that did not receive the extension from the client 172 are required to set the 4 bytes of the server's random value, that 173 encodes the time, as zero. This provides a tool to indicate support 174 for the extended format even in the presence of an adversary, but 175 comes at the cost of reducing the total randomness from the server 176 from 32 bytes to 28 bytes. 178 7. IANA Considerations 180 This document defines the TLS extension "new_server_key_exchange" 181 (value TBD-BY-IANA) whose value should be assigned from the TLS 182 ExtensionType Registry defined in [RFC5246]. 184 8. References 186 8.1. Normative References 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, March 1997. 191 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 192 Security (TLS) Protocol Version 1.2", RFC 5246, 193 August 2008. 195 8.2. Informative References 197 [WS-ATTACK] Wagner, D. and B. Schneier, "Analysis of the SSL 198 3.0 protocol", In Proceedings of the Second USENIX 199 Workshop on Electronic Commerce, USENIX Press , 200 November 1996. 202 [CROSS-PROTOCOL] Mavrogiannopoulos, N., Vercauteren, F., Velichkov, 203 V., and B. Preneel, "A cross-protocol attack on the 204 TLS protocol", In Proceedings of the 19th ACM 205 Conference on Computer and Communications Security 206 (CCS 2012), ACM , October 2012. 208 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 209 Sockets Layer (SSL) Protocol Version 3.0", 210 RFC 6101, August 2011. 212 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., 213 and B. Moeller, "Elliptic Curve Cryptography (ECC) 214 Cipher Suites for Transport Layer Security (TLS)", 215 RFC 4492, May 2006. 217 Authors' Addresses 219 Nikos Mavrogiannopoulos 220 KU Leuven ESAT/SCD/COSIC 221 Kasteelpark Arenberg 10, bus 2446 222 Leuven-Heverlee, B-3001 223 Belgium 225 EMail: nikos.mavrogiannopoulos@esat.kuleuven.be 227 Bart Preneel 228 KU Leuven ESAT/SCD/COSIC 229 Kasteelpark Arenberg 10, bus 2446 230 Leuven-Heverlee, B-3001 231 Belgium 233 EMail: bart.preneel@esat.kuleuven.be