danetool is being built even without libgnutls-dane.

[gnutls.git] / doc / protocol / draft-hajjeh-tls-sign-02.txt

\r


Internet Engineering Task Force                               I. Hajjeh \r
INTERNET DRAFT                                                ESRGroups \r
                                                          M. Badra, Ed. \r
                                                       LIMOS Laboratory \r
 \r
Expires: April 2007                                       November 2006 \r
    \r
                                  TLS Sign  \r
                       <draft-hajjeh-tls-sign-02.txt> \r
    \r
    \r
Status \r
    \r
   By submitting this Internet-Draft, each author represents that any \r
   applicable patent or other IPR claims of which he or she is aware \r
   have been or will be disclosed, and any of which he or she becomes \r
   aware will be disclosed, in accordance with Section 6 of BCP 79. \r
     \r
   Internet-Drafts are working documents of the Internet Engineering \r
   Task Force (IETF), its areas, and its working groups. Note that \r
   other groups may also distribute working documents as Internet \r
   Drafts. \r
    \r
   Internet-Drafts are draft documents valid for a maximum of six \r
   months and may be updated, replaced, or obsoleted by other documents \r
   at any time. It is inappropriate to use Internet-Drafts as reference \r
   material or to cite them other than as "work in progress."  \r
     \r
   The list of current Internet-Drafts can be accessed at \r
   http://www.ietf.org/ietf/1id-abstracts.txt  \r
     \r
   The list of Internet-Draft Shadow Directories can be accessed at \r
   http://www.ietf.org/shadow.html   \r
     \r
   This Internet-Draft will expire on April 09, 2007. \r
    \r
Copyright Notice \r
    \r
   Copyright (C) The Internet Society (2006). \r
     \r
Abstract  \r
     \r
   TLS protocol provides authentication and data protection for \r
   communication between two entities. However, missing from the \r
   protocol is a way to perform non-repudiation service.  \r
     \r
   This document defines extensions to the TLS protocol to allow it to \r
   perform non-repudiation service. It is based on [TLSSign] and it \r
   provides the client and the server the ability to sign by TLS, \r
   handshake and applications data using certificates such as X.509. \r
    \r

 \r
Hajjeh, et. al.              Expires April 2007                [Page 1] \f\r
INTERNET-DRAFT                   TLS Sign                 November 2006 \r

1 Introduction \r
    \r
   Actually, TLS is the most deployed security protocol for securing \r
   exchanges. It provides end-to-end secure communications between two \r
   entities with authentication and data protection. However, what is \r
   missing from the protocol is a way to provide the non-repudiation \r
   service. \r
    \r
   This document describes how the non-repudiation service may be \r
   integrated as an optional module in TLS. This is in order to provide \r
   both parties with evidence that the transaction has taken place and \r
   to offer a clear separation with application design and development.  \r
    \r
   TLS-Sign's design motivations included:  \r
     \r
   o   TLS is application protocol-independent. Higher-level protocol   \r
       can operate on top of the TLS protocol transparently.  \r
     \r
   o   TLS is a modular nature protocol. Since TLS is developed in four  \r
       independent protocols, the approach defined in this document can  \r
       be added by extending the TLS protocol and with a total \r
       reuse of pre-existing TLS infrastructures and implementations.  \r
        \r
   o   Several applications like E-Business require non-repudiation   \r
       proof of transactions. It is critical in these applications to   \r
       have the non-repudiation service that generates, distributes,   \r
       validates and maintains the evidence of an electronic   \r
       transaction. Since TLS is widely used to secure these   \r
       applications exchanges, the non-repudiation should be offered by   \r
       TLS.  \r
        \r
   o   Generic non-repudiation with TLS. TLS Sign provides a generic   \r
       non-repudiation service that can be easily used with protocols.    \r
       TLS Sign minimizes both design and implementation of the   \r
       signature service and that of the designers and implementators   \r
       who wish to use this module. \r
    \r
1.2 Requirements language \r
    \r
   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document \r
   are to be interpreted as described in RFC-2119. \r
    \r
2 TLS Sign overview  \r
     \r
   TLS Sign is integrated as a higher-level module of the TLS Record \r
   protocol. It is optionally used if the two entities agree. This is \r
   negotiated by extending Client and Server Hello messages in the same \r
   way defined in [TLSExt]. \r
    \r
   In order to allow a TLS client to negotiate the TLS Sign, a new \r
   extension type should be added to the Extended Client and Server \r

 \r
Hajjeh, et. al.              Expires April 2007               [Page 2] \f\r
INTERNET-DRAFT                   TLS Sign                 November 2006 \r

   Hellos messages. TLS clients and servers MAY include an extension of \r
   type 'signature' in the Extended Client and Server Hellos messages. \r
   The 'extension_data' field of this extension contains a \r
   'signature_request' where:  \r
     \r
    enum {  \r
          pkcs7(0), smime(1), xmldsig(2), (255);  \r
       } ContentFormat;  \r
    \r
    struct {  \r
            ContentFormat content_format;  \r
            SignMethod sign_meth;  \r
            SignType sign_type<2..2^16-1>;  \r
         } SignatureRequest;  \r
    \r
    enum {  \r
          ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255);  \r
       } SignMethod;  \r
     \r
    uint8 SignType[2]; \r
    \r
   The client initiates the TLS Sign module by sending the \r
   ExtendedClientHello including the 'signature' extension. This \r
   extension contains:  \r
    \r
   - the SignType carrying the type of the non repudiation proof. It \r
   can have one of these two values: \r
    \r
   SignType non_repudiation_with_proof_of_origin      = { 0x00, 0x01 }; \r
   SignType non_repudiation_without_proof_of_origin   = { 0x00, 0x02 }; \r
    \r
   - the ContentFormat carrying the format of signed data. It can be \r
   PKCS7 [PKCS7], S/MIME [S/MIME] or XMLDSIG [XMLDSIG] \r
    \r
             ContentFormat PKCS7   = { 0x00, 0xA1 }; \r
             ContentFormat SMIME   = { 0x00, 0xA2 }; \r
             ContentFormat XMLDSIG = { 0x00, 0xA3 }; \r
    \r
         o if the value of the ContentFormat is PKCS7, then the PKCS7  \r
           Content_type is of type signed-data. \r
    \r
         o if the value of the ContentFormat is S/MIME, then S/MIME  \r
           Content_type is of type SignedData \r
    \r
         o if the value of the ContentFormat is XMLDSIG, then XMLDSIG  \r
           signatureMethod algorithms. \r
    \r
   - the SignMethod carrying the signature method that is used to sign \r
   the application data (e.g. X509  authentication certificate). \r
    \r
               SignMethod X509 = { 0x00, 0xB1 }; \r

 \r
Hajjeh, et. al.              Expires April 2007               [Page 3] \f\r
INTERNET-DRAFT                   TLS Sign                 November 2006 \r

    \r
   Actually, this document uses the same certificate used in client \r
   authentication. Any new signature method MAY be added in future \r
   versions (e.g. delegated attributes certificates). \r
    \r
   The server MAY reject the connection by sending the error alert \r
   "unsupported_extension" [TLSExt] and closing the connection. \r
    \r
   The client and the server MAY or MAY NOT use the same certificates \r
   used by the Handshake protocol. Several cases are possible: \r
    \r
   - If the server has an interest in getting non-repudiation data from \r
   the client and that the cipher_suites list sent by the client does \r
   not include any cipher_suite with signature ability, the server MUST \r
   (upon reception of tls_sign_on_off protocol message not followed by \r
   a certificate with a type equals to ExtendedServerHello.sign_method) \r
   close the connection by sending a fatal error. \r
    \r
   - If the server has an interest in getting non-repudiation data from \r
   the client and that the cipher_suites list sent by the client \r
   includes at least a cipher_suite with signature ability, the server \r
   SHOULD select a cipher_suite with signature ability and MUST provide \r
   a certificate (e.g., RSA) that MAY be used for key exchange. \r
   Further, the server MUST request a certificate from the client using \r
   the TLS certificate request message (e.g., an RSA or a DSS \r
   signature-capable certificate). If the client does not send a \r
   certificate during the TLS Handshake, the server MUST close the TLS \r
   session by sending a fatal error in the case where the client sends \r
   a tls_sign_on_off protocol message not followed by a certificate \r
   with a type equals to ExtendedServerHello.sign_method. \r
    \r
   - The client or the server MAY use a certificate different to these \r
   being used by TLS Handshake. This MAY happen when the server agrees \r
   in getting non-repudiation data from the client and that the type of \r
   the client certificate used by TLS Handshake and the type selected \r
   by the server from the list in ExtendedClientHello.sign_method are \r
   different, or when the ExtendedServerHello.cipher_suite does not \r
   require client and/or server certificates. In these cases, the \r
   client or the server sends a new message called certificate_sign, \r
   right after sending the tls_sign_on_off protocol messages. The new \r
   message contains the sender's certificate in which the type is the \r
   same type selected by the server from the list in \r
   ExtendedClientHello.sign_method. The certificate_sign is therefore \r
   used to generate signed data. It is defined as follows: \r
    \r
       opaque ASN.1Cert<2^24-1>; \r
    \r
       struct { \r
           ASN.1Cert certificate_list<1..2^24-1>; \r
       } CertificateSign; \r
    \r

 \r
Hajjeh, et. al.              Expires April 2007               [Page 4] \f\r
INTERNET-DRAFT                   TLS Sign                 November 2006 \r

   The certificate_list, as defined in [TLS], is a sequence (chain) of \r
   certificates. The sender's certificate MUST come first in the list. \r
    \r
   If the server has no interest in getting non-repudiation data from \r
   the client, it replays with an ordinary TLS ServerHello or return a \r
   handshake failure alert and close the connection [TLS]. \r
    \r
         Client                                               Server  \r
         ------                                               ------  \r
    \r
         ClientHello             -------->  \r
                                                         ServerHello  \r
                                                        Certificate* \r
                                                  ServerKeyExchange*  \r
                                                 CertificateRequest*  \r
                                 <--------           ServerHelloDone  \r
         Certificate*  \r
         ClientKeyExchange  \r
         CertificateVerify* \r
         [ChangeCipherSpec] \r
         Finished                -------->  \r
                                                  [ChangeCipherSpec] \r
                                 <--------                  Finished \r
    \r
         TLSSignOnOff   <-------------------------->    TLSSignOnOff \r
          \r
         CertificateSign* <-----------------------> CertificateSign* \r
     \r
         (Signed) Application Data <---->  (Signed) Application Data \r
    \r
   * Indicates optional or situation-dependent messages that are not \r
   always sent. \r
    \r
2.1 tls sign on off protocol  \r
    \r
   To manage the generation of evidence, new sub-protocol is added by \r
   this document, called tls_sign_on_off. This protocol consists of a \r
   single message that is encrypted and compressed under the \r
   established connection state. This message can be sent at any time \r
   after the TLS session has been established. Thus, no man in the \r
   middle can replay or inject this message. It consists of a single \r
   byte of value 1 (tls_sign_on) or 0 (tls_sign_off). \r
    \r
       enum {   \r
             change_cipher_spec(20), alert(21), handshake(22),   \r
             application_data(23), tls_sign(TBC), (255)   \r
          } ContentType;   \r
      \r
       struct {   \r
               enum { tls_sign_off(0), tls_sign_on(1), (255) } type;   \r
            } TLSSignOnOff;  \r

 \r
Hajjeh, et. al.              Expires April 2007               [Page 5] \f\r
INTERNET-DRAFT                   TLS Sign                 November 2006 \r

    \r
   The tls_sign_on_off message is sent by the client and/or server to \r
   notify the receiving party that subsequent records will carry data \r
   signed under the negotiated parameters.   \r
    \r
   Note: TLSSignOnOff is an independent TLS Protocol content type, and \r
   is not actually a TLS handshake message. \r
    \r
 2.1.1 TLS sign packet format  \r
    \r
   This document defines a new packet format that encapsulates signed \r
   data, the TLSSigntext. The packet format is shown below. The fields \r
   are transmitted from left to right.  \r
    \r
   0                   1                   2                   3        \r
   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    \r
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   \r
   | Content-Type  |     Flag      |     Version                   |   \r
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  \r
   |              Length           |  Signed Data ...  \r
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   \r
    \r
   Content-Type \r
    \r
   Same as TLSPlaintext.type. \r
    \r
   Flag \r
    \r
   0 1 2 3 4 5 6 7 8  \r
   +-+-+-+-+-+-+-+-+   \r
   |A R R R R R R R|   \r
   +-+-+-+-+-+-+-+-+   \r
    \r
   A = acknowledgement of receipt \r
   R = Reserved \r
    \r
   When the whole signed data is delivered to the receiver, the TLS \r
   Sign will check the signature. If the signature is valid and that \r
   the sender requires a proof of receipt, the receiver MUST generate a \r
   TLSSigntext packet with the bit A set to 1 (acknowledgement of \r
   receipt). This helps the receiver of the acknowledgment of receipt \r
   in storing the data-field for later use (see section 2.2). The data-\r
   field of that message contains the digest of the whole data receiver \r
   by the generator of the acknowledgement of receipt. The digest is \r
   signed before sending the result to the other side. \r
    \r
    2.1.3 bad_sign alert \r
    \r
   This alert is returned if a record is received with an incorrect \r
   signature. This message is always fatal. \r
    \r

 \r
Hajjeh, et. al.              Expires April 2007               [Page 6] \f\r
INTERNET-DRAFT                   TLS Sign                 November 2006 \r

2.2 Storing signed data  \r
    \r
   The objective of TLS Sign is to provide both parties with evidence \r
   that can be stored and later presented to a third party to resolve \r
   disputes that arise if and when a communication is repudiated by one \r
   of the entities involved. This document provides the two basic types \r
   of non-repudiation service:  \r
    \r
   o   Non-repudiation with proof of origin: provides the TLS server   \r
       with evidence proving that the TLS client has sent it the signed   \r
       data at a certain time.  \r
    \r
   o   Non-repudiation with proof of delivery: provides the TLS client   \r
       with evidence that the server has received the client's signed   \r
       data at a specific time.  \r
    \r
   TLS Handshake exchanges the current time and date according to the \r
   entities internal clock. Thus, the time and date can be stored with \r
   the signed data as a proof of communication. For B2C or B2B \r
   transactions, non-repudiation with proof of origin and non-\r
   repudiation with proof of receipt are both important. If the TLS \r
   client requests a non-repudiation service with proof of receipt, the \r
   server SHOULD verify and send back to client a signature on the hash \r
   of signed data.  \r
    \r
   The following figure explains the different events for proving and \r
   storing signed data [RFC2828]. RFC 2828 uses the term "critical \r
   action" to refer to the act of communication between the two \r
   entities. For a complete non-repudiation deployment, 6 phases should \r
   be respected: \r
    \r
   --------   --------   --------   --------   --------     --------  \r
   Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:     Phase 6:  \r
   Request    Generate   Transfer   Verify     Retain       Resolve  \r
   Service    Evidence   Evidence   Evidence   Evidence     Dispute  \r
   --------   --------   --------   --------   --------     --------  \r
   Service    Critical   Evidence   Evidence   Archive      Evidence  \r
   Request => Action  => Stored  => Is      => Evidence     Is  \r
   Is Made    Occurs     For Later  Tested     In Case      Verified  \r
              and        Use |          ^      Critical         ^  \r
              Evidence       v          |      Action Is        |  \r
              Is         +-------------------+ Repudiated       |  \r
              Generated  |Verifiable Evidence|------>       ----+  \r
                         +-------------------+  \r
    \r
   1- Requesting explicit transaction evidence before sending data. \r
   Normally, this action is taken by the SSL/TLS client  \r
    \r
   2- If the server accepts, the client will generate evidence by \r
   signing data using his X.509 authentication certificate. Server will \r
   go through the same process if the evidence of receipt is requested. \r

 \r
Hajjeh, et. al.              Expires April 2007               [Page 7] \f\r
INTERNET-DRAFT                   TLS Sign                 November 2006 \r

    \r
   3 - The signed data is then sent by the initiator (client or server) \r
   and stored it locally, or by a third party, for a later use if \r
   needed. \r
    \r
   4 - The entity that receive the evidence process to verify the \r
   signed data. \r
    \r
   5- The evidence is then stored by the receiver entity for a later \r
   use if needed. \r
    \r
   6- In this phase, which occurs only if the critical action is \r
   repudiated, the evidence is retrieved from storage, presented, and \r
   verified to resolve the dispute. \r
    \r
   With this method, the stored signed data (or evidence) can be \r
   retrieved by both parties, presented and verified if the critical \r
   action is repudiated. \r
    \r
Security Considerations \r
    \r
   Security issues are discussed throughout this memo. \r
    \r
IANA Considerations \r
    \r
   This document defines a new TLS extension "signature", assigned the \r
   value TBD from the TLS ExtensionType registry defined in [TLSEXT]. \r
    \r
   This document defines one TLS ContentType: tls_sign(TBD). This \r
   ContentType value is assigned from the TLS ContentType registry \r
   defined in [TLS]. \r
    \r
   This document defines a new handshake message, certificate_sign, \r
   whose value is to be allocated from the TLS HandshakeType registry \r
   defined in [TLS]. \r
    \r
   The bad_sign alert that is defined in this document is assigned to \r
   the TLS Alert registry defined in [TLS]. \r
    \r
References \r
    \r
   [TLS]     Dierks, T., et. al., "The TLS Protocol Version 1.0",  \r
             RFC 2246, January 1999. \r
    \r
   [TLSExt]  Blake-Wilson, S., et. al., "Transport Layer Security TLS)  \r
             Extensions", RFC 3546, June 2003. \r
    \r
   [PKCS7]   RSA Laboratories, "PKCS #7: RSA Cryptographic Message  \r
             Syntax Standard," version 1.5, November 1993.  \r
        \r
   [S/MIME]  Ramsdell, B., "S/MIME Version 3 Message Specification",  \r

 \r
Hajjeh, et. al.              Expires April 2007               [Page 8] \f\r
INTERNET-DRAFT                   TLS Sign                 November 2006 \r

             RFC 2633, June 1999.  \r
    \r
   [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML  \r
             Signature Syntax and Processing", RFC 3275, March 2002.  \r
    \r
   [TLSSign] Hajjeh, I., Serhrouchni, A., "Integrating a signature   \r
             module in SSL/TLS, ICETE2004., ACM/IEEE, First   \r
             International Conference on E-Business and  \r
             Telecommunication Networks, Portugal, August 2004.  \r
    \r
   [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May   \r
             2000. \r
    \r
Author's and Contributors' Addresses \r
    \r
   Ibrahim Hajjeh  \r
   Engineering and Scientific Research Groups (ESRGroups) \r
   17 Passage Barrault  \r
   75013 Paris               Phone: NA  \r
   France                    Email: Ibrahim.Hajjeh@esrgroups.org \r
    \r
   Mohamad Badra \r
   LIMOS Laboratory - UMR (6158), CNRS \r
   France                    Email: badra@isima.fr \r
    \r
   Ahmed serhrouchni  \r
   ENST                      Phone: NA  \r
   France                    Email: Ahmed.serhrouchni@enst.fr  \r
    \r
   Jacques Demerjian  \r
   France Telecom R&D  \r
   42 rue des coutures  \r
   14066 Caen Cedex 4        Phone: NA  \r
   France                    Email: jacques.demerjian@francetelecom.com \r
    \r
   Acknowledgements  \r
    \r
   The authors would like to thank Eric Rescorla for discussions and \r
   comments on the design of TLS Sign. \r
    \r
Appendix  Changelog \r
    \r
   Changes from -01 to -02: \r
    \r
   o Add an IANA section. \r
    \r
   o Small clarifications to section 2.  \r
    \r
   o Add the bad_sign alert and the certificate_sign message. \r
    \r
   Changes from -00 to -01: \r

 \r
Hajjeh, et. al.              Expires April 2007               [Page 9] \f\r
INTERNET-DRAFT                   TLS Sign                 November 2006 \r

    \r
   o Clarifications to the format of the signed data in Section 2. \r
    \r
   o Small clarifications to TLS SIGN negotiation in Section 2. \r
    \r
   o Added Jacques Demerjian and Mohammed Achemlal as \r
     contributors/authors. \r
    \r
   Intellectual Property Statement  \r
     \r
   The IETF takes no position regarding the validity or scope of any \r
   Intellectual Property Rights or other rights that might be claimed \r
   to pertain to the implementation or use of the technology described \r
   in this document or the extent to which any license under such \r
   rights might or might not be available; nor does it represent that \r
   it has made any independent effort to identify any such rights. \r
   Information on the IETF's procedures with respect to rights in IETF \r
   Documents can be found in BCP 78 and BCP 79. \r
    \r
   Copies of IPR disclosures made to the IETF Secretariat and any \r
   assurances of licenses to be made available, or the result of an \r
   attempt made to obtain a general license or permission for the use \r
   of such proprietary rights by implementers or users of this \r
   specification can be obtained from the IETF on-line IPR repository \r
   at http://www.ietf.org/ipr. \r
    \r
   The IETF invites any interested party to bring to its attention any \r
   copyrights, patents or patent applications, or other proprietary \r
   rights that may cover technology that may be required to implement \r
   this standard. Please address the information to the IETF at ietf-\r
   ipr@ietf.org. \r
    \r
   Disclaimer of Validity \r
    \r
   This document and the information contained herein are provided on \r
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE \r
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE \r
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR \r
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF \r
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED \r
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  \r
    \r
   Copyright Statement \r
     \r
   Copyright (C) The Internet Society (2006). This document is subject \r
   to the rights, licenses and restrictions contained in BCP 78, and \r
   except as set forth therein, the authors retain all their rights. \r
    \r
   Acknowledgment  \r
    \r


 \r
Hajjeh, et. al.              Expires April 2007               [Page 10] \f\r
INTERNET-DRAFT                   TLS Sign                 November 2006 \r

   Funding for the RFC Editor function is currently provided by the \r
   Internet Society. \r


















































 \r
Hajjeh, et. al.              Expires April 2007               [Page 11] \f