diff options
Diffstat (limited to 'doc/protocol/draft-hajjeh-tls-identity-protection-00.txt')
| -rw-r--r-- | doc/protocol/draft-hajjeh-tls-identity-protection-00.txt | 505 |
1 files changed, 0 insertions, 505 deletions
diff --git a/doc/protocol/draft-hajjeh-tls-identity-protection-00.txt b/doc/protocol/draft-hajjeh-tls-identity-protection-00.txt deleted file mode 100644 index a9b65adb2c..0000000000 --- a/doc/protocol/draft-hajjeh-tls-identity-protection-00.txt +++ /dev/null @@ -1,505 +0,0 @@ - - - -Internet Engineering Task Force I. Hajjeh - ESRGroups - M. Badra - ISIMA Laboratory - -Expires: April 2007 November, 2006 - - Identity Protection Ciphersuites for Transport Layer Security - <draft-hajjeh-tls-identity-protection-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 April 2007. - - Copyright Notice - - Copyright (C) The Internet Society (2006). All Rights Reserved. - -Abstract - - TLS defines several ciphersuites providing authentication, data - protection and session key exchange between two communicating - entities. Some of these ciphersuites are used for completely - anonymous key exchange, in which neither party is authenticated. - However, they are vulnerable to man-in-the-middle attacks and are - therefore deprecated. - - This document defines a set of ciphersuites to add client identity - protection to the Transport Layer Security (TLS) protection. - - -Hajjeh & Badra Expires April 2007 [Page 1] - -Internet-draft Identity Protection Ciphersuites for TLS November 2006 - -1. Introduction - - TLS is the most deployed security protocol for securing exchanges. - It provides end-to-end secure communications between two entities - with authentication and data protection. - - TLS supports three authentication modes: authentication of both - parties, only server-side authentication, and anonymous key - exchange. For each mode, TLS specifies a set of ciphersuites. - However, anonymous ciphersuites are strongly discouraged because - they cannot prevent man-in-the-middle attacks. - - Client identity protection may be established by changing the order - of the messages that the client sends after receiving - ServerHelloDone [CORELLA]. This is done by sending the - ChangeCipherSpec message before the Certificate and the - CertificateVerify messages and after the ClientKeyExchange message. - However, it requires a major change to TLS machine state as long as - a new TLS version. - - Client identity protection may also be done through a EDH exchange - before establishing an ordinary handshake with identity information - [RESCORLA]. This wouldn't however be secure enough against active - attackers and wouldn't be favorable for some environments (e.g. - mobile), due to the additional cryptographic computations. - - Client identity protection may be also possible, assuming that the - client permits renegotiation after the first server authentication. - However, this requires more cryptographic computations and augments - significantly the number of rounds trips. - - Finally, client identity protection may be realized by exchanging a - TLS extension that negotiates the symmetric encryption algorithm to - be used for client certificate encrypting/decrypting [EAPTLSIP]. - This solution may suffer from interoperability issues related to TLS - Extensions, TLS 1.0 and TLS 1.1 implementations, as described in - [INTEROP]. - - This document defines a set of ciphersuites to add client identity - protection to TLS protocol. Client identity protection is provided - by symmetrically encrypting the client certificate with a key - derived from the SecurityParameters.master_secret, - SecurityParameters.server_random and - SecurityParameters.client_random. The symmetric encryption algorithm - is set to the cipher algorithm of the ServerHello.cipher_suite. - -1.2. Requirements language - - The key words "MUST", "MUST NOT" and "MAY" in this document are to - be interpreted as described in RFC-2119. - - -Hajjeh & Badra Expires April 2007 [Page 2] - -Internet-draft Identity Protection Ciphersuites for TLS November 2006 - -2. TLS Identity Protection overview - - This document specifies a set of ciphersuites for TLS. These - ciphersuites reuse existing key exchange algorithms that require - based-certificates authentication, and reuse also existing MAC, - stream and bloc ciphers algorithms from [TLS] and [TLSCTR], - [TLSECC], [TLSAES] and [TLSCAM]. Their names include the text "IP" - to refer to the client identity protection. An example is shown - below. - - CipherSuite Key Exchange Cipher Hash - - TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5 RSA RC4 40 MD5 - TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA DHE AES 128_CBC SHA - - If the client has not a certificate with a type appropriate for one - of the supported cipher key exchange algorithms or if the client - will not be able to send such a certificate, it MUST NOT include any - ciphersuite with client identity protection in the - ClientHello.cipher_suites. - - If the server selects a ciphersuite with client identity protection, - the server MUST request a certificate from the client. - - If the server selects one of the ciphersuites defined in this - document, the client MUST encrypt its certificate using the - symmetric algorithm selected by the server from the list in - ClientHello.cipher_suites and a key derived from the - SecurityParameters.master_secret (see section 3 for the key - computation). - - In the case of DH_DSS and DH_RSA ciphersuites with client - authentication, the ClientKeyExchange message always contains - explicit Diffie-Hellman public value and it is possible to correlate - sessions by the same client. Consequently, DH_DSS and DH_RSA are not - currently omitted from this document. - - For EDH, the client MUST explicitly send its EDH public value in the - ClientKeyExchange message. - - - - - - - - - - - - - -Hajjeh & Badra Expires April 2007 [Page 3] - -Internet-draft Identity Protection Ciphersuites for TLS November 2006 - - Client Server - - ClientHello --------> - ServerHello - Certificate - ServerKeyExchange* - CertificateRequest - <-------- ServerHelloDone - ClientKeyExchange - {Certificate} - CertificateVerify - [ChangeCipherSpec] - Finished --------> - [ChangeCipherSpec] - <-------- Finished - Application Data <-------> Application Data - - * Indicates optional or situation-dependent messages that are not - always sent. - {} Indicates messages that are symmetrically encrypted. - - The ciphersuites in Section 4 (IP_RSA Key Exchange Algorithm) use - RSA based certificates to mutually authenticate a RSA exchange with - the client identity protection. - The ciphersuites in Section 5 (IP_EDH Key Exchange Algorithm) use - EDH_RSA or EDH_DSS to mutually authenticate a Diffie-Hellman - exchange with the client identity protection. - - The ciphersuites in Section 6 (IP_ECC Key Exchange Algorithm) are - TBC. - -3. Key computation to encrypt/decrypt client's certificate - - Before sending its certificate, the client is able to compute the - master secret and then the key_block. Thus, the client and the - server derive from the key_block a key called - identity_protection_key. This key is deployed by the client - (respectively the server) to encrypt (respectively decrypt) the - client's certificate. - - The identity_protection_key is set to the low order bits of the - key_block, and its length is set appropriately to - ServerHello.cipher_suite. For example, if the client and the server - have agreed on using a ciphersuite with RC4_128 as symmetric - cryptography, they therefore set their key to the low order 128-bits - of the key_block. - - Exportable encryption algorithms (for which CipherSpec.is_exportable - is true) require additional processing as follows to derive their - final identity_protection_key: - - -Hajjeh & Badra Expires April 2007 [Page 4] - -Internet-draft Identity Protection Ciphersuites for TLS November 2006 - - - final_identity_protection_key = - PRF(SecurityParameters.identity_protection_key, - "identity_protection_key", - SecurityParameters.client_random + - SecurityParameters.server_random); - -4. IP_RSA Key Exchange Algorithm - - This section defines additional ciphersuites that use RSA based - certificates to authenticate a RSA exchange. These ciphersuites give - client identity protection. - - CipherSuite Key Exchange Cipher Hash - - TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5 RSA RC4_40 MD5 - TLS_IP_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 - TLS_IP_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA - TLS_IP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RSA RC2_CBC_40 MD5 - TLS_IP_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA - TLS_IP_RSA_EXPORT_WITH_DES40_CBC_SHA RSA DES40_CBC_ SHA - TLS_IP_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA - TLS_IP_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE SHA - TLS_IP_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA - TLS_IP_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA - TLS_IP_RSA_WITH_AES_128_CTR_SHA RSA AES_128_CTR SHA - TLS_IP_RSA_WITH_CAMELLIA_128_CBC_SHA RSA CAMELLIA_128_CBC SHA - TLS_IP_RSA_WITH_AES_256_CTR_SHA RSA AES_256_CTR SHA - TLS_IP_RSA_WITH_CAMELLIA_256_CBC_SHA RSA CAMELLIA_256_CBC SHA - -5. IP_EDH Key Exchange Algorithm - - This section defines additional ciphersuites that use EDH with RSA - or DSS based certificates to authenticate a Diffie-Hellman exchange. - These ciphersuites give client identity protection. - - The client MUST explicitly send its EDH public value in the - ClientKeyExchange message. - - Note that this document does not specify any CipherSpec that uses DH - RSA or DSS based certificates. - - CipherSuite Key Exchange Cipher Hash - - TLS_IP_DHE_DSS_WITH_DES_CBC_SHA DHE DES_CBC SHA - TLS_IP_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE 3DES_EDE_CBC SHA - TLS_IP_DHE_RSA_WITH_DES_CBC_SHA DHE DES_CBC SHA - TLS_IP_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE 3DES_EDE_CBC SHA - TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA DHE AES_128_CBC SHA - TLS_IP_DHE_RSA_WITH_AES_128_CBC_SHA DHE AES_128_CBC SHA - - -Hajjeh & Badra Expires April 2007 [Page 5] - -Internet-draft Identity Protection Ciphersuites for TLS November 2006 - - TLS_IP_DHE_DSS_WITH_AES_256_CBC_SHA DHE AES_256_CBC SHA - TLS_IP_DHE_RSA_WITH_AES_256_CBC_SHA DHE AES_256_CBC SHA - TLS_IP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE CAMELLIA_128_CBC SHA - TLS_IP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE CAMELLIA_128_CBC SHA - TLS_IP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE CAMELLIA_256_CBC SHA - TLS_IP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE CAMELLIA_256_CBC SHA - TLS_IP_DHE_DSS_WITH_AES_128_CTR_SHA DHE AES_128_CTR SHA - TLS_IP_DHE_RSA_WITH_AES_128_CTR_SHA DHE AES_128_CTR SHA - TLS_IP_DHE_DSS_WITH_AES_256_CTR_SHA DHE AES_256_CTR SHA - TLS_IP_DHE_RSA_WITH_AES_256_CTR_SHA DHE AES_256_CTR SHA - -6. IP_ECC Key Exchange Algorithm - - TBC. - -7. Security Considerations - - The security considerations described throughout [TLS], [DTLS], - [TLS1.1], [TLSAES] and [TLSAES] apply here as well. - -8. IANA Considerations - - This section provides guidance to the IANA regarding registration of - values related to the identity protection ciphersuites. - - CipherSuite TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5 = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_RC4_128_MD5 = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_RC4_128_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_IDEA_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_DES_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_AES_128_CTR_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_AES_256_CTR_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_DSS_WITH_DES_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_RSA_WITH_DES_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_RSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_DSS_WITH_AES_256_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_RSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX }; - - -Hajjeh & Badra Expires April 2007 [Page 6] - -Internet-draft Identity Protection Ciphersuites for TLS November 2006 - - CipherSuite TLS_IP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_DSS_WITH_AES_128_CTR_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_RSA_WITH_AES_128_CTR_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_DSS_WITH_AES_256_CTR_SHA = { 0xXX,0xXX }; - CipherSuite TLS_IP_DHE_RSA_WITH_AES_256_CTR_SHA = { 0xXX,0xXX }; - - Note: For implementation and deployment facilities, it is helpful to - reserve a specific registry sub-range (minor, major) for identity - protection ciphersuites. - -References - - [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", - RFC 2246, January 1999. - - [TLS1.1] Dierks, T. and E. Rescorla, "The TLS Protocol Version - 1.1", RFC 4346, April 2005. - - [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer - Security", RFC 4347, April 2006. - - [TLSCAM] Moriai, S., Kato, A., Kanda M., "Addition of Camellia - Cipher Suites to Transport Layer Security (TLS)", - RFC 4132, July 2005. - - [TLSAES] Chown, P., "Advanced Encryption Standard (AES) - Ciphersuites for Transport Layer Security (TLS)", - RFC 3268, June 2002. - - [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., - Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher - Suites for Transport Layer Security (TLS)", RFC 4492, May - 2006 - - [TLSCTR] Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher - Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work - in progress), June 2006. - - [EAPTLSIP] Urien, P. and M. Badra, "Identity Protection within EAP- - TLS", - draft-urien-badra-eap-tls-identity-protection-01.txt - (work in progress), October 2006. - - [INTEROP] Pettersen, Y., "Clientside interoperability - experiences for the SSL and TLS protocols", draft-ietf- - tls-interoperability-00 (work in progress), October 2006. - - [CORELLA] Corella, F., "adding client identity protection to TLS", - message on ietf-tls@lists.certicom.com mailing list, - http://www.imc.org/ietf-tls/mail-archive/msg02004.html, - - -Hajjeh & Badra Expires April 2007 [Page 7] - -Internet-draft Identity Protection Ciphersuites for TLS November 2006 - - August 2000. - - [RESCORLA] Rescorla, E., "SSL and TLS: Designing and Building Secure - Systems", Addison-Wesley, March 2001. - -Author's Addresses - - Ibrahim Hajjeh - ESRGroups, Security WG - France Email: Ibrahim.Hajjeh@esrgroups.org - - Mohamad Badra - LIMOS Laboratory - UMR (6158), CNRS - France Email: badra@isima.fr - - Intellectual Property Statement - - 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 IETF's procedures with respect to rights in IETF - 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. - - Disclaimer of Validity - - 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 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. - - Copyright Statement - - -Hajjeh & Badra Expires April 2007 [Page 8] - -Internet-draft Identity Protection Ciphersuites for TLS November 2006 - - - Copyright (C) The Internet Society (2006). 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. - - Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hajjeh & Badra Expires April 2007 [Page 9]
\ No newline at end of file |