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]