the new makeinfo sets the FLOAT_NAME by default.
[gnutls.git] / doc / protocol / draft-hajjeh-tls-identity-protection-00.txt
bloba9b65adb2ca7a70ac6ef39b2bcdaa0e4af0c5dc5
2  
4 Internet Engineering Task Force                               I. Hajjeh 
5                                                               ESRGroups 
6                                                                M. Badra 
7                                                        ISIMA Laboratory 
8     
9 Expires: April 2007                                      November, 2006 
10     
11        Identity Protection Ciphersuites for Transport Layer Security 
12                 <draft-hajjeh-tls-identity-protection-00.txt> 
13     
14     
15 Status of this Memo 
16     
17    By submitting this Internet-Draft, each author represents that any 
18    applicable patent or other IPR claims of which he or she is aware 
19    have been or will be disclosed, and any of which he or she becomes 
20    aware will be disclosed, in accordance with Section 6 of BCP 79. 
21     
22    Internet-Drafts are working documents of the Internet Engineering 
23    Task Force (IETF), its areas, and its working groups. Note that 
24    other groups may also distribute working documents as Internet 
25    Drafts. 
26     
27    Internet-Drafts are draft documents valid for a maximum of six 
28    months and may be updated, replaced, or obsoleted by other documents 
29    at any time.  It is inappropriate to use Internet-Drafts as 
30    reference material or to cite them other than as "work in progress." 
31     
32    The list of current Internet-Drafts can be accessed at 
33    http://www.ietf.org/ietf/1id-abstracts.txt. 
34     
35    The list of Internet-Draft Shadow Directories can be accessed at 
36    http://www.ietf.org/shadow.html. 
37     
38    This Internet-Draft will expire on April 2007. 
39     
40    Copyright Notice 
41     
42    Copyright (C) The Internet Society (2006). All Rights Reserved. 
43     
44 Abstract 
45     
46    TLS defines several ciphersuites providing authentication, data 
47    protection and session key exchange between two communicating 
48    entities. Some of these ciphersuites are used for completely 
49    anonymous key exchange, in which neither party is authenticated. 
50    However, they are vulnerable to man-in-the-middle attacks and are 
51    therefore deprecated. 
52     
53    This document defines a set of ciphersuites to add client identity 
54    protection to the Transport Layer Security (TLS) protection. 
57 Hajjeh & Badra             Expires April 2007                  [Page 1] \f
59 Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
61 1. Introduction 
62     
63    TLS is the most deployed security protocol for securing exchanges. 
64    It provides end-to-end secure communications between two entities 
65    with authentication and data protection. 
66     
67    TLS supports three authentication modes: authentication of both 
68    parties, only server-side authentication, and anonymous key 
69    exchange. For each mode, TLS specifies a set of ciphersuites. 
70    However, anonymous ciphersuites are strongly discouraged because 
71    they cannot prevent man-in-the-middle attacks. 
72     
73    Client identity protection may be established by changing the order 
74    of the messages that the client sends after receiving 
75    ServerHelloDone [CORELLA]. This is done by sending the 
76    ChangeCipherSpec message before the Certificate and the 
77    CertificateVerify messages and after the ClientKeyExchange message. 
78    However, it requires a major change to TLS machine state as long as 
79    a new TLS version. 
80     
81    Client identity protection may also be done through a EDH exchange 
82    before establishing an ordinary handshake with identity information 
83    [RESCORLA]. This wouldn't however be secure enough against active 
84    attackers and wouldn't be favorable for some environments (e.g. 
85    mobile), due to the additional cryptographic computations. 
86     
87    Client identity protection may be also possible, assuming that the 
88    client permits renegotiation after the first server authentication. 
89    However, this requires more cryptographic computations and augments 
90    significantly the number of rounds trips. 
91     
92    Finally, client identity protection may be realized by exchanging a 
93    TLS extension that negotiates the symmetric encryption algorithm to 
94    be used for client certificate encrypting/decrypting [EAPTLSIP]. 
95    This solution may suffer from interoperability issues related to TLS 
96    Extensions, TLS 1.0 and TLS 1.1 implementations, as described in 
97    [INTEROP]. 
98     
99    This document defines a set of ciphersuites to add client identity 
100    protection to TLS protocol. Client identity protection is provided 
101    by symmetrically encrypting the client certificate with a key 
102    derived from the SecurityParameters.master_secret, 
103    SecurityParameters.server_random and 
104    SecurityParameters.client_random. The symmetric encryption algorithm 
105    is set to the cipher algorithm of the ServerHello.cipher_suite. 
106     
107 1.2. Requirements language 
108     
109    The key words "MUST", "MUST NOT" and "MAY" in this document are to 
110    be interpreted as described in RFC-2119. 
113 Hajjeh & Badra             Expires April 2007                  [Page 2] \f
115 Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
117 2. TLS Identity Protection overview 
118     
119    This document specifies a set of ciphersuites for TLS. These 
120    ciphersuites reuse existing key exchange algorithms that require 
121    based-certificates authentication, and reuse also existing MAC, 
122    stream and bloc ciphers algorithms from [TLS] and [TLSCTR], 
123    [TLSECC], [TLSAES] and [TLSCAM]. Their names include the text "IP" 
124    to refer to the client identity protection. An example is shown 
125    below. 
126     
127    CipherSuite                          Key Exchange  Cipher       Hash 
128     
129    TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5    RSA           RC4 40       MD5 
130    TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA  DHE           AES 128_CBC  SHA 
131     
132    If the client has not a certificate with a type appropriate for one 
133    of the supported cipher key exchange algorithms or if the client 
134    will not be able to send such a certificate, it MUST NOT include any 
135    ciphersuite with client identity protection in the 
136    ClientHello.cipher_suites. 
137     
138    If the server selects a ciphersuite with client identity protection, 
139    the server MUST request a certificate from the client. 
140     
141    If the server selects one of the ciphersuites defined in this 
142    document, the client MUST encrypt its certificate using the 
143    symmetric algorithm selected by the server from the list in 
144    ClientHello.cipher_suites and a key derived from the 
145    SecurityParameters.master_secret (see section 3 for the key 
146    computation). 
147     
148    In the case of DH_DSS and DH_RSA ciphersuites with client 
149    authentication, the ClientKeyExchange message always contains 
150    explicit Diffie-Hellman public value and it is possible to correlate 
151    sessions by the same client. Consequently, DH_DSS and DH_RSA are not 
152    currently omitted from this document. 
153     
154    For EDH, the client MUST explicitly send its EDH public value in the 
155    ClientKeyExchange message. 
169 Hajjeh & Badra             Expires April 2007                  [Page 3] \f
171 Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
173          Client                                        Server 
174     
175          ClientHello          --------> 
176                                                   ServerHello 
177                                                   Certificate 
178                                             ServerKeyExchange* 
179                                            CertificateRequest 
180                               <--------       ServerHelloDone 
181          ClientKeyExchange 
182         {Certificate} 
183          CertificateVerify 
184         [ChangeCipherSpec] 
185          Finished             --------> 
186                                             [ChangeCipherSpec] 
187                               <--------              Finished 
188          Application Data     <------->      Application Data 
189     
190    * Indicates optional or situation-dependent messages that are not 
191    always sent. 
192    {} Indicates messages that are symmetrically encrypted. 
193     
194    The ciphersuites in Section 4 (IP_RSA Key Exchange Algorithm) use 
195    RSA based certificates to mutually authenticate a RSA exchange with 
196    the client identity protection. 
197    The ciphersuites in Section 5 (IP_EDH Key Exchange Algorithm) use 
198    EDH_RSA or EDH_DSS to mutually authenticate a Diffie-Hellman 
199    exchange with the client identity protection. 
200     
201    The ciphersuites in Section 6 (IP_ECC Key Exchange Algorithm) are 
202    TBC. 
203     
204 3. Key computation to encrypt/decrypt client's certificate 
205     
206    Before sending its certificate, the client is able to compute the 
207    master secret and then the key_block. Thus, the client and the 
208    server derive from the key_block a key called 
209    identity_protection_key. This key is deployed by the client 
210    (respectively the server) to encrypt (respectively decrypt) the 
211    client's certificate. 
212     
213    The identity_protection_key is set to the low order bits of the 
214    key_block, and its length is set appropriately to 
215    ServerHello.cipher_suite. For example, if the client and the server 
216    have agreed on using a ciphersuite with RC4_128 as symmetric 
217    cryptography, they therefore set their key to the low order 128-bits 
218    of the key_block. 
219     
220    Exportable encryption algorithms (for which CipherSpec.is_exportable 
221    is true) require additional processing as follows to derive their 
222    final identity_protection_key: 
225 Hajjeh & Badra             Expires April 2007                  [Page 4] \f
227 Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
229     
230           final_identity_protection_key = 
231           PRF(SecurityParameters.identity_protection_key, 
232                                      "identity_protection_key", 
233                                      SecurityParameters.client_random + 
234                                      SecurityParameters.server_random); 
235     
236 4. IP_RSA Key Exchange Algorithm 
237     
238    This section defines additional ciphersuites that use RSA based 
239    certificates to authenticate a RSA exchange. These ciphersuites give 
240    client identity protection. 
241     
242    CipherSuite                      Key Exchange  Cipher           Hash 
243     
244    TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5     RSA      RC4_40            MD5 
245    TLS_IP_RSA_WITH_RC4_128_MD5           RSA      RC4_128           MD5 
246    TLS_IP_RSA_WITH_RC4_128_SHA           RSA      RC4_128           SHA 
247    TLS_IP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RSA      RC2_CBC_40        MD5 
248    TLS_IP_RSA_WITH_IDEA_CBC_SHA          RSA      IDEA_CBC          SHA 
249    TLS_IP_RSA_EXPORT_WITH_DES40_CBC_SHA  RSA      DES40_CBC_        SHA 
250    TLS_IP_RSA_WITH_DES_CBC_SHA           RSA      DES_CBC           SHA 
251    TLS_IP_RSA_WITH_3DES_EDE_CBC_SHA      RSA      3DES_EDE          SHA 
252    TLS_IP_RSA_WITH_AES_128_CBC_SHA       RSA      AES_128_CBC       SHA 
253    TLS_IP_RSA_WITH_AES_256_CBC_SHA       RSA      AES_256_CBC       SHA 
254    TLS_IP_RSA_WITH_AES_128_CTR_SHA       RSA      AES_128_CTR       SHA 
255    TLS_IP_RSA_WITH_CAMELLIA_128_CBC_SHA  RSA      CAMELLIA_128_CBC  SHA 
256    TLS_IP_RSA_WITH_AES_256_CTR_SHA       RSA      AES_256_CTR       SHA 
257    TLS_IP_RSA_WITH_CAMELLIA_256_CBC_SHA  RSA      CAMELLIA_256_CBC  SHA 
258     
259 5. IP_EDH Key Exchange Algorithm 
260     
261    This section defines additional ciphersuites that use EDH with RSA 
262    or DSS based certificates to authenticate a Diffie-Hellman exchange. 
263    These ciphersuites give client identity protection. 
264     
265    The client MUST explicitly send its EDH public value in the 
266    ClientKeyExchange message. 
267     
268    Note that this document does not specify any CipherSpec that uses DH 
269    RSA or DSS based certificates. 
270     
271    CipherSuite                      Key Exchange  Cipher           Hash 
272     
273    TLS_IP_DHE_DSS_WITH_DES_CBC_SHA          DHE   DES_CBC           SHA 
274    TLS_IP_DHE_DSS_WITH_3DES_EDE_CBC_SHA     DHE   3DES_EDE_CBC      SHA 
275    TLS_IP_DHE_RSA_WITH_DES_CBC_SHA          DHE   DES_CBC           SHA 
276    TLS_IP_DHE_RSA_WITH_3DES_EDE_CBC_SHA     DHE   3DES_EDE_CBC      SHA 
277    TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA      DHE   AES_128_CBC       SHA 
278    TLS_IP_DHE_RSA_WITH_AES_128_CBC_SHA      DHE   AES_128_CBC       SHA 
281 Hajjeh & Badra             Expires April 2007                  [Page 5] \f
283 Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
285    TLS_IP_DHE_DSS_WITH_AES_256_CBC_SHA      DHE   AES_256_CBC       SHA 
286    TLS_IP_DHE_RSA_WITH_AES_256_CBC_SHA      DHE   AES_256_CBC       SHA 
287    TLS_IP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE   CAMELLIA_128_CBC  SHA 
288    TLS_IP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE   CAMELLIA_128_CBC  SHA 
289    TLS_IP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE   CAMELLIA_256_CBC  SHA 
290    TLS_IP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE   CAMELLIA_256_CBC  SHA 
291    TLS_IP_DHE_DSS_WITH_AES_128_CTR_SHA      DHE   AES_128_CTR       SHA 
292    TLS_IP_DHE_RSA_WITH_AES_128_CTR_SHA      DHE   AES_128_CTR       SHA 
293    TLS_IP_DHE_DSS_WITH_AES_256_CTR_SHA      DHE   AES_256_CTR       SHA 
294    TLS_IP_DHE_RSA_WITH_AES_256_CTR_SHA      DHE   AES_256_CTR       SHA 
295     
296 6. IP_ECC Key Exchange Algorithm 
297     
298    TBC. 
300 7. Security Considerations 
301     
302    The security considerations described throughout [TLS], [DTLS], 
303    [TLS1.1], [TLSAES] and [TLSAES] apply here as well. 
304     
305 8. IANA Considerations 
306     
307    This section provides guidance to the IANA regarding registration of 
308    values related to the identity protection ciphersuites. 
309     
310    CipherSuite TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5       = { 0xXX,0xXX }; 
311    CipherSuite TLS_IP_RSA_WITH_RC4_128_MD5             = { 0xXX,0xXX }; 
312    CipherSuite TLS_IP_RSA_WITH_RC4_128_SHA             = { 0xXX,0xXX }; 
313    CipherSuite TLS_IP_RSA_EXPORT_WITH_RC2_CBC_40_MD5   = { 0xXX,0xXX }; 
314    CipherSuite TLS_IP_RSA_WITH_IDEA_CBC_SHA            = { 0xXX,0xXX }; 
315    CipherSuite TLS_IP_RSA_EXPORT_WITH_DES40_CBC_SHA    = { 0xXX,0xXX }; 
316    CipherSuite TLS_IP_RSA_WITH_DES_CBC_SHA             = { 0xXX,0xXX }; 
317    CipherSuite TLS_IP_RSA_WITH_3DES_EDE_CBC_SHA        = { 0xXX,0xXX }; 
318    CipherSuite TLS_IP_RSA_WITH_AES_128_CBC_SHA         = { 0xXX,0xXX }; 
319    CipherSuite TLS_IP_RSA_WITH_AES_256_CBC_SHA         = { 0xXX,0xXX }; 
320    CipherSuite TLS_IP_RSA_WITH_AES_128_CTR_SHA         = { 0xXX,0xXX }; 
321    CipherSuite TLS_IP_RSA_WITH_CAMELLIA_128_CBC_SHA    = { 0xXX,0xXX }; 
322    CipherSuite TLS_IP_RSA_WITH_AES_256_CTR_SHA         = { 0xXX,0xXX }; 
323    CipherSuite TLS_IP_RSA_WITH_CAMELLIA_256_CBC_SHA    = { 0xXX,0xXX }; 
324    CipherSuite TLS_IP_DHE_DSS_WITH_DES_CBC_SHA         = { 0xXX,0xXX }; 
325    CipherSuite TLS_IP_DHE_DSS_WITH_3DES_EDE_CBC_SHA    = { 0xXX,0xXX }; 
326    CipherSuite TLS_IP_DHE_RSA_WITH_DES_CBC_SHA         = { 0xXX,0xXX }; 
327    CipherSuite TLS_IP_DHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0xXX,0xXX }; 
328    CipherSuite TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA     = { 0xXX,0xXX }; 
329    CipherSuite TLS_IP_DHE_RSA_WITH_AES_128_CBC_SHA     = { 0xXX,0xXX }; 
330    CipherSuite TLS_IP_DHE_DSS_WITH_AES_256_CBC_SHA     = { 0xXX,0xXX }; 
331    CipherSuite TLS_IP_DHE_RSA_WITH_AES_256_CBC_SHA     = { 0xXX,0xXX }; 
332    CipherSuite TLS_IP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX }; 
333    CipherSuite TLS_IP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX }; 
334    CipherSuite TLS_IP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX }; 
337 Hajjeh & Badra             Expires April 2007                  [Page 6] \f
339 Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
341    CipherSuite TLS_IP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX }; 
342    CipherSuite TLS_IP_DHE_DSS_WITH_AES_128_CTR_SHA     = { 0xXX,0xXX }; 
343    CipherSuite TLS_IP_DHE_RSA_WITH_AES_128_CTR_SHA     = { 0xXX,0xXX }; 
344    CipherSuite TLS_IP_DHE_DSS_WITH_AES_256_CTR_SHA     = { 0xXX,0xXX }; 
345    CipherSuite TLS_IP_DHE_RSA_WITH_AES_256_CTR_SHA     = { 0xXX,0xXX }; 
346     
347    Note: For implementation and deployment facilities, it is helpful to 
348    reserve a specific registry sub-range (minor, major) for identity 
349    protection ciphersuites. 
350     
351 References 
352     
353    [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",  
354               RFC 2246, January 1999. 
355     
356    [TLS1.1]   Dierks, T. and E. Rescorla, "The TLS Protocol Version  
357               1.1", RFC 4346, April 2005. 
358     
359    [DTLS]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer  
360               Security", RFC 4347, April 2006. 
361     
362    [TLSCAM]   Moriai, S., Kato, A., Kanda M., "Addition of Camellia  
363               Cipher Suites to Transport Layer Security (TLS)",  
364               RFC 4132, July 2005. 
365     
366    [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)  
367               Ciphersuites for Transport Layer Security (TLS)",  
368               RFC 3268, June 2002. 
369     
370    [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,  
371               Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher  
372               Suites for Transport Layer Security (TLS)", RFC 4492, May  
373               2006 
374     
375    [TLSCTR]   Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher  
376               Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work  
377               in progress), June 2006. 
378     
379    [EAPTLSIP] Urien, P. and M. Badra, "Identity Protection within EAP- 
380               TLS",  
381               draft-urien-badra-eap-tls-identity-protection-01.txt  
382               (work in progress), October 2006. 
383     
384    [INTEROP]  Pettersen, Y., "Clientside interoperability  
385               experiences for the SSL and TLS protocols", draft-ietf- 
386               tls-interoperability-00 (work in progress), October 2006. 
387     
388    [CORELLA]  Corella, F., "adding client identity protection to TLS",  
389               message on ietf-tls@lists.certicom.com mailing list,  
390               http://www.imc.org/ietf-tls/mail-archive/msg02004.html,  
393 Hajjeh & Badra             Expires April 2007                  [Page 7] \f
395 Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
397               August 2000. 
398     
399    [RESCORLA] Rescorla, E., "SSL and TLS: Designing and Building Secure  
400               Systems", Addison-Wesley, March 2001. 
401     
402 Author's Addresses 
403     
404    Ibrahim Hajjeh 
405    ESRGroups, Security WG 
406    France                    Email: Ibrahim.Hajjeh@esrgroups.org 
407     
408    Mohamad Badra 
409    LIMOS Laboratory - UMR (6158), CNRS 
410    France                    Email: badra@isima.fr 
411     
412    Intellectual Property Statement 
413     
414    The IETF takes no position regarding the validity or scope of any 
415    Intellectual Property Rights or other rights that might be claimed 
416    to pertain to the implementation or use of the technology described 
417    in this document or the extent to which any license under such 
418    rights might or might not be available; nor does it represent that 
419    it has made any independent effort to identify any such rights. 
420    Information on the IETF's procedures with respect to rights in IETF 
421    Documents can be found in BCP 78 and BCP 79. 
422     
423    Copies of IPR disclosures made to the IETF Secretariat and any 
424    assurances of licenses to be made available, or the result of an 
425    attempt made to obtain a general license or permission for the use 
426    of such proprietary rights by implementers or users of this 
427    specification can be obtained from the IETF on-line IPR repository 
428    at http://www.ietf.org/ipr. 
429     
430    The IETF invites any interested party to bring to its attention any 
431    copyrights, patents or patent applications, or other proprietary 
432    rights that may cover technology that may be required to implement 
433    this standard. Please address the information to the IETF at ietf-
434    ipr@ietf.org. 
435     
436    Disclaimer of Validity 
437     
438    This document and the information contained herein are provided on 
439    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
440    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
441    INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
442    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
443    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
444    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
445     
446    Copyright Statement 
449 Hajjeh & Badra             Expires April 2007                  [Page 8] \f
451 Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
453     
454    Copyright (C) The Internet Society (2006). This document is subject 
455    to the rights, licenses and restrictions contained in BCP 78, and 
456    except as set forth therein, the authors retain all their rights. 
457     
458    Acknowledgment 
459     
460    Funding for the RFC Editor function is currently provided by the 
461    Internet Society. 
505 Hajjeh & Badra             Expires April 2007                  [Page 9] \f