TLS Working Group T. Otto Internet-Draft April 27, 2007 Intended status: Standards Track Expires: October 29, 2007 A Privacy-enhancing TLS ciphersuite draft-otto-tls-sigma-ciphersuite-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Otto Expires October 29, 2007 [Page 1] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 Abstract This document describes a TLS ciphersuite which is based on the SIGMA protocol. By its careful adoption in the TLS handshake protocol, the proposed ciphersuite is able to inherit features of the SIGMA protocol. The ciphersuite provides active identity protection, forward secrecy, deniability and adjustable security strength. A similar ciphersuite offering these features has not yet been proposed so far. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. TLS and its handshake protocol . . . . . . . . . . . . . . 4 1.2. The SIGMA protocol . . . . . . . . . . . . . . . . . . . . 5 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 6 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Otto Expires October 29, 2007 [Page 2] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 1. Introduction This document specifies such a new ciphersuite, which encapsulates the SIGMA protocol [SIGMA] into the TLS handshake messages and therefore inherits its valueable features. Further information about SIGMA can be found on the author's website, which is http://www.ee.technion.ac.il/~hugo/sigma.html In the remainder of this document, we use the term TLS-SIGMA for our proposal. TLS-SIGMA offers Forward Secrecy: This is achieved by the authenticated Diffie-Hellman key exchange which is the cryptographic core of the SIGMA protocol. Adjustability: The cryptographic strength is determined by the choice of the Diffie-Hellman group. We call this feature adjustable security strength. Active Identity Protection: The Identity of the Client is protected against active attacks. This is achieved because the server autenticates prior to the client. Only if the client could identity the server properly, he sends his identity. Deniability: In contrast to many other ciphersuites, the conversation between client and server is deniable, in the sense, that by carrying out the TLS-SIGMA handshake, there exists no proof for the server having talked to the client, at least none which can withstand at a court, and vice versa. One might argue that there already exist numerous TLS ciphersuites with a DH key exchange, for example TLS_DHE_RSA_WITH_AES_256_CBC_SHA, and ask where the particular advantages of this ciphersuite are. The crucial point is that with RSA as key exchange mechanism and the mutual authentication case, the client computes in CertificateVerify a signature over all handshake messages (see Section 7.4.8 of [RFC2246]), that is Otto Expires October 29, 2007 [Page 3] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 CertificateVerify = SIG(Client; g^x, g^y, CertServer, CertClient) and thus provides an undeniable proof that the conversation has taken place. 1.1. TLS and its handshake protocol TLS has its origin in the SSL protocol developed by Netscape Communications in early 1990s. In the meantime, it became the major protocol to establish a cryptographially protected context between two communicating parties. One of the most valuable features of TLS is its flexibility in that initially, both sides agree on a set of cryptographic algorithms, a so-called ciphersuite. Such a ciphersuite comprises an algorithm for authentiation and key exchange, a stream or block cipher for bulk encryption and finally, an algorithm for hashing. While SSL realized this flexibility by a complicated negotiation, TLS has facilitated the procedure, in that the client sends the server all his supported ciphersuites, whereafter the server selects one of them according to his policy or aborts the protocol, if none suitable is among them. TLS is designed having addition of further ciphersuites in mind. The TLS handshake protocol's main intention is to o negotiate certain session parameters, o authenticate the server to the client, and optionally, the client to the server and o establish a shared cryptographic secret. If the handshake has finished successfully, a cryptographically protected channel is established between the two parties, which can be used to exchange securely further data. The message flow of the TLS handshake protocol is shown the following figure. Otto Expires October 29, 2007 [Page 4] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 Client Server ------ ------ (1) ClientHello --------> ServerHello (2) (Certificate) ServerKeyExchange (CertificateRequest) <-------- ServerHelloDone (3) (Certificate) ClientKeyExchange (CertificateVerify) ChangeCipherSpec Finished --------> (4) ChangeCipherSpec <-------- Finished Figure 1: TLS handshake 1.2. The SIGMA protocol SIGMA is a family of cryptographic key-exchange protocols that provide perfect forward secrecy via a Diffie-Hellman exchange authenticated with digital signatures. It has been proposed already in 1995. It has gained many popularity by building the cryptographic basis for the signature-based modes of IKE and IKEv2. The protocol has very valuable features which motivated us to incorporate it into TLS. The SIGMA specification offers two subprotocols, SIGMA-I and SIGMA-R, where I and R stand for Intiator and Responder. SIGMA-I is a three- message protocol and provides active identity protection for the initiator, while SIGMA-R consists of four messages and provides active identity protection for the responder. Obviously, only the SIGMA-I seems to be suitable to be built-in in TLS, so that we restricts on it in the following. Figure Figure 2 depicts the message flow of SIGMA-I. Otto Expires October 29, 2007 [Page 5] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 A B | g^x | |--------------------------------------------------------->| | | | g^y, ENC (Ke; B, SIG(B; g^x,g^y), MAC(Km; B) ) | |<---------------------------------------------------------| | | | ENC (Ke; A, SIG(A; g^y,g^x), MAC(Km; A) ) | |--------------------------------------------------------->| Figure 2: SIGMA-I The SIGMA specification allows to replace the peer's exponential by a nonce, but we omit this modification. The protocol derives Ke, Km and a session key Ks from the Diffie-Hellman shared key, but they have to be computationally independent. On page 20 of [SIGMA] the refinement to add some sense of direction to the MAC, i.e. we replace MAC(Km;A) MAC(Km; "0",A) and MAC(Km;B) by MAC(Km; "1",B). Finally, we replace (according to the rationale on page 21 of [SIGMA]) the pair (SIG(B; g^x,g^y), MAC(Km; B)) by SIG(B; MAC(Km; g^x,g^y,B))) and vice versa for the pair (SIG(A; g^y,g^x), MAC(Km; A)). The terminology does not deviate too much from existing work. The semantic is as follows. ENC(K;X) stands for encryption of X with key K. g^x and g^y are Diffie-Hellman keys. SIG(A;X) stands for A's signature on the content X. MAC (K;X) stands for computing a MAC over X keyed by K. Ke and Km are derived from the Diffie-Hellman shared secret g^(xy) through a PRF, while they must be cryptographically independent. 1.3. Requirements notation In this document, several words are used to signify the requirements of the specification. 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]. 1.4. Terminology This document frequently uses the following terms: Otto Expires October 29, 2007 [Page 6] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 client: One side of the connection. server: The other side of the connection. Otto Expires October 29, 2007 [Page 7] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 2. Protocol Overview This section describes how SIGMA-I is built in the TLS handshake protocol. Specifying a new ciphersuite means to re-define the semantic or content of existing handshake messages or to add extensions to the initial Hello exchange. SIGMA-I fits perfectly in the message flow, if the client takes the role of the initiator, and the server of the responder. First, the client sends in an extension of the TLS ClientHello his Diffie-Hellman public key g^x to the server, together with the DH group he desires. Possible choices are the prime groups defined in IKEv2 [RFC4306] or in [RFC3546]. Table Figure 3 summarizes the choices. +--------------------+------+-------------+ | DH group specifier | bits | defined in | +--------------------+------+-------------+ | 0x0001 | 768 | RFC 4306 | +--------------------+------+-------------+ | 0x0002 | 1024 | RFC 4306 | +--------------------+------+-------------+ | 0x0003 | 1536 | RFC 3546 | +--------------------+------+-------------+ | 0x0004 | 2048 | RFC 3546 | +--------------------+------+-------------+ | 0x0005 | 3072 | RFC 3546 | +--------------------+------+-------------+ | 0x0006 | 4096 | RFC 3546 | +--------------------+------+-------------+ Figure 3: DH groups The server then verifies whether the selected / proposed DH group is accceptable. If no, the TLS handshake fails and the server sends a corresponding message to the client. Otherwise, the server selects a private key y, computes g^y and sends this parameter in an extension of the ServerHello back. The Certificate message contains the server's certificate (which corresponds to the identity B in the SIGMA-I message flow), ServerkeyExchange contains the encrypted signature and hash according to message 2 in Figure X. Both sides are now able to compute the premaster secret. The server computes SK = (g^x)^y, the client computes SK = (g^y)^x. The master secret and keyblock are derived as specified in TLS v1.0. The client sends now in the Certificate message his certificate Otto Expires October 29, 2007 [Page 8] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 (which corresponds to the identity A in the SIGMA-I message flow), and in ClientKeyExchange the encrypted signature and MAC, according to message 3 in Figure Figure 2. The CertificateVerify message is not sent. For RSA ciphersuites, this message would contain a signature over all previously exchanged handshake messages. Applying this signature would destroy SIGMA's properties. According to the rationale above, we show the message flow for TLS- SIGMA : Client (A) Server (B) ------ ------ (1) ClientHello (g^x) --------> ServerHello (g^y) (2) Certificate (B) ServerKeyExchange ENC(Ke; SIG(B; MAC(Km; g^x,g^y,B))) <-------- ServerHelloDone (3) ClientKeyExchange ENC(Ke; SIG( A; MAC(Km; g^y,g^x,A))) ChangeCipherSpec Finished --------> (4) ChangeCipherSpec <-------- Finished Figure 4: TLS-SIGMA ciphersuite Otto Expires October 29, 2007 [Page 9] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 3. IANA Considerations -TBD- Otto Expires October 29, 2007 [Page 10] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 4. Security Considerations -TBD- Otto Expires October 29, 2007 [Page 11] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 5. Acknowledgments Add your name here. Otto Expires October 29, 2007 [Page 12] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 6.2. Informative References [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [SIGMA] Hugo Krawczyk, "SIGMA: the 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", Springer LNCS Advances in Cryptography - CRYPTO 2003 Proceedings, LNCS 2729, 2003. [TLSPSK-Perf] Mario Di Raimondo, Rosario Gennaro, Hugo Krawczyk, "Deniable Authentication and Key Exchange.", CCS 06 (Conference on Computer and Communications Security) URL: , October 2006. Otto Expires October 29, 2007 [Page 13] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 Author's Address Thomas Otto Germany Email: t.otto@tu-bs.de Otto Expires October 29, 2007 [Page 14] Internet-Draft A Privacy-enhancing TLS ciphersuite April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Otto Expires October 29, 2007 [Page 15]