diff options
Diffstat (limited to 'doc/protocol/draft-hajjeh-tls-identity-protection-02.txt')
| -rw-r--r-- | doc/protocol/draft-hajjeh-tls-identity-protection-02.txt | 592 |
1 files changed, 0 insertions, 592 deletions
diff --git a/doc/protocol/draft-hajjeh-tls-identity-protection-02.txt b/doc/protocol/draft-hajjeh-tls-identity-protection-02.txt deleted file mode 100644 index e9ddc64d65..0000000000 --- a/doc/protocol/draft-hajjeh-tls-identity-protection-02.txt +++ /dev/null @@ -1,592 +0,0 @@ -Working Group Name I. Hajjeh -Internet Draft INEOVATION - M. Badra - LIMOS Laboratory -Intended status: Experimental December 13, 2007 -Expires: June 2008 - - - - Credential Protection Ciphersuites for Transport Layer Security - draft-hajjeh-tls-identity-protection-02.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 June 13, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -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. - - - -Hajjeh & Badra Expires June 2008 [Page 1] - -Internet-Draft Credential Protection Ciphersuites for TLS December 2007 - - - However, they are vulnerable to man-in-the-middle attacks and are - therefore deprecated. - - This document defines a set of ciphersuites to add client credential - protection to the Transport Layer Security (TLS) protocol. - -Table of Contents - - - 1. Introduction................................................2 - 2. TLS credential protection overview..........................3 - 3. CP_RSA Key Exchange Algorithm...............................5 - 4. CP_DHE and CP_DH Key Exchange Algorithms....................6 - 5. CP_ECDH and CP_ECDHE Key Exchange Algorithm.................6 - 6. Security Considerations.....................................7 - 7. IANA Considerations.........................................7 - 8. References..................................................9 - 8.1. Normative References...................................9 - 8.2. Informative References.................................9 - Author's Addresses............................................10 - Intellectual Property Statement...............................10 - Disclaimer of Validity........................................10 - -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 credential 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 credential protection may also be done through a DHE exchange - before establishing an ordinary handshake with identity information - [SSLTLS]. This wouldn't however be secure enough against active - attackers, which will be able to disclose the client's credentials - - - -Hajjeh & Badra Expires June 2008 [Page 2] - -Internet-Draft Credential Protection Ciphersuites for TLS December 2007 - - - and wouldn't be favorable for some environments (e.g. mobile), due to - the additional cryptographic computations. - - Client credential protection may also be possible, assuming that the - client permits renegotiation after the first server authentication - [TLS]. However, this requires more cryptographic computations and - augments significantly the number of rounds trips. In fact, - renegotiation refers back to an asymmetric encryption/decryption and - to a full previously certificate chain verified public key, whose - chain was verified properly during the first handshake and stored in - the client session context. In addition, computation overhead - increases due to all second handshake messages encryption/decryption. - Where for round trips, their number increases dramatically when small - data packets are used to convey TLS messages. Furthermore, it is - mandatory for the server to complete a first TLS handshake before it - becomes able to confirm if the client has a certificate or not. - - Client credential protection may as well be realized by exchanging a - TLS extension that negotiates the symmetric encryption algorithm to - be used for client certificate encrypting/decrypting [EAPIP]. 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 credential - protection to TLS protocol. Client credential 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.1. Conventions used in this document - - 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 RFC-2119 [RFC2119]. - -2. TLS credential 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, and - bloc ciphers algorithms from [TLS] and [TLSCTR], [TLSECC], [TLSAES] - and [TLSCAM]. Their names include the text "CP" to refer to the - client credential protection. An example is shown below. - - - -Hajjeh & Badra Expires June 2008 [Page 3] - -Internet-Draft Credential Protection Ciphersuites for TLS December 2007 - - - CipherSuite Key Exchange Cipher Hash - TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5 RSA RC4_40 MD5 - TLS_CP_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, the client MUST NOT include - any credential protection ciphersuite in the - ClientHello.cipher_suites. - - If the server selects a ciphersuite with client credential - 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 the Certificate and the - CertificateVerify messages using the symmetric algorithm selected by - the server from the list in ClientHello.cipher_suites and a key - derived from the SecurityParameters.master_secret. This key is the - same key used to encrypt data written by the client. - - If a stream cipher encryption algorithm has been selected, the client - symmetrically encrypts Certificate and CertificateVerify messages - without any padding byte. - - If a block cipher encryption algorithm has been selected, the client - uses an explicit IV and adds padding value to force the length of the - plaintext to be an integral multiple of the block cipher's block - length, as it is described in section 6.2.3.2 of [TLS]. - - For DHE key exchange algorithm, the client always sends the - ClientKeyExchange message conveying its ephemeral DH public key Yc. - - For ECDHE key exchange algorithm, the client always sends the - ClientKeyExchange message conveying its ephemeral ECDH public key Yc. - - Current TLS specifications note that if the client certificate - already contains a suitable DH or ECDH public key, then Yc is - implicit and does not need to be sent again and consequently, the - client key exchange message will be sent, but it MUST be empty. - Implementations of this document MUST send ClientKeyExchange message - but always carrying the client Yc, whatever the PublicValueEncoding - is implicit or explicit. Note that it is possible to correlate - sessions by the same client when DH or ECDH are in use. - - - - - - -Hajjeh & Badra Expires June 2008 [Page 4] - -Internet-Draft Credential Protection Ciphersuites for TLS December 2007 - - - Client Server - - ClientHello --------> - ServerHello - Certificate - ServerKeyExchange* - <-------- CertificateRequest - {Certificate} - ClientKeyExchange - {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 3 (CP_RSA Key Exchange Algorithm) use RSA - based certificates to mutually authenticate a RSA exchange with the - client credential protection. - - The ciphersuites in Section 4 (CP_DHE and CP_DH Key Exchange - Algorithm) use DHE_RSA, DH_RSA, DHE_DSS or DH_DSS to mutually - authenticate a (Ephemeral) Diffie-Hellman exchange. - - The ciphersuites in Section 5 (CP_ECDH and CP_ECDHE Key Exchange - Algorithms) use ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA or ECDHE_RSA to - mutually authenticate a (Ephemeral) EC Diffie-Hellman exchange. - -3. CP_RSA Key Exchange Algorithm - - This section defines additional ciphersuites that use RSA based - certificates to authenticate a RSA exchange. These ciphersuites give - client credential protection. - - CipherSuite Key Exchange Cipher Hash - - TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5 RSA RC4_40 MD5 - TLS_CP_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 - TLS_CP_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA - TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RSA RC2_CBC_40 MD5 - TLS_CP_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA - TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA RSA DES40_CBC SHA - - -Hajjeh & Badra Expires June 2008 [Page 5] - -Internet-Draft Credential Protection Ciphersuites for TLS December 2007 - - - TLS_CP_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA - TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE SHA - TLS_CP_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA - TLS_CP_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA - TLS_CP_RSA_WITH_AES_128_CTR_SHA RSA AES_128_CTR SHA - TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA RSA CAMELLIA_128_CBC SHA - TLS_CP_RSA_WITH_AES_256_CTR_SHA RSA AES_256_CTR SHA - TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA RSA CAMELLIA_256_CBC SHA - -4. CP_DHE and CP_DH Key Exchange Algorithms - - This section defines additional ciphersuites that use DH and DHE as - key exchange algorithms, with RSA or DSS based certificates to - authenticate a (Ephemeral) Diffie-Hellman exchange. These - ciphersuites give client credential protection. - - CipherSuite Key Exchange Cipher Hash - - TLS_CP_DHE_DSS_WITH_DES_CBC_SHA DHE DES_CBC SHA - TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE 3DES_EDE_CBC SHA - TLS_CP_DHE_RSA_WITH_DES_CBC_SHA DHE DES_CBC SHA - TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE 3DES_EDE_CBC SHA - TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA DHE AES_128_CBC SHA - TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA DHE AES_128_CBC SHA - TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA DHE AES_256_CBC SHA - TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA DHE AES_256_CBC SHA - TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE CAMELLIA_128_CBC SHA - TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE CAMELLIA_128_CBC SHA - TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE CAMELLIA_256_CBC SHA - TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE CAMELLIA_256_CBC SHA - TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA DHE AES_128_CTR SHA - TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA DHE AES_128_CTR SHA - TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA DHE AES_256_CTR SHA - TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA DHE AES_256_CTR SHA - TLS_CP_DH_DSS_WITH_DES_CBC_SHA DH DES_CBC SHA - TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA DH 3DES_EDE_CBC SHA - TLS_CP_DH_RSA_WITH_DES_CBC_SHA DH DES_CBC SHA - TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA DH 3DES_EDE_CBC SHA - TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA DH AES_128_CBC SHA - TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA DH AES_128_CBC SHA - TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA DH AES_256_CBC SHA - TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA DH AES_256_CBC SHA - -5. CP_ECDH and CP_ECDHE Key Exchange Algorithm - - This section defines additional ciphersuites that use ECDH and ECDHE - as key exchange algorithms, with RSA or ECDSA based certificates to - - -Hajjeh & Badra Expires June 2008 [Page 6] - -Internet-Draft Credential Protection Ciphersuites for TLS December 2007 - - - authenticate a (Ephemeral) ECDH exchange. These ciphersuites give - client credential protection. - - CipherSuite Key Exchange Cipher Hash - - TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA ECDH RC4_128 SHA - TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ECDH 3DES_EDE_CBC SHA - TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA ECDH AES_128_CBC SHA - TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA ECDHE AES_256_CBC SHA - TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA ECDHE RC4_128 SHA - TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ECDHE 3DES_EDE_CBC SHA - TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ECDHE AES_128_CBC SHA - TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ECDHE AES_256_CBC SHA - TLS_CP_ECDH_RSA_WITH_RC4_128_SHA ECDH RC4_128 SHA - TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA ECDH 3DES_EDE_CBC SHA - TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA ECDH AES_256_CBC SHA - TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA ECDH AES_256_CBC SHA - TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA ECDHE RC4_128 SHA - TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ECDHE 3DES_EDE_CBC SHA - TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA ECDHE AES_256_CBC SHA - TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA ECDHE AES_256_CBC SHA - -6. Security Considerations - - The security considerations described throughout [TLS], [DTLS], - [TLSAES], [TLSECC] and [TLSAES] apply here as well. - -7. IANA Considerations - - This section provides guidance to the IANA regarding registration of - values related to the credential protection ciphersuites. - - CipherSuite TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5 ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_RC4_128_MD5 ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_IDEA_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_AES_128_CTR_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_AES_256_CTR_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_DSS_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; - - -Hajjeh & Badra Expires June 2008 [Page 7] - -Internet-Draft Credential Protection Ciphersuites for TLS December 2007 - - - CipherSuite TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_RSA_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DH_DSS_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DH_RSA_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDH_RSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; - CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; - - Note: For implementation and deployment facilities, it is helpful to - reserve a specific registry sub-range (minor, major) for credential - protection ciphersuites. - - - - - - -Hajjeh & Badra Expires June 2008 [Page 8] - -Internet-Draft Credential Protection Ciphersuites for TLS December 2007 - - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [TLS] 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 - (expired), June 2006. - -8.2. Informative References - - [SSLTLS] Rescorla, E., "SSL and TLS: Designing and Building Secure - Systems", Addison-Wesley, March 2001. - - [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, - August 2000. - - [INTEROP] Pettersen, Y., "Clientside interoperability experiences for - the SSL and TLS protocols",draft-ietf-tls-interoperability- - 00 (expired), October 2006. - - [EAPIP] Urien, P. and M. Badra, "Identity Protection within EAP- - TLS", draft-urien-badra-eap-tls-identity-protection-01.txt - (expired), October 2006. - - - -Hajjeh & Badra Expires June 2008 [Page 9] - -Internet-Draft Credential Protection Ciphersuites for TLS December 2007 - - -Author's Addresses - - Ibrahim Hajjeh - INEOVATION - France - - Email: hajjeh@ineovation.com - - - Mohamad Badra - LIMOS Laboratory - UMR6158, 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 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. - -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, 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 - - -Hajjeh & Badra Expires June 2008 [Page 10] - -Internet-Draft Credential Protection Ciphersuites for TLS December 2007 - - - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -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. - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hajjeh & Badra Expires June 2008 [Page 11] - |