idnits 2.17.00 (12 Aug 2021) /tmp/idnits24102/draft-otto-tls-sigma-ciphersuite-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 431. 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 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2007) is 5502 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) == Unused Reference: 'RFC3748' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'RFC2407' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'RFC2408' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'RFC3526' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'TLSPSK-Perf' is defined on line 380, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group T. Otto 3 Internet-Draft April 27, 2007 4 Intended status: Standards Track 5 Expires: October 29, 2007 7 A Privacy-enhancing TLS ciphersuite 8 draft-otto-tls-sigma-ciphersuite-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 29, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes a TLS ciphersuite which is based on the SIGMA 42 protocol. By its careful adoption in the TLS handshake protocol, the 43 proposed ciphersuite is able to inherit features of the SIGMA 44 protocol. The ciphersuite provides active identity protection, 45 forward secrecy, deniability and adjustable security strength. A 46 similar ciphersuite offering these features has not yet been proposed 47 so far. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. TLS and its handshake protocol . . . . . . . . . . . . . . 4 53 1.2. The SIGMA protocol . . . . . . . . . . . . . . . . . . . . 5 54 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 6 55 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 56 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 61 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 62 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 Intellectual Property and Copyright Statements . . . . . . . . . . 15 66 1. Introduction 68 This document specifies such a new ciphersuite, which encapsulates 69 the SIGMA protocol [SIGMA] into the TLS handshake messages and 70 therefore inherits its valueable features. Further information about 71 SIGMA can be found on the author's website, which is 72 http://www.ee.technion.ac.il/~hugo/sigma.html 74 In the remainder of this document, we use the term TLS-SIGMA for our 75 proposal. 77 TLS-SIGMA offers 79 Forward Secrecy: 81 This is achieved by the authenticated Diffie-Hellman key exchange 82 which is the cryptographic core of the SIGMA protocol. 84 Adjustability: 86 The cryptographic strength is determined by the choice of the 87 Diffie-Hellman group. We call this feature adjustable security 88 strength. 90 Active Identity Protection: 92 The Identity of the Client is protected against active attacks. 93 This is achieved because the server autenticates prior to the 94 client. Only if the client could identity the server properly, he 95 sends his identity. 97 Deniability: 99 In contrast to many other ciphersuites, the conversation between 100 client and server is deniable, in the sense, that by carrying out 101 the TLS-SIGMA handshake, there exists no proof for the server 102 having talked to the client, at least none which can withstand at 103 a court, and vice versa. 105 One might argue that there already exist numerous TLS ciphersuites 106 with a DH key exchange, for example TLS_DHE_RSA_WITH_AES_256_CBC_SHA, 107 and ask where the particular advantages of this ciphersuite are. 109 The crucial point is that with RSA as key exchange mechanism and the 110 mutual authentication case, the client computes in CertificateVerify 111 a signature over all handshake messages (see Section 7.4.8 of 112 [RFC2246]), that is 113 CertificateVerify = SIG(Client; g^x, g^y, CertServer, CertClient) 115 and thus provides an undeniable proof that the conversation has taken 116 place. 118 1.1. TLS and its handshake protocol 120 TLS has its origin in the SSL protocol developed by Netscape 121 Communications in early 1990s. In the meantime, it became the major 122 protocol to establish a cryptographially protected context between 123 two communicating parties. 125 One of the most valuable features of TLS is its flexibility in that 126 initially, both sides agree on a set of cryptographic algorithms, a 127 so-called ciphersuite. Such a ciphersuite comprises an algorithm for 128 authentiation and key exchange, a stream or block cipher for bulk 129 encryption and finally, an algorithm for hashing. 131 While SSL realized this flexibility by a complicated negotiation, TLS 132 has facilitated the procedure, in that the client sends the server 133 all his supported ciphersuites, whereafter the server selects one of 134 them according to his policy or aborts the protocol, if none suitable 135 is among them. 137 TLS is designed having addition of further ciphersuites in mind. 139 The TLS handshake protocol's main intention is to 141 o negotiate certain session parameters, 143 o authenticate the server to the client, and optionally, the client 144 to the server and 146 o establish a shared cryptographic secret. 148 If the handshake has finished successfully, a cryptographically 149 protected channel is established between the two parties, which can 150 be used to exchange securely further data. The message flow of the 151 TLS handshake protocol is shown the following figure. 153 Client Server 154 ------ ------ 156 (1) ClientHello --------> 157 ServerHello 158 (2) (Certificate) 159 ServerKeyExchange 160 (CertificateRequest) 161 <-------- ServerHelloDone 162 (3) (Certificate) 163 ClientKeyExchange 164 (CertificateVerify) 165 ChangeCipherSpec 166 Finished --------> 167 (4) ChangeCipherSpec 168 <-------- Finished 170 Figure 1: TLS handshake 172 1.2. The SIGMA protocol 174 SIGMA is a family of cryptographic key-exchange protocols that 175 provide perfect forward secrecy via a Diffie-Hellman exchange 176 authenticated with digital signatures. It has been proposed already 177 in 1995. It has gained many popularity by building the cryptographic 178 basis for the signature-based modes of IKE and IKEv2. 180 The protocol has very valuable features which motivated us to 181 incorporate it into TLS. 183 The SIGMA specification offers two subprotocols, SIGMA-I and SIGMA-R, 184 where I and R stand for Intiator and Responder. SIGMA-I is a three- 185 message protocol and provides active identity protection for the 186 initiator, while SIGMA-R consists of four messages and provides 187 active identity protection for the responder. Obviously, only the 188 SIGMA-I seems to be suitable to be built-in in TLS, so that we 189 restricts on it in the following. 191 Figure Figure 2 depicts the message flow of SIGMA-I. 193 A B 194 | g^x | 195 |--------------------------------------------------------->| 196 | | 197 | g^y, ENC (Ke; B, SIG(B; g^x,g^y), MAC(Km; B) ) | 198 |<---------------------------------------------------------| 199 | | 200 | ENC (Ke; A, SIG(A; g^y,g^x), MAC(Km; A) ) | 201 |--------------------------------------------------------->| 203 Figure 2: SIGMA-I 205 The SIGMA specification allows to replace the peer's exponential by a 206 nonce, but we omit this modification. The protocol derives Ke, Km 207 and a session key Ks from the Diffie-Hellman shared key, but they 208 have to be computationally independent. On page 20 of [SIGMA] the 209 refinement to add some sense of direction to the MAC, i.e. we replace 210 MAC(Km;A) MAC(Km; "0",A) and MAC(Km;B) by MAC(Km; "1",B). 212 Finally, we replace (according to the rationale on page 21 of 213 [SIGMA]) the pair (SIG(B; g^x,g^y), MAC(Km; B)) by SIG(B; MAC(Km; 214 g^x,g^y,B))) and vice versa for the pair (SIG(A; g^y,g^x), MAC(Km; 215 A)). 217 The terminology does not deviate too much from existing work. The 218 semantic is as follows. ENC(K;X) stands for encryption of X with key 219 K. g^x and g^y are Diffie-Hellman keys. SIG(A;X) stands for A's 220 signature on the content X. MAC (K;X) stands for computing a MAC over 221 X keyed by K. 223 Ke and Km are derived from the Diffie-Hellman shared secret g^(xy) 224 through a PRF, while they must be cryptographically independent. 226 1.3. Requirements notation 228 In this document, several words are used to signify the requirements 229 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 230 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 231 and "OPTIONAL" in this document are to be interpreted as described in 232 [RFC2119]. 234 1.4. Terminology 236 This document frequently uses the following terms: 238 client: 240 One side of the connection. 242 server: 244 The other side of the connection. 246 2. Protocol Overview 248 This section describes how SIGMA-I is built in the TLS handshake 249 protocol. Specifying a new ciphersuite means to re-define the 250 semantic or content of existing handshake messages or to add 251 extensions to the initial Hello exchange. 253 SIGMA-I fits perfectly in the message flow, if the client takes the 254 role of the initiator, and the server of the responder. 256 First, the client sends in an extension of the TLS ClientHello his 257 Diffie-Hellman public key g^x to the server, together with the DH 258 group he desires. Possible choices are the prime groups defined in 259 IKEv2 [RFC4306] or in [RFC3546]. Table Figure 3 summarizes the 260 choices. 262 +--------------------+------+-------------+ 263 | DH group specifier | bits | defined in | 264 +--------------------+------+-------------+ 265 | 0x0001 | 768 | RFC 4306 | 266 +--------------------+------+-------------+ 267 | 0x0002 | 1024 | RFC 4306 | 268 +--------------------+------+-------------+ 269 | 0x0003 | 1536 | RFC 3546 | 270 +--------------------+------+-------------+ 271 | 0x0004 | 2048 | RFC 3546 | 272 +--------------------+------+-------------+ 273 | 0x0005 | 3072 | RFC 3546 | 274 +--------------------+------+-------------+ 275 | 0x0006 | 4096 | RFC 3546 | 276 +--------------------+------+-------------+ 278 Figure 3: DH groups 280 The server then verifies whether the selected / proposed DH group is 281 accceptable. If no, the TLS handshake fails and the server sends a 282 corresponding message to the client. Otherwise, the server selects a 283 private key y, computes g^y and sends this parameter in an extension 284 of the ServerHello back. The Certificate message contains the 285 server's certificate (which corresponds to the identity B in the 286 SIGMA-I message flow), ServerkeyExchange contains the encrypted 287 signature and hash according to message 2 in Figure X. 289 Both sides are now able to compute the premaster secret. The server 290 computes SK = (g^x)^y, the client computes SK = (g^y)^x. The master 291 secret and keyblock are derived as specified in TLS v1.0. 293 The client sends now in the Certificate message his certificate 294 (which corresponds to the identity A in the SIGMA-I message flow), 295 and in ClientKeyExchange the encrypted signature and MAC, according 296 to message 3 in Figure Figure 2. The CertificateVerify message is 297 not sent. For RSA ciphersuites, this message would contain a 298 signature over all previously exchanged handshake messages. Applying 299 this signature would destroy SIGMA's properties. 301 According to the rationale above, we show the message flow for TLS- 302 SIGMA : 304 Client (A) Server (B) 305 ------ ------ 307 (1) ClientHello (g^x) --------> 308 ServerHello (g^y) 309 (2) Certificate (B) 311 ServerKeyExchange 312 ENC(Ke; SIG(B; MAC(Km; g^x,g^y,B))) 314 <-------- ServerHelloDone 315 (3) 316 ClientKeyExchange 317 ENC(Ke; SIG( A; MAC(Km; g^y,g^x,A))) 319 ChangeCipherSpec 320 Finished --------> 321 (4) ChangeCipherSpec 322 <-------- Finished 324 Figure 4: TLS-SIGMA ciphersuite 326 3. IANA Considerations 328 -TBD- 330 4. Security Considerations 332 -TBD- 334 5. Acknowledgments 336 Add your name here. 338 6. References 340 6.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 346 Levkowetz, "Extensible Authentication Protocol (EAP)", 347 RFC 3748, June 2004. 349 6.2. Informative References 351 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 352 RFC 2246, January 1999. 354 [RFC2407] Piper, D., "The Internet IP Security Domain of 355 Interpretation for ISAKMP", RFC 2407, November 1998. 357 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 358 Security Association and Key Management Protocol 359 (ISAKMP)", RFC 2408, November 1998. 361 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 362 (IKE)", RFC 2409, November 1998. 364 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 365 Diffie-Hellman groups for Internet Key Exchange (IKE)", 366 RFC 3526, May 2003. 368 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 369 and T. Wright, "Transport Layer Security (TLS) 370 Extensions", RFC 3546, June 2003. 372 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 373 RFC 4306, December 2005. 375 [SIGMA] Hugo Krawczyk, "SIGMA: the 'SIGn-and-MAc' Approach to 376 Authenticated Diffie-Hellman and its Use in the IKE 377 Protocols", Springer LNCS Advances in Cryptography - 378 CRYPTO 2003 Proceedings, LNCS 2729, 2003. 380 [TLSPSK-Perf] 381 Mario Di Raimondo, Rosario Gennaro, Hugo Krawczyk, 382 "Deniable Authentication and Key Exchange.", CCS 06 383 (Conference on Computer and Communications Security) URL: 384 , October 2006. 386 Author's Address 388 Thomas Otto 389 Germany 391 Email: t.otto@tu-bs.de 393 Full Copyright Statement 395 Copyright (C) The IETF Trust (2007). 397 This document is subject to the rights, licenses and restrictions 398 contained in BCP 78, and except as set forth therein, the authors 399 retain all their rights. 401 This document and the information contained herein are provided on an 402 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 403 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 404 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 405 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 406 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 407 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 409 Intellectual Property 411 The IETF takes no position regarding the validity or scope of any 412 Intellectual Property Rights or other rights that might be claimed to 413 pertain to the implementation or use of the technology described in 414 this document or the extent to which any license under such rights 415 might or might not be available; nor does it represent that it has 416 made any independent effort to identify any such rights. Information 417 on the procedures with respect to rights in RFC documents can be 418 found in BCP 78 and BCP 79. 420 Copies of IPR disclosures made to the IETF Secretariat and any 421 assurances of licenses to be made available, or the result of an 422 attempt made to obtain a general license or permission for the use of 423 such proprietary rights by implementers or users of this 424 specification can be obtained from the IETF on-line IPR repository at 425 http://www.ietf.org/ipr. 427 The IETF invites any interested party to bring to its attention any 428 copyrights, patents or patent applications, or other proprietary 429 rights that may cover technology that may be required to implement 430 this standard. Please address the information to the IETF at 431 ietf-ipr@ietf.org. 433 Acknowledgment 435 Funding for the RFC Editor function is provided by the IETF 436 Administrative Support Activity (IASA).