idnits 2.17.1 draft-mavrogiannopoulos-tls-server-key-exchage-00.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 (May 15, 2012) is 4362 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'WS-ATTACK' ** 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 (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Mavrogiannopoulos 3 Internet-Draft KU Leuven - IBBT 4 Intended status: Standards Track May 15, 2012 5 Expires: November 16, 2012 7 Preventing cross-protocol attacks in TLS protocol 8 draft-mavrogiannopoulos-tls-server-key-exchage-00 10 Abstract 12 This memo proposes a fix in the TLS ServerKeyExchange message 13 signature, 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 November 16, 2012. 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 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. The Wagner and Schneier attack . . . . . . . . . . . . . . . . 3 52 4. The new ServerKeyExchange signature . . . . . . . . . . . . . . 4 53 5. The extension . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 6. Security considerations . . . . . . . . . . . . . . . . . . . . 6 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 58 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 60 1. Introduction 62 The TLS protocol [RFC5246] suffers from an issue in the 63 ServerKeyExchange message signature discovered by Wagner and Schneier 64 in [WS-ATTACK]. They describe a cross-protocol attack on the SSL 3.0 65 [RFC6101] protocol, that re-uses a signed ServerKeyExchange packet in 66 another session with a different key exchange algorithm. In effect 67 the attack uses a server as an oracle that transmits signed 68 ServerKeyExchange messages that can be relayed to another, unrelated, 69 session. The described attack turned to be impossible to implement 70 in practice, but the underlying idea is applicable to all TLS 71 protocol versions, and as the supported key exchange algorithms 72 increase, it provides a tool for new attacks on the protocol [ref 73 needed]. 75 In this document we propose a fix for the TLS protocol that does not 76 require a protocol version upgrade. 78 2. Terminology 80 This document uses the same notation and terminology used in the TLS 81 Protocol specification [RFC5246]. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 3. The Wagner and Schneier attack 89 Wagner and Schneier in [WS-ATTACK] describe a cross-protocol attack 90 (The authors refer to it as "key exchange algorithm rollback attack") 91 based on the observation that the digital signature in a Diffie- 92 Hellman key exchange does not cover any identifier of the negotiated 93 ciphersuite. According to the SSL 3.0 protocol [RFC6101] when a 94 Diffie-Hellman key exchange has been negotiated, the group parameters 95 are sent by the server in the ServerKeyExchange message as shown 96 below. 98 struct { 99 select (KeyExchangeAlgorithm) { 100 case diffie_hellman: 101 opaque dh_p<1..2^16-1>; 102 opaque dh_g<1..2^16-1>; 103 opaque dh_Ys<1..2^16-1>; 104 Signature signed_params; 105 case rsa: 106 opaque rsa_modulus<1..2^16-1>; 107 opaque rsa_exponent<1..2^16-1>; 108 Signature signed_params; 109 }; 110 } ServerKeyExchange; 112 The signature on that message is calculated on the algorithm 113 parameters, and the nonces exchanged by both peers. The crucial 114 observation is that the negotiated key exchange algorithm is not part 115 of this signature. 117 This omission allows an adversary to re-use a signed 118 ServerKeyExchange packet in another session, with another key 119 exchange algorithm, by initiating a parallel connection to the 120 server. In particular, the described in [WS-ATTACK] attack deceives 121 a client who advertises a TLS_RSA_EXPORT ciphersuite and expects 122 temporary RSA parameters in the ServerKeyExchange message, into 123 receiving Diffie-Hellman parameters from a TLS_DHE_RSA ciphersuite. 125 The attack is based on a wrong assumption in the TLS packet parsing, 126 which prevents it from being practical. It demonstrates, however, 127 the idea of a cross-protocol attack utilizing two of the SSL 3.0 key 128 exchange methods, the Diffie-Hellman and the RSA-EXPORT key 129 exchanges. 131 4. The new ServerKeyExchange signature 133 The goal of this memo is to restrict the applicability of the server 134 provided signed ServerKeyExchange to the current session. A simple 135 fix may be to include the negotiated ciphersuite into the signature. 136 However, the TLS protocol is complex and a key exchange method does 137 not always imply a single format of the ServerKeyExchange signature. 138 For example, the elliptic curves key exchange method may be used with 139 an arbitrary elliptic curve [RFC4492] which requires different data 140 in the ServerKeyExchange than when used with a named curve. Such key 141 exchange suboptions are negotiated using TLS extensions and such 142 extensions should be covered by the signature, to prevent any attack 143 that takes advantage of the different signature format. 145 For that we propose that the signature of the ServerKeyExchange 146 message to be modified to include in addition to explicit identifiers 147 of the algorithms, all the previously exchanged messages. The 148 proposed signature for a ServerKeyExchange message is shown below. 150 enum { server (0), client (1) } ConnectionEnd; 152 enum { dhe_dss (0), dhe_rsa (1), 153 ec_diffie_hellman (2) 154 } KeyExchangeAlgorithm; 156 struct { 157 digitally-signed struct { 158 ConnectionEnd entity; 159 KeyExchangeAlgorithm kx_algorithm; 160 select (KeyExchangeAlgorithm) { 161 case dhe_dss: 162 case dhe_rsa: 163 ServerDHParams params; 164 case ec_diffie_hellman: 165 ServerECDHParams; 166 } 167 opaque handshake_messages<0..2^24-1>; 168 } 169 } ServerKeyExchange; 171 The new format includes explicit indicators of the entity (server), 172 the key exchange algorithm used, the handshake messages exchanged, 173 and the parameters of the key exchange. This modification will be 174 negotiated by using a new TLS extension to allow backwards 175 compatibility. 177 5. The extension 179 In order for a client to advertise its support for the new 180 ServerKeyExchange foramt we add a new extension 181 "new_server_key_exchange", with value TBD-BY-IANA, to the enumerated 182 ExtensionType defined in [RFC5246]. Clients MAY include the 183 extension of type "new_server_key_exchange" in the (extended) client 184 hello. The "extension_data" field of this extension MUST be empty. 186 Servers that receive an extended client hello containing a 187 "new_server_key_exchange" extension, MAY accept the request for the 188 new ServerKeyExchange format by including an extension of type 189 "new_server_key_exchange" in the (extended) server hello. The 190 "extension_data" field of this extension MUST be empty. 192 Note that this extension is valid for all versions of the TLS 193 protocol including TLS 1.2 [RFC5246] and SSL 3.0 [RFC6101]. 195 6. Security considerations 197 This extension modifies the ServerKeyExchange message in order to 198 prevent attacks to the protocol similar in nature with the Wagner and 199 Schneier attack. In order for the protection to be applicable, both 200 the client and the server must support this extension. In the case 201 where either or none support this extension, the old vulnerable 202 format is being used. 204 7. IANA Considerations 206 This document defines the TLS extension "new_server_key_exchange" 207 (value TBD-BY-IANA) whose value should be assigned from the TLS 208 ExtensionType Registry defined in [RFC5246]. 210 8. References 212 8.1. Normative References 214 [WS-ATTACK] Wagner, D. and B. Schneier, "WS-ATTACK of the SSL 3.0 215 protocol", The Second USENIX Workshop on Electronic 216 Commerce Proceedings, USENIX Press , November 1996. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 222 Security (TLS) Protocol Version 1.2", RFC 5246, 223 August 2008. 225 8.2. Informative References 227 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 228 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 229 August 2011. 231 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and 232 B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher 233 Suites for Transport Layer Security (TLS)", RFC 4492, 234 May 2006. 236 Author's Address 238 Nikos Mavrogiannopoulos 239 KU Leuven ESAT/SCD/COSIC - IBBT 240 Kasteelpark Arenberg 10, bus 2446 241 Leuven-Heverlee, B-3001 242 Belgium 244 EMail: nikos.mavrogiannopoulos@esat.kuleuven.be