From 37ceaa4697db3397be0191524e89427e42f023f5 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Mon, 11 Jun 2007 10:38:47 +0200 Subject: Add. --- doc/protocol/draft-badra-ecdhe-tls-psk-00.txt | 281 +++++++++++ .../draft-hajjeh-tls-identity-protection-01.txt | 506 +++++++++++++++++++ doc/protocol/draft-hajjeh-tls-sign-03.txt | 561 +++++++++++++++++++++ 3 files changed, 1348 insertions(+) create mode 100644 doc/protocol/draft-badra-ecdhe-tls-psk-00.txt create mode 100644 doc/protocol/draft-hajjeh-tls-identity-protection-01.txt create mode 100644 doc/protocol/draft-hajjeh-tls-sign-03.txt (limited to 'doc') diff --git a/doc/protocol/draft-badra-ecdhe-tls-psk-00.txt b/doc/protocol/draft-badra-ecdhe-tls-psk-00.txt new file mode 100644 index 0000000000..23d12cec3c --- /dev/null +++ b/doc/protocol/draft-badra-ecdhe-tls-psk-00.txt @@ -0,0 +1,281 @@ + + + +Internet Engineering Task Force M. Badra +INTERNET DRAFT LIMOS Laboratory +Updates: 4785, 4279 + +Expires: November 2007 July 2007 + + ECDHE_PSK Ciphersuites for TLS + + + +Status + + 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 November 2007. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document updates RFC 4785 and RFC 4279 and specifies a set of + ciphersuites that use an Elliptic Curve Diffie-Hellman exchange + authenticated with a pre-shared key. These ciphersuites provides + Perfect Forward Secrecy. It specifies as well one authentication- + only ciphersuites (with no encryption). This ciphersuite is useful + when authentication and integrity protection is desired, but + confidentiality is not needed or not permitted. + + The reader is expected to become familiar with RFC 4785 and RFC 4279 + prior to studying this document. + + +Badra Expires November 2007 [Page 1] + +Internet-Draft ECDHE_PSK Ciphersuites for TLS July 2007 + + +1. Introduction + + RFC 4279 specifies ciphersuites for supporting TLS using pre-shared + symmetric keys and they (a) use only symmetric key operations for + authentication, (b) use a Diffie-Hellman exchange authenticated + with a pre-shared key, or (c) combines public key authentication of + the server with pre-shared key authentication of the client. + + RFC 4785 specifies authentication-only ciphersuites (with no + encryption). + + This document specifies a set of ciphersuites that use an Elliptic + Curve Diffie-Hellman exchange authenticated with a pre-shared key. + These ciphersuites provides Perfect Forward Secrecy. It specifies as + well one authentication-only ciphersuites (with no encryption). This + ciphersuite is useful when authentication and integrity protection + is desired, but confidentiality is not needed or not permitted. + +2. Updating RFC4279 + + The new ciphersuites proposed here match the ciphersuites defined in + [RFC4279], except that they use an Elliptic Curve Diffie-Hellman + exchange [RFC4492] authenticated with a pre-shared key. They are + defined as follow: + + CipherSuite Key Exchange Cipher Hash + + TLS_ECDHE_PSK_WITH_RC4_128_SHA ECDHE_PSK RC4_128 SHA + TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA ECDHE_PSK 3DES_EDE_CBC SHA + TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA ECDHE_PSK AES_128_CBC SHA + TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA ECDHE_PSK AES_256_CBC SHA + + When these ciphersuites are used, the ServerKeyExchange and + ClientKeyExchange messages also include the Diffie-Hellman + parameters. The PSK identity and identity hint fields have the same + meaning as in the previous section (note that the ServerKeyExchange + message is always sent, even if no PSK identity hint is provided). + + The format of the ServerKeyExchange and ClientKeyExchange messages + is shown below. + + struct { + select (KeyExchangeAlgorithm) { + /* other cases for rsa, diffie_hellman, etc. */ + case ec_diffie_hellman_psk: /* NEW */ + opaque psk_identity_hint<0..2^16-1>; + ServerECDHParams params; + }; + } ServerKeyExchange; + + +Badra Expires November 2007 [Page 2] + +Internet-Draft ECDHE_PSK Ciphersuites for TLS July 2007 + + + struct { + select (KeyExchangeAlgorithm) { + /* other cases for rsa, diffie_hellman, etc. */ + case ec_diffie_hellman_psk: /* NEW */ + opaque psk_identity<0..2^16-1>; + ClientECDiffieHellmanPublic public; + } exchange_keys; + } ClientKeyExchange; + + The premaster secret is formed as follows. First, perform the + Elliptic Curve Diffie-Hellman computation in the same way as for + other Diffie-Hellman-based ciphersuites in [TLS1.0] or [TLS1.1]. Let + Z be the value produced by this computation. Concatenate a uint16 + containing the length of Z (in octets), Z itself, a uint16 + containing the length of the PSK (in octets), and the PSK itself. + + This corresponds to the general structure for the premaster secrets + (see Note 1 in Section 2 in RFC 4279) in [RFC4279], with + "other_secret" containing Z: + + struct { + opaque other_secret<0..2^16-1>; + opaque psk<0..2^16-1>; + }; + + Here "other_secret" comes from the Elliptic Curve Diffie-Hellman + exchange (ECDHE_PSK). + +3. Updating RFC4785 + + The new ciphersuite proposed here match the ciphersuites defined in + [RFC4785], except that it uses an Elliptic Curve Diffie-Hellman + exchange authenticated with a pre-shared key + + CipherSuite Key Exchange Cipher Hash + + TLS_ECDHE_PSK_WITH_NULL_SHA ECDHE_PSK NULL SHA + +4. Security Considerations + + The security considerations described throughout [TLS1.0], + [TLSv1.1], RFC 4785 and RFC 4279 apply here as well. + +5. IANA Considerations + + This document defines the following new ciphersuites, whose values + are to be assigned from the TLS Cipher Suite registry defined in + [TLS1.1]. + + CipherSuite TLS_ECDHE_PSK_WITH_RC4_128_SHA = { 0xXX, 0xXX }; + +Badra Expires November 2007 [Page 3] + +Internet-Draft ECDHE_PSK Ciphersuites for TLS July 2007 + + + CipherSuite TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0xXX, 0xXX }; + CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA = { 0xXX, 0xXX }; + CipherSuite TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA = { 0xXX, 0xXX }; + CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA = { 0xXX, 0xXX }; + +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. + + [TLS1.0] T., Dierks, C., Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [TLS1.1] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", + RFC 4346, April 200P. + + [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites + for Transport Layer Security (TLS)", RFC 4279, December + 2005. + + [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK) + Ciphersuites with NULL Encryption for Transport Layer + Security (TLS)", RFC 4785, January 2007. + + [RFC4492] 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. + +Acknowledgements + + The authors would like to thank Bodo Moeller for comments on the + document. + +Author's Addresses + + Mohamad Badra + LIMOS Laboratory - UMR (6158), CNRS + France Email: badra@isima.fr + + 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. + +Badra Expires November 2007 [Page 4] + +Internet-Draft ECDHE_PSK Ciphersuites for TLS July 2007 + + + + 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. + + Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + + + + + + + +Badra Expires November 2007 [Page 5] \ No newline at end of file diff --git a/doc/protocol/draft-hajjeh-tls-identity-protection-01.txt b/doc/protocol/draft-hajjeh-tls-identity-protection-01.txt new file mode 100644 index 0000000000..b16c81fb9a --- /dev/null +++ b/doc/protocol/draft-hajjeh-tls-identity-protection-01.txt @@ -0,0 +1,506 @@ + + + +Internet Engineering Task Force I. Hajjeh + ESRGroups + M. Badra + LIMOS Laboratory + +Expires: November 2007 June, 2007 + + Credential Protection Ciphersuites for Transport Layer Security + + + +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 November 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. + 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. + + +Hajjeh & Badra Expires November 2007 [Page 1] + +Internet-draft Credential protection Ciphersuites for TLS June 2007 + +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 + [RESCORLA]. This wouldn't however be secure enough against active + attackers, which will be able to disclose the client's credentials + and wouldn't be favorable for some environments (e.g. mobile), due + to the additional cryptographic computations. + + Client credential 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. + + 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 [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 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.2. Requirements language + + + + +Hajjeh & Badra Expires November 2007 [Page 2] + +Internet-draft Credential protection Ciphersuites for TLS June 2007 + + The key words "MUST", "MUST NOT" and "MAY" in this document are to + be interpreted as described in RFC-2119. + +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, + stream 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. + + 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, it MUST NOT include any + ciphersuite with client credential protection 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 [TLS1.1]. + + 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. + + + +Hajjeh & Badra Expires November 2007 [Page 3] + +Internet-draft Credential protection Ciphersuites for TLS June 2007 + + 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. + + Client Server + + ClientHello --------> + ServerHello + Certificate + ServerKeyExchange* + CertificateRequest + <-------- ServerHelloDone + {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 + + + +Hajjeh & Badra Expires November 2007 [Page 4] + +Internet-draft Credential protection Ciphersuites for TLS June 2007 + + 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 + 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 + + + + +Hajjeh & Badra Expires November 2007 [Page 5] + +Internet-draft Credential protection Ciphersuites for TLS June 2007 + +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 + 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], + [TLS1.1], [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 }; + + +Hajjeh & Badra Expires November 2007 [Page 6] + +Internet-draft Credential protection Ciphersuites for TLS June 2007 + + CipherSuite TLS_CP_DHE_DSS_WITH_DES_CBC_SHA = { 0xXX,0xXX }; + 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. + +8. References + +8.1. Normative References + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + + +Hajjeh & Badra Expires November 2007 [Page 7] + +Internet-draft Credential protection Ciphersuites for TLS June 2007 + + 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 + +8.1. Informative References + + [RESCORLA] 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 (work in progress), October 2006. + 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. + +Author's Addresses + + Ibrahim Hajjeh + ESRGroups, Security WG + France Email: Ibrahim.Hajjeh@esrgroups.org + + + +Hajjeh & Badra Expires November 2007 [Page 8] + +Internet-draft Credential protection Ciphersuites for TLS June 2007 + + Mohamad Badra + LIMOS Laboratory - UMR (6158), CNRS + France Email: badra@isima.fr + + 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. + + Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + +Hajjeh & Badra Expires November 2007 [Page 9] \ No newline at end of file diff --git a/doc/protocol/draft-hajjeh-tls-sign-03.txt b/doc/protocol/draft-hajjeh-tls-sign-03.txt new file mode 100644 index 0000000000..c0a9b1cb76 --- /dev/null +++ b/doc/protocol/draft-hajjeh-tls-sign-03.txt @@ -0,0 +1,561 @@ + + + +Internet Engineering Task Force I. Hajjeh +INTERNET DRAFT ESRGroups + M. Badra + LIMOS Laboratory + +Expires: November 2007 June 2007 + + TLS Sign + + + +Status + + 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 November 2007. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + TLS protocol provides authentication and data protection for + communication between two entities. However, missing from the + protocol is a way to perform non-repudiation service. + + This document defines extensions to the TLS protocol to allow it to + perform non-repudiation service. It is based on [TLSSign] and it + provides the client and the server the ability to sign by TLS, + handshake and applications data using certificates such as X.509. + + + +Hajjeh & Badra Expires November 2007 [Page 1] +INTERNET-DRAFT TLS Sign June 2007 + +1 Introduction + + Actually, 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. However, what is + missing from the protocol is a way to provide the non-repudiation + service. + + This document describes how the non-repudiation service may be + integrated as an optional module in TLS. This is in order to provide + both parties with evidence that the transaction has taken place and + to offer a clear separation with application design and development. + + TLS-Sign's design motivations included: + + o TLS is application protocol-independent. Higher-level protocol + can operate on top of the TLS protocol transparently. + + o TLS is a modular nature protocol. Since TLS is developed in four + independent protocols, the approach defined in this document can + be added by extending the TLS protocol and with a total + reuse of pre-existing TLS infrastructures and implementations. + + o Several applications like E-Business require non-repudiation + proof of transactions. It is critical in these applications to + have the non-repudiation service that generates, distributes, + validates and maintains the evidence of an electronic + transaction. Since TLS is widely used to secure these + applications exchanges, the non-repudiation should be offered by + TLS. + + o Generic non-repudiation with TLS. TLS Sign provides a generic + non-repudiation service that can be easily used with protocols. + TLS Sign minimizes both design and implementation of the + signature service and that of the designers and implementators + who wish to use this module. + +1.2 Requirements language + + The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document + are to be interpreted as described in RFC-2119. + +2 TLS Sign overview + + TLS Sign is integrated as a higher-level module of the TLS Record + protocol. It is optionally used if the two entities agree. This is + negotiated by extending Client and Server Hello messages in the same + way defined in [TLSExt]. + + In order to allow a TLS client to negotiate the TLS Sign, a new + extension type should be added to the Extended Client and Server + + +Hajjeh & Badra Expires November 2007 [Page 2] +INTERNET-DRAFT TLS Sign June 2007 + + Hellos messages. TLS clients and servers MAY include an extension of + type 'signature' in the Extended Client and Server Hellos messages. + The 'extension_data' field of this extension contains a + 'signature_request' where: + + enum { + pkcs7(0), smime(1), xmldsig(2), (255); + } ContentFormat; + + struct { + ContentFormat content_format; + SignMethod sign_meth; + SignType sign_type<2..2^16-1>; + } SignatureRequest; + + enum { + ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255); + } SignMethod; + + uint8 SignType[2]; + + The client initiates the TLS Sign module by sending the + ExtendedClientHello including the 'signature' extension. This + extension contains: + + - the SignType carrying the type of the non repudiation proof. It + can have one of these two values: + + SignType non_repudiation_with_proof_of_origin = { 0x00, 0x01 }; + SignType non_repudiation_without_proof_of_origin = { 0x00, 0x02 }; + + - the ContentFormat carrying the format of signed data. It can be + PKCS7 [PKCS7], S/MIME [S/MIME] or XMLDSIG [XMLDSIG] + + ContentFormat PKCS7 = { 0x00, 0xA1 }; + ContentFormat SMIME = { 0x00, 0xA2 }; + ContentFormat XMLDSIG = { 0x00, 0xA3 }; + + o if the value of the ContentFormat is PKCS7, then the PKCS7 + Content_type is of type signed-data. + + o if the value of the ContentFormat is S/MIME, then S/MIME + Content_type is of type SignedData + + o if the value of the ContentFormat is XMLDSIG, then XMLDSIG + signatureMethod algorithms. + + - the SignMethod carrying the signature method that is used to sign + the application data (e.g. X509 authentication certificate). + + SignMethod X509 = { 0x00, 0xB1 }; + + +Hajjeh & Badra Expires November 2007 [Page 3] +INTERNET-DRAFT TLS Sign June 2007 + + + Actually, this document uses the same certificate used in client + authentication. Any new signature method MAY be added in future + versions (e.g. delegated attributes certificates). + + The server MAY reject the connection by sending the error alert + "unsupported_extension" [TLSExt] and closing the connection. + + The client and the server MAY or MAY NOT use the same certificates + used by the Handshake protocol. Several cases are possible: + + - If the server has an interest in getting non-repudiation data from + the client and that the cipher_suites list sent by the client does + not include any cipher_suite with signature ability, the server MUST + (upon reception of tls_sign_on_off protocol message not followed by + a certificate with a type equals to ExtendedServerHello.sign_method) + close the connection by sending a fatal error. + + - If the server has an interest in getting non-repudiation data from + the client and that the cipher_suites list sent by the client + includes at least a cipher_suite with signature ability, the server + SHOULD select a cipher_suite with signature ability and MUST provide + a certificate (e.g., RSA) that MAY be used for key exchange. + Further, the server MUST request a certificate from the client using + the TLS certificate request message (e.g., an RSA or a DSS + signature-capable certificate). If the client does not send a + certificate during the TLS Handshake, the server MUST close the TLS + session by sending a fatal error in the case where the client sends + a tls_sign_on_off protocol message not followed by a certificate + with a type equals to ExtendedServerHello.sign_method. + + - The client or the server MAY use a certificate different to these + being used by TLS Handshake. This MAY happen when the server agrees + in getting non-repudiation data from the client and that the type of + the client certificate used by TLS Handshake and the type selected + by the server from the list in ExtendedClientHello.sign_method are + different, or when the ExtendedServerHello.cipher_suite does not + require client and/or server certificates. In these cases, the + client or the server sends a new message called certificate_sign, + right after sending the tls_sign_on_off protocol messages. The new + message contains the sender's certificate in which the type is the + same type selected by the server from the list in + ExtendedClientHello.sign_method. The certificate_sign is therefore + used to generate signed data. It is defined as follows: + + opaque ASN.1Cert<2^24-1>; + + struct { + ASN.1Cert certificate_list<1..2^24-1>; + } CertificateSign; + + + +Hajjeh & Badra Expires November 2007 [Page 4] +INTERNET-DRAFT TLS Sign June 2007 + + The certificate_list, as defined in [TLS], is a sequence (chain) of + certificates. The sender's certificate MUST come first in the list. + + If the server has no interest in getting non-repudiation data from + the client, it replays with an ordinary TLS ServerHello or return a + handshake failure alert and close the connection [TLS]. + + Client Server + ------ ------ + + ClientHello --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + + TLSSignOnOff <--------------------------> TLSSignOnOff + + CertificateSign* <-----------------------> CertificateSign* + + (Signed) Application Data <----> (Signed) Application Data + + * Indicates optional or situation-dependent messages that are not + always sent. + +2.1 tls sign on off protocol + + To manage the generation of evidence, new sub-protocol is added by + this document, called tls_sign_on_off. This protocol consists of a + single message that is encrypted and compressed under the + established connection state. This message can be sent at any time + after the TLS session has been established. Thus, no man in the + middle can replay or inject this message. It consists of a single + byte of value 1 (tls_sign_on) or 0 (tls_sign_off). + + enum { + change_cipher_spec(20), alert(21), handshake(22), + application_data(23), tls_sign(TBC), (255) + } ContentType; + + struct { + enum { tls_sign_off(0), tls_sign_on(1), (255) } type; + } TLSSignOnOff; + + +Hajjeh & Badra Expires November 2007 [Page 5] +INTERNET-DRAFT TLS Sign June 2007 + + + The tls_sign_on_off message is sent by the client and/or server to + notify the receiving party that subsequent records will carry data + signed under the negotiated parameters. + + Note: TLSSignOnOff is an independent TLS Protocol content type, and + is not actually a TLS handshake message. + + 2.1.1 TLS sign packet format + + This document defines a new packet format that encapsulates signed + data, the TLSSigntext. The packet format is shown below. The fields + are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Content-Type | Flag | Version | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Signed Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Content-Type + + Same as TLSPlaintext.type. + + Flag + + 0 1 2 3 4 5 6 7 8 + +-+-+-+-+-+-+-+-+ + |A R R R R R R R| + +-+-+-+-+-+-+-+-+ + + A = acknowledgement of receipt + R = Reserved + + When the whole signed data is delivered to the receiver, the TLS + Sign will check the signature. If the signature is valid and that + the sender requires a proof of receipt, the receiver MUST generate a + TLSSigntext packet with the bit A set to 1 (acknowledgement of + receipt). This helps the receiver of the acknowledgment of receipt + in storing the data-field for later use (see section 2.2). The data- + field of that message contains the digest of the whole data receiver + by the generator of the acknowledgement of receipt. The digest is + signed before sending the result to the other side. + + 2.1.3 bad_sign alert + + This alert is returned if a record is received with an incorrect + signature. This message is always fatal. + + + +Hajjeh & Badra Expires November 2007 [Page 6] +INTERNET-DRAFT TLS Sign June 2007 + +2.2 Storing signed data + + The objective of TLS Sign is to provide both parties with evidence + that can be stored and later presented to a third party to resolve + disputes that arise if and when a communication is repudiated by one + of the entities involved. This document provides the two basic types + of non-repudiation service: + + o Non-repudiation with proof of origin: provides the TLS server + with evidence proving that the TLS client has sent it the signed + data at a certain time. + + o Non-repudiation with proof of delivery: provides the TLS client + with evidence that the server has received the client's signed + data at a specific time. + + TLS Handshake exchanges the current time and date according to the + entities internal clock. Thus, the time and date can be stored with + the signed data as a proof of communication. For B2C or B2B + transactions, non-repudiation with proof of origin and non- + repudiation with proof of receipt are both important. If the TLS + client requests a non-repudiation service with proof of receipt, the + server SHOULD verify and send back to client a signature on the hash + of signed data. + + The following figure explains the different events for proving and + storing signed data [RFC2828]. RFC 2828 uses the term "critical + action" to refer to the act of communication between the two + entities. For a complete non-repudiation deployment, 6 phases should + be respected: + + -------- -------- -------- -------- -------- -------- + Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: Phase 6: + Request Generate Transfer Verify Retain Resolve + Service Evidence Evidence Evidence Evidence Dispute + -------- -------- -------- -------- -------- -------- + Service Critical Evidence Evidence Archive Evidence + Request => Action => Stored => Is => Evidence Is + Is Made Occurs For Later Tested In Case Verified + and Use | ^ Critical ^ + Evidence v | Action Is | + Is +-------------------+ Repudiated | + Generated |Verifiable Evidence|------> ----+ + +-------------------+ + + 1- Requesting explicit transaction evidence before sending data. + Normally, this action is taken by the SSL/TLS client + + 2- If the server accepts, the client will generate evidence by + signing data using his X.509 authentication certificate. Server will + go through the same process if the evidence of receipt is requested. + + +Hajjeh & Badra Expires November 2007 [Page 7] +INTERNET-DRAFT TLS Sign June 2007 + + + 3 - The signed data is then sent by the initiator (client or server) + and stored it locally, or by a third party, for a later use if + needed. + + 4 - The entity that receive the evidence process to verify the + signed data. + + 5- The evidence is then stored by the receiver entity for a later + use if needed. + + 6- In this phase, which occurs only if the critical action is + repudiated, the evidence is retrieved from storage, presented, and + verified to resolve the dispute. + + With this method, the stored signed data (or evidence) can be + retrieved by both parties, presented and verified if the critical + action is repudiated. + +Security Considerations + + Security issues are discussed throughout this memo. + +IANA Considerations + + This document defines a new TLS extension "signature", assigned the + value TBD from the TLS ExtensionType registry defined in [TLSEXT]. + + This document defines one TLS ContentType: tls_sign(TBD). This + ContentType value is assigned from the TLS ContentType registry + defined in [TLS]. + + This document defines a new handshake message, certificate_sign, + whose value is to be allocated from the TLS HandshakeType registry + defined in [TLS]. + + The bad_sign alert that is defined in this document is assigned to + the TLS Alert registry defined in [TLS]. + +References + + [TLS] Dierks, T., et. al., "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [TLSExt] Blake-Wilson, S., et. al., "Transport Layer Security TLS) + Extensions", RFC 3546, June 2003. + + [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message + Syntax Standard," version 1.5, November 1993. + + [S/MIME] Ramsdell, B., "S/MIME Version 3 Message Specification", + + +Hajjeh & Badra Expires November 2007 [Page 8] +INTERNET-DRAFT TLS Sign June 2007 + + RFC 2633, June 1999. + + [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML + Signature Syntax and Processing", RFC 3275, March 2002. + + [TLSSign] Hajjeh, I., Serhrouchni, A., "Integrating a signature + module in SSL/TLS, ICETE2004., ACM/IEEE, First + International Conference on E-Business and + Telecommunication Networks, Portugal, August 2004. + + [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May + 2000. + +Author's Addresses + + Ibrahim Hajjeh + Engineering and Scientific Research Groups (ESRGroups) + 82 rue Baudricourt + 75013 Paris Phone: NA + France Email: Ibrahim.Hajjeh@esrgroups.org + + Mohamad Badra + LIMOS Laboratory - UMR 6158, CNRS + France Email: badra@isima.fr + + Acknowledgements + + The authors would like to thank Eric Rescorla for discussions and + comments on the design of TLS Sign. + +Appendix Changelog + + Changes from -01 to -02: + + o Add an IANA section. + + o Small clarifications to section 2. + + o Add the bad_sign alert and the certificate_sign message. + + Changes from -00 to -01: + + o Clarifications to the format of the signed data in Section 2. + + o Small clarifications to TLS SIGN negotiation in Section 2. + + o Added Jacques Demerjian and Mohammed Achemlal as + contributors/authors. + + Full Copyright Statement + + + +Hajjeh & Badra Expires November 2007 [Page 9] +INTERNET-DRAFT TLS Sign June 2007 + + 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. + + Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + + + + +Hajjeh & Badra Expires November 2007 [Page 10] \ No newline at end of file -- cgit v1.2.1