[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03 04                                                
Internet Engineering Task Force                             I. Hajjeh
INTERNET DRAFT                                         A. Serhrouchni
                                                           ENST Paris
                                                        M. Badra, Ed.
                                                         O. Cherkaoui
                                                      UQAM University
Expires: June 2005                                   January 09, 2005

                               TLS Sign
                    <draft-hajjeh-tls-sign-00.txt>


Status

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   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

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

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, et. al.       Informational - Expires June 2005        [Page 1]


INTERNET-DRAFT                   TLS Sign                  January 2005

Table of Contents

   Abstract...........................................................1
   1 Introduction.....................................................2
   1.2 Requirements language..........................................3
   2 TLS Sign overview................................................3
      2.1 Signed data Record type.....................................5
      2.1.1 TLS Sign activate/deactivate..............................5
      2.1.1 TLS sign packet format....................................5
      2.2 Storing signed data.........................................6
   Security Considerations............................................7
   References.........................................................7
   Author's Addresses.................................................8

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.




Hajjeh, et. al.       Informational - Expires June 2005        [Page 2]


INTERNET-DRAFT                   TLS Sign                  January 2005

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
   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;
             Signature_type sign_type<1..2^16-1>;
        } 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 signature type (e.g., non-repudiation with proof of origin),
   - the content format (e.g., PKCS7 [PKCS7], S/MIME [S/MIME], XMLDSIG
     [XMLDSIG]),
   - the signature method (e.g. X509 authentication certificate).
     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.




Hajjeh, et. al.       Informational - Expires June 2005        [Page 3]


INTERNET-DRAFT                   TLS Sign                  January 2005

   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 with signing
   ability in the 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, the server will select a cipher_suite or, if no
   acceptable choices are presented, return a handshake failure alert
   and close the connection [TLS]."

   However, the client MAY demand a non-repudiation data without having
   a certificate. In this case, the client MAY reject the 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.

         Client                                               Server
         ------                                               ------

         ClientHello                  -------->
                                                         ServerHello
                                                         Certificate
                                                  ServerKeyExchange*
                                                  CertificateRequest
                                      <--------      ServerHelloDone
         Certificate
         ClientKeyExchange
         CertificateVerify
         ChangeCipherSpec
         Finished                     -------->
                                                    ChangeCipherSpec
                                      <--------             Finished
         (Signed) Application Data    <------->   (Signed) App. Data










Hajjeh, et. al.       Informational - Expires June 2005        [Page 4]


INTERNET-DRAFT                   TLS Sign                  January 2005

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 record 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 point after the TLS session has been
   established.

2.1.1 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.

    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


Hajjeh, et. al.       Informational - Expires June 2005        [Page 5]


INTERNET-DRAFT                   TLS Sign                  January 2005

    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), and as data-field
   the digest of the whole data. The data-field is of course signed by
   the receiver before it is sent to the sender.

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:







Hajjeh, et. al.       Informational - Expires June 2005        [Page 6]


INTERNET-DRAFT                   TLS Sign                  January 2005

    --------   --------   --------   --------   --------   . --------
    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.

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.



Hajjeh, et. al.       Informational - Expires June 2005        [Page 7]


INTERNET-DRAFT                   TLS Sign                  January 2005

   [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, ICETEƆ2004, 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
   ENST
   46 rue Barrault
   75013 Paris               Phone: NA
   France                    Email: Ibrahim.Hajjeh@enst.fr

   Ahmed serhrouchni
   ENST
   46 rue Barrault
   75013 Paris               Phone: NA
   France                    Email: Ahmed.serhrouchni@enst.fr

   Mohamad Badra
   UQAM University
   Montreal (Quebec)         Phone: NA
   Canada                    Email: Mohamad.Badra@uqam.ca

   Omar Cherkaoui
   UQAM University
   Montreal (Quebec)         Phone: NA
   Canada                    Email: Omar.Cherkaoui@uqam.ca

   Acknowledgements

   The authors would like to thank Eric Rescorla for discussions and
   comments on the design of TLS Sign.

   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


Hajjeh, et. al.       Informational - Expires June 2005        [Page 8]


INTERNET-DRAFT                   TLS Sign                  January 2005

   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
   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.














Hajjeh, et. al.       Informational - Expires June 2005        [Page 9]