Add.

3 files changed, 1348 insertions, 0 deletions

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 
+                    <draft-badra-ecdhe-tls-psk-00.txt> 
+    
+    
+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 
+                <draft-hajjeh-tls-identity-protection-01.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 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  
+                       <draft-hajjeh-tls-sign-03.txt> 
+    
+    
+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