Preventing cross-protocol attacks in TLS protocol
draft-mavrogiannopoulos-tls-cross-protocol-00

Network Working Group                               N. Mavrogiannopoulos
Internet-Draft                                          KU Leuven - IBBT
Intended status: Standards Track                            June 1, 2012
Expires: December 3, 2012

           Preventing cross-protocol attacks in TLS protocol
             draft-mavrogiannopoulos-tls-cross-protocol-00

Abstract

   This memo proposes a fix in the TLS ServerKeyExchange message
   signature, to prevent cross-protocol attacks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 3, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Mavrogiannopoulos       Expires December 3, 2012                [Page 1]
Internet-Draft    Preventing TLS cross-protocol attacks        June 2012

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  The Wagner and Schneier attack  . . . . . . . . . . . . . . . . 3
   4.  The new ServerKeyExchange signature . . . . . . . . . . . . . . 4
   5.  The extension . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Server and client behavior  . . . . . . . . . . . . . . . . . . 5
   7.  Security considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7

Mavrogiannopoulos       Expires December 3, 2012                [Page 2]
Internet-Draft    Preventing TLS cross-protocol attacks        June 2012

1.  Introduction

   The TLS protocol [RFC5246] suffers from an issue in the
   ServerKeyExchange message signature discovered by Wagner and Schneier
   in [WS-ATTACK].  They describe a cross-protocol attack on the SSL 3.0
   [RFC6101] protocol, that re-uses a signed ServerKeyExchange packet in
   another session with a different key exchange algorithm.  In effect
   the attack uses a server as an oracle to obtain signed
   ServerKeyExchange messages that are relayed to another, unrelated,
   session.  The described attack turned to be impossible to implement
   in practice, but the underlying idea is applicable to all TLS
   protocol versions, and as the supported key exchange algorithms
   increase, it provides a tool for new attacks on the protocol [ref
   needed].

   In this document we propose a fix for the TLS protocol that does not
   require a protocol version upgrade.

2.  Terminology

   This document uses the same notation and terminology used in the TLS
   Protocol specification [RFC5246].

   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 [RFC2119].

3.  The Wagner and Schneier attack

   Wagner and Schneier in [WS-ATTACK] describe a cross-protocol attack
   (The authors refer to it as "key exchange algorithm rollback attack")
   based on the observation that the digital signature in a Diffie-
   Hellman key exchange does not cover any identifier of the negotiated
   ciphersuite.  According to the SSL 3.0 protocol [RFC6101] when a
   Diffie-Hellman key exchange has been negotiated, the group parameters
   are sent by the server in the ServerKeyExchange message as shown
   below.

Mavrogiannopoulos       Expires December 3, 2012                [Page 3]
Internet-Draft    Preventing TLS cross-protocol attacks        June 2012

       struct {
           select (KeyExchangeAlgorithm) {
               case diffie_hellman:
                   opaque dh_p<1..2^16-1>;
                   opaque dh_g<1..2^16-1>;
                   opaque dh_Ys<1..2^16-1>;
                   Signature signed_params;
               case rsa:
                   opaque rsa_modulus<1..2^16-1>;
                   opaque rsa_exponent<1..2^16-1>;
                   Signature signed_params;
           };
       } ServerKeyExchange;

   The signature on that message is calculated on the algorithm
   parameters, and the nonces exchanged by both peers.  The crucial
   observation is that the negotiated key exchange algorithm is not part
   of this signature.

   This omission allows an adversary to re-use a signed
   ServerKeyExchange packet in another session, with another key
   exchange algorithm, by initiating a parallel connection to the
   server.  In particular, the described in [WS-ATTACK] attack deceives
   a client who advertises a TLS_RSA_EXPORT ciphersuite and expects
   temporary RSA parameters in the ServerKeyExchange message, into
   receiving Diffie-Hellman parameters from a TLS_DHE_RSA ciphersuite.

   The attack is based on a wrong assumption in the TLS packet parsing,
   which prevents it from being practical.  It demonstrates, however,
   the idea of a cross-protocol attack utilizing two of the SSL 3.0 key
   exchange methods, the Diffie-Hellman and the RSA-EXPORT key
   exchanges.

4.  The new ServerKeyExchange signature

   The goal of this memo is to restrict the applicability of the server
   provided signed ServerKeyExchange to the current session.  A simple
   fix may be to include the negotiated ciphersuite into the signature.
   However, the TLS protocol is complex and a key exchange method does
   not always imply a single format of the ServerKeyExchange signature.
   For example, the elliptic curves key exchange method may be used with
   an arbitrary elliptic curve [RFC4492] which requires different data
   in the ServerKeyExchange than when used with a named curve.  Such key
   exchange suboptions are negotiated using TLS extensions and such
   extensions should be covered by the signature, to prevent any attack
   that takes advantage of the different signature format.

   For that we propose that the signature of the ServerKeyExchange

Mavrogiannopoulos       Expires December 3, 2012                [Page 4]
Internet-Draft    Preventing TLS cross-protocol attacks        June 2012

   message to be modified to include in addition to explicit identifiers
   of the algorithms, all the previously exchanged messages.  The
   proposed signature for a ServerKeyExchange message is shown below.

     enum { server (0), client (1) } ConnectionEnd;

     enum { dhe_dss (0), dhe_rsa (1),
            ec_diffie_hellman (2)
          } KeyExchangeAlgorithm;

     struct {
       digitally-signed struct {
         ConnectionEnd entity;
         KeyExchangeAlgorithm kx_algorithm;
         select (KeyExchangeAlgorithm) {
           case dhe_dss:
           case dhe_rsa:
             ServerDHParams params;
           case ec_diffie_hellman:
             ServerECDHParams;
         }
         opaque handshake_messages<0..2^24-1>;
       }
     } ServerKeyExchange;

   The new format includes explicit indicators of the entity (server),
   the key exchange algorithm used, the handshake messages exchanged,
   and the parameters of the key exchange.  This modification will be
   negotiated by using a new TLS extension to allow backwards
   compatibility.

5.  The extension

   In order for a client to advertise its support for the new
   ServerKeyExchange format we add a new extension
   "new_server_key_exchange", with value TBD-BY-IANA, to the enumerated
   ExtensionType defined in [RFC5246].  The "extension_data" field of
   this extension is empty.

6.  Server and client behavior

   Clients, that wish to protect against cross-protocol attacks, SHOULD
   include the extension of type "new_server_key_exchange" in the
   (extended) client hello.

   Servers that receive an extended client hello containing a
   "new_server_key_exchange" extension, MAY accept the request for the
   new ServerKeyExchange format by including an extension of type

Mavrogiannopoulos       Expires December 3, 2012                [Page 5]
Internet-Draft    Preventing TLS cross-protocol attacks        June 2012

   "new_server_key_exchange" in the extended server hello.

   Servers compliant to this document, that did not receive the
   extension MUST set the gmt_unix_time part of the Random value
   included in ServerHello to zero.  Because in cross-protocol attacks
   the server's random value is redirected to the client, this is a way
   for the server to indicate support for the extension even in the
   presence of an adversary.

   Clients compliant to this document, that advertised this extension
   but didn't receive a corresponding extension from the server, MUST
   check the gmt_unix_time part of the Random value included in
   ServerHello message for the value zero.  If the gmt_unix_time is zero
   the client MUST abort the handshake with an "illegal_parameter" fatal
   alert.

   Note that this extension is applies to all versions of the TLS
   protocol including TLS 1.2 [RFC5246] and SSL 3.0 [RFC6101].

7.  Security considerations

   This extension modifies the ServerKeyExchange message in order to
   prevent attacks to the protocol similar in nature with the Wagner and
   Schneier attack.  In order for the protection to be applicable, both
   the client and the server must sbupport this extension.

   Compliant servers that did not receive the extension from the client
   are required to set the 4 bytes of the server's random value, that
   encodes the time, as zero.  This provides a tool to indicate support
   for the extended format even in the presence of an adversary, but
   comes at the cost of reducing the total randomness from the server
   from 32 bytes to 28 bytes.

8.  IANA Considerations

   This document defines the TLS extension "new_server_key_exchange"
   (value TBD-BY-IANA) whose value should be assigned from the TLS
   ExtensionType Registry defined in [RFC5246].

9.  References

9.1.  Normative References

   [WS-ATTACK]  Wagner, D. and B. Schneier, "WS-ATTACK of the SSL 3.0
                protocol", The Second USENIX Workshop on Electronic
                Commerce Proceedings, USENIX Press , November 1996.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate

Mavrogiannopoulos       Expires December 3, 2012                [Page 6]
Internet-Draft    Preventing TLS cross-protocol attacks        June 2012

                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5246]    Dierks, T. and E. Rescorla, "The Transport Layer
                Security (TLS) Protocol Version 1.2", RFC 5246,
                August 2008.

9.2.  Informative References

   [RFC6101]    Freier, A., Karlton, P., and P. Kocher, "The Secure
                Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
                August 2011.

   [RFC4492]    Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
                B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher
                Suites for Transport Layer Security (TLS)", RFC 4492,
                May 2006.

Author's Address

   Nikos Mavrogiannopoulos
   KU Leuven ESAT/SCD/COSIC - IBBT
   Kasteelpark Arenberg 10, bus 2446
   Leuven-Heverlee,   B-3001
   Belgium

   EMail: nikos.mavrogiannopoulos@esat.kuleuven.be

Mavrogiannopoulos       Expires December 3, 2012                [Page 7]