path: root/doc/protocol/draft-hajjeh-tls-sign-01.txt

Internet Engineering Task Force                               I. Hajjeh 
INTERNET DRAFT                                                ESRGroups 
                                                               M. Badra 
                                                         A. Serhrouchni 
                                                             ENST Paris 
                                                           J. Demerjian 
                                                            M. Achemlal 
                                                     France Telecom R&D 
Expires: April 2006                                    October 20, 2005 
    
                                  TLS Sign  
                       <draft-hajjeh-tls-sign-01.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 April 20, 2006. 
    
Copyright Notice 
    
   Copyright (C) The Internet Society (2005). 
     
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 

 
Hajjeh, et. al.              Expires April 2006                [Page 1] 
INTERNET-DRAFT                   TLS Sign                  October 2005 
 
   provides the client and the server the ability to sign by TLS, 
   handshake and applications data using certificates such as X.509. 
    
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]. 

 
Badra & Hajjeh               Expires April 2006               [Page 2] 
INTERNET-DRAFT                   TLS Sign                  October 2005 
 
    
   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 
   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;  
         } signature_request;  
    
    enum {  
          ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255);  
       } SignMethod;  
     
    opaque Signature_type<1..2^16-1>;  
      
   The client initiates the TLS Sign module by sending the 
   ExtendedClientHello including the 'signature' extension. This 
   extension contains:  
 
   - the SignType contains 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 contains 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. 
    


 
Badra & Hajjeh               Expires April 2006               [Page 3] 
INTERNET-DRAFT                   TLS Sign                  October 2005 
 
   - the sign_method contains the signature method that is used to sign 
   the application data (e.g. X509  authentication certificate). 
    
               SignMethod X509 = { 0x00, 0xB1 }; 
    
   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. 
    
   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 
   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 
   MUST 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). This request however, MUST be appropriate for the 
   selected cipher suite. 
    
   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  
         (Signed) Application Data    <------->   (Signed) App. Data 
    
   However, the client MAY request a non-repudiation data without 
   having a certificate. In this case, the client MAY reject the 

 
Badra & Hajjeh               Expires April 2006               [Page 4] 
INTERNET-DRAFT                   TLS Sign                  October 2005 
 
   connection if the server is not ready to give it the non-repudiation 
   service. This MAY be done using the signature type field of the 
   signature_request structure. 
    
2.1 Signed data Record type  
    
   New record type is added in this document: the signed data protocol. 
   The message consists of a single byte of value 1 or 0.   
    
       enum {   
             change_cipher_spec(20), alert(21), handshake(22),   
             application_data(23), tls_sign(25), (255)   
          } ContentType;   
      
       struct {   
               enum { tls_sign_off(0), tls_sign_on(1), (255) } type;   
            } TLSSignOnOff;  
    
 2.1.1 TLS Sign activate/deactivate  
    
   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. Thus, no man in the middle can replay 
   or inject this message. It consists of a Boolean of value 1 
   (tls_sign_on) or 0 (tls_sign_off). 
    
   The tls_sign_on_off message is sent by both the client and server to 
   notify the receiving party that subsequent records will carry data 
   under the negotiated parameters and keys.   
    
   If the client was not authenticated in his first TLS exchange or 
   does not support a signature algorithm, the server who receives 
   tls_sign_on_off message, MAY answer by signed data, ignore it or MAY 
   invite the client to start a new TLS session sending the 
   HelloRequest message.   
    
   This message can be sent at any time after the TLS session has been 
   established.  
    
 2.1.2 TLS sign packet format  
    
   This document defines a new packet format that encapsulates signed 
   data. The packet format is shown below. The fields are transmitted 
   from left to right.  
    
    
    
    
    
    

 
Badra & Hajjeh               Expires April 2006               [Page 5] 
INTERNET-DRAFT                   TLS Sign                  October 2005 
 
   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  |          Length               |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                Signed Data ...  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
    
   Content-Type 
    
   0 1 2 3 4 5 6 7   
   +-+-+-+-+-+-+-+-+   
   |A D R R R R R R|   
   +-+-+-+-+-+-+-+-+   
    
   A = acknowledgement of receipt  
   D = signed data  
   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 
   message with Type=A (acknowledgement of receipt). The data-field of 
   that message contains the digest of the whole data. The digest is 
   signed before sending the result to the other side. 
    
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.  
    

 
Badra & Hajjeh               Expires April 2006               [Page 6] 
INTERNET-DRAFT                   TLS Sign                  October 2005 
 
   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. 
    
   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. 
    



 
Badra & Hajjeh               Expires April 2006               [Page 7] 
INTERNET-DRAFT                   TLS Sign                  October 2005 
 
 
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",  
             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) 
   17 Passage Barrault  
   75013 Paris               Phone: NA  
   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
    
   Mohamad Badra  
   ENST 
   46 rue Barrault  
   75634 Paris               Phone: NA  
   France                    Email: Mohamad.Badra@enst.fr 
    
   Ahmed serhrouchni  
   ENST                      Phone: NA  
   France                    Email: Ahmed.serhrouchni@enst.fr  
    
   Jacques Demerjian  
   France Telecom R&D  
   42 rue des coutures  
   14066 Caen Cedex 4        Phone: NA  
   France                    Email: jacques.demerjian@francetelecom.com 
    
   Mohammed Achemlal  

 
Badra & Hajjeh               Expires April 2006               [Page 8] 
INTERNET-DRAFT                   TLS Sign                  October 2005 
 
   France Telecom R&D        Phone: NA  
   France                    Email: Mohammed.Achemlal@francetelecom.com 
    
   Acknowledgements  
    
   The authors would like to thank Eric Rescorla for discussions and 
   comments on the design of TLS Sign. 
    
Appendix  Changelog 
    
   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. 
    
   Intellectual Property Statement  
     
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights. 
   Information on the IETF's procedures with respect to rights in IETF 
   Documents can be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org. 
    
   Disclaimer of Validity 
    
   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 


 
Badra & Hajjeh               Expires April 2006               [Page 9] 
INTERNET-DRAFT                   TLS Sign                  October 2005 
 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  
    
   Copyright Statement 
     
   Copyright (C) The Internet Society (2004). This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
    
   Acknowledgment  
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 







































 
Badra & Hajjeh               Expires April 2006               [Page 10]