doc/protocol/draft-hajjeh-tls-sign-00.txt

   1
   2 Internet Engineering Task Force                             I. Hajjeh
   3 INTERNET DRAFT                                         A. Serhrouchni
   4                                                            ENST Paris
   5                                                         M. Badra, Ed.
   6                                                          O. Cherkaoui
   7                                                       UQAM University
   8 Expires: June 2005                                   January 09, 2005
   9
  10                                TLS Sign
  11                     <draft-hajjeh-tls-sign-00.txt>
  12
  13
  14 Status
  15
  16    By submitting this Internet-Draft, I certify that any applicable
  17    patent or other IPR claims of which I am aware have been disclosed,
  18    or will be disclosed, and any of which I become aware will be
  19    disclosed, in accordance with RFC 3668.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups. Note that
  23    other groups may also distribute working documents as Internet
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six
  27    months and may be updated, replaced, or obsoleted by other documents
  28    at any time. It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html
  36
  37 Copyright Notice
  38
  39    Copyright (C) The Internet Society (2004).  All Rights Reserved.
  40
  41 Abstract
  42
  43    TLS protocol provides authentication and data protection for
  44    communication between two entities. However, missing from the
  45    protocol is a way to perform non-repudiation service.
  46
  47    This document defines extensions to the TLS protocol to allow it to
  48    perform non-repudiation service. It is based on [TLSSign] and it
  49    provides the client and the server the ability to sign by TLS,
  50    handshake and applications data using certificates such as X.509.
  51
  52
  53
  54
  55 Hajjeh, et. al.       Informational - Expires June 2005        [Page 1]
  56 INTERNET-DRAFT                   TLS Sign                  January 2005
  57
  58 Table of Contents
  59
  60    Abstract...........................................................1
  61    1 Introduction.....................................................2
  62    1.2 Requirements language..........................................3
  63    2 TLS Sign overview................................................3
  64       2.1 Signed data Record type.....................................5
  65       2.1.1 TLS Sign activate/deactivate..............................5
  66       2.1.1 TLS sign packet format....................................5
  67       2.2 Storing signed data.........................................6
  68    Security Considerations............................................7
  69    References.........................................................7
  70    Author's Addresses.................................................8
  71
  72 1 Introduction
  73
  74    Actually, TLS is the most deployed security protocol for securing
  75    exchanges. It provides end-to-end secure communications between two
  76    entities with authentication and data protection. However, what is
  77    missing from the protocol is a way to provide the non-repudiation
  78    service.
  79
  80    This document describes how the non-repudiation service may be
  81    integrated as an optional module in TLS. This is in order to provide
  82    both parties with evidence that the transaction has taken place and
  83    to offer a clear separation with application design and development.
  84    TLS-Sign's design motivations included:
  85
  86    o   TLS is application protocol-independent. Higher-level protocol
  87        can operate on top of the TLS protocol transparently.
  88
  89    o   TLS is a modular nature protocol. Since TLS is developed in four
  90        independent protocols, the approach defined in this document can
  91        be added by extending the TLS protocol and with a total
  92        reuse of pre-existing TLS infrastructures and implementations.
  93
  94    o   Several applications like E-Business require non-repudiation
  95        proof of transactions. It is critical in these applications to
  96        have the non-repudiation service that generates, distributes,
  97        validates and maintains the evidence of an electronic
  98        transaction. Since TLS is widely used to secure these
  99        applications exchanges, the non-repudiation should be offered by
 100        TLS.
 101
 102    o   Generic Non repudiation with TLS. TLS SIGN provides a generic
 103        non-repudiation service that can be easily used with protocols.
 104        TLS SIGN minimizes both design and implementation of the
 105        signature service and that of the designers and implementators
 106        who wish to use this module.
 107
 108
 109
 110
 111 Hajjeh, et. al.       Informational - Expires June 2005        [Page 2]
 112 INTERNET-DRAFT                   TLS Sign                  January 2005
 113
 114 1.2 Requirements language
 115
 116    The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document
 117    are to be interpreted as described in RFC-2119.
 118
 119 2 TLS Sign overview
 120
 121    TLS Sign is integrated as a higher-level module of the TLS Record
 122    protocol. It is optionally used if the two entities agree. This is
 123    negotiated by extending Client and Server Hello messages in the same
 124    way defined in [TLSExt].
 125
 126    In order to allow a TLS client to negotiate the TLS Sign, a new
 127    extension type should be added to the Extended Client and Server
 128    Hellos messages. TLS clients and servers may include an extension of
 129    type 'signature' in the Extended Client and Server Hellos messages.
 130    The 'extension_data' field of this extension contains a
 131    'signature_request' where:
 132
 133      enum {
 134            pkcs7(0), smime(1), xmldsig(2), (255);
 135         } ContentFormat;
 136
 137      struct {
 138              ContentFormat content_format;
 139              SignMethod sign_meth;
 140              Signature_type sign_type<1..2^16-1>;
 141         } signature_request;
 142
 143      enum {
 144          ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255);
 145         } SignMethod;
 146
 147        opaque Signature_type<1..2^16-1>;
 148
 149    The client initiates the TLS Sign module by sending the
 150    ExtendedClientHello including the 'signature' extension. This
 151    extension contains:
 152
 153    - the signature type (e.g., non-repudiation with proof of origin),
 154    - the content format (e.g., PKCS7 [PKCS7], S/MIME [S/MIME], XMLDSIG
 155      [XMLDSIG]),
 156    - the signature method (e.g. X509 authentication certificate).
 157      Actually, this document uses the same certificate used in client
 158      authentication. Any new signature method MAY be added in future
 159      versions (e.g. delegated attributes certificates).
 160
 161    The server MAY reject the connection by sending the error alert
 162    "unsupported_extension" [TLSExt] and closing the connection.
 163
 164
 165
 166
 167 Hajjeh, et. al.       Informational - Expires June 2005        [Page 3]
 168 INTERNET-DRAFT                   TLS Sign                  January 2005
 169
 170    If the server has an interest in getting non-repudiation data from
 171    the client and that the cipher_suites list sent by the client does
 172    not include any cipher_suite with signature ability, the server MUST
 173    close the connection by sending a fatal error.
 174
 175    If the server has an interest in getting non-repudiation data from
 176    the client and that the cipher_suites list sent by the client
 177    includes at least a cipher_suite with signature ability, the server
 178    MUST select a cipher_suite with signature ability and MUST provide a
 179    certificate (e.g., RSA) that MAY be used for key exchange. Further,
 180    the server MUST request a certificate from the client with signing
 181    ability in the certificate request message (e.g., an RSA or a DSS
 182    signature-capable certificate). This request however, MUST be
 183    appropriate for the selected cipher suite.
 184
 185    If the server has no interest in getting non-repudiation data from
 186    the client, the server will select a cipher_suite or, if no
 187    acceptable choices are presented, return a handshake failure alert
 188    and close the connection [TLS]."
 189
 190    However, the client MAY demand a non-repudiation data without having
 191    a certificate. In this case, the client MAY reject the connection if
 192    the server is not ready to give it the non-repudiation service. This
 193    may be done using the signature type field of the signature_request
 194    structure.
 195
 196          Client                                               Server
 197          ------                                               ------
 198
 199          ClientHello                  -------->
 200                                                          ServerHello
 201                                                          Certificate
 202                                                   ServerKeyExchange*
 203                                                   CertificateRequest
 204                                       <--------      ServerHelloDone
 205          Certificate
 206          ClientKeyExchange
 207          CertificateVerify
 208          ChangeCipherSpec
 209          Finished                     -------->
 210                                                     ChangeCipherSpec
 211                                       <--------             Finished
 212          (Signed) Application Data    <------->   (Signed) App. Data
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223 Hajjeh, et. al.       Informational - Expires June 2005        [Page 4]
 224 INTERNET-DRAFT                   TLS Sign                  January 2005
 225
 226 2.1 Signed data Record type
 227
 228    New record type is added in this document: the signed data protocol.
 229    The message consists of a single byte of value 1 or 0.
 230
 231        enum {
 232            change_cipher_spec(20), alert(21), handshake(22),
 233            application_data(23), tls_sign(25), (255)
 234        } ContentType;
 235
 236        struct {
 237            enum { tls_sign_off(0), tls_sign_on(1), (255) } type;
 238        } TLSSignOnOff;
 239
 240 2.1.1 TLS Sign activate/deactivate
 241
 242    To manage the generation of evidence, new record protocol is added
 243    by this document, called tls_sign_on_off. This protocol consists of
 244    a single message that is encrypted and compressed under the
 245    established connection state. Thus, no man in the middle can replay
 246    or inject this message. It consists of a Boolean of value 1
 247    (tls_sign_on) or 0 (tls_sign_off).
 248
 249    The tls_sign_on_off message is sent by both the client and server to
 250    notify the receiving party that subsequent records will carry data
 251    under the negotiated parameters and keys.
 252
 253    If the client was not authenticated in his first TLS exchange or
 254    does not support a signature algorithm, the server who receives
 255    tls_sign_on_off message, MAY answer by signed data, ignore it or MAY
 256    invite the client to start a new TLS session sending the
 257    HelloRequest message.
 258
 259    This message can be sent at any point after the TLS session has been
 260    established.
 261
 262 2.1.1 TLS sign packet format
 263
 264    This document defines a new packet format that encapsulates signed
 265    data. The packet format is shown below. The fields are transmitted
 266    from left to right.
 267
 268     0                   1                   2                   3
 269     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
 270    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 271    | Content-Type  |          Length               |
 272    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 273    |                Signed Data ...
 274    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 275
 276    Content-Type
 277
 278
 279 Hajjeh, et. al.       Informational - Expires June 2005        [Page 5]
 280 INTERNET-DRAFT                   TLS Sign                  January 2005
 281
 282     0 1 2 3 4 5 6 7
 283    +-+-+-+-+-+-+-+-+
 284    |A D R R R R R R|
 285    +-+-+-+-+-+-+-+-+
 286
 287    A = acknowledgement of receipt
 288    D = signed data
 289    R = Reserved
 290
 291    When the whole signed data is delivered to the receiver, the TLS
 292    Sign will check the signature. If the signature is valid and that
 293    the sender requires a proof of receipt, the receiver MUST generate a
 294    message with Type=A (acknowledgement of receipt), and as data-field
 295    the digest of the whole data. The data-field is of course signed by
 296    the receiver before it is sent to the sender.
 297
 298 2.2 Storing signed data
 299
 300    The objective of TLS Sign is to provide both parties with evidence
 301    that can be stored and later presented to a third party to resolve
 302    disputes that arise if and when a communication is repudiated by one
 303    of the entities involved. This document provides the two basic types
 304    of non-repudiation service:
 305
 306    o   Non-repudiation with proof of origin: provides the TLS server
 307        with evidence proving that the TLS client has sent it the signed
 308        data at a certain time.
 309
 310    o   Non-repudiation with proof of delivery: provides the TLS client
 311        with evidence that the server has received the client's signed
 312        data at a specific time.
 313
 314    TLS Handshake exchanges the current time and date according to the
 315    entities internal clock. Thus, the time and date can be stored with
 316    the signed data as a proof of communication. For B2C or B2B
 317    transactions, non-repudiation with proof of origin and non-
 318    repudiation with proof of receipt are both important. If the TLS
 319    client requests a non-repudiation service with proof of receipt, the
 320    server SHOULD verify and send back to client a signature on the hash
 321    of signed data.
 322
 323    The following figure explains the different events for proving and
 324    storing signed data [RFC2828]. RFC 2828 uses the term "critical
 325    action" to refer to the act of communication between the two
 326    entities. For a complete non-repudiation deployment, 6 phases should
 327    be respected:
 328
 329
 330
 331
 332
 333
 334
 335 Hajjeh, et. al.       Informational - Expires June 2005        [Page 6]
 336 INTERNET-DRAFT                   TLS Sign                  January 2005
 337
 338     --------   --------   --------   --------   --------   . --------
 339     Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:   . Phase 6:
 340     Request    Generate   Transfer   Verify     Retain     . Resolve
 341     Service    Evidence   Evidence   Evidence   Evidence   . Dispute
 342     --------   --------   --------   --------   --------   . --------
 343     Service    Critical   Evidence   Evidence   Archive    . Evidence
 344     Request => Action  => Stored  => Is      => Evidence   . Is
 345     Is Made    Occurs     For Later  Tested     In Case    . Verified
 346                and        Use |          ^      Critical   .     ^
 347                Evidence       v          |      Action Is  .     |
 348                Is         +-------------------+ Repudiated .     |
 349                Generated  |Verifiable Evidence|------> ... . ----+
 350                           +-------------------+
 351
 352    1- Requesting explicit transaction evidence before sending data.
 353    Normally, this action is taken by the SSL/TLS client
 354
 355    2- If the server accepts, the client will generate evidence by
 356    signing data using his X.509 authentication certificate. Server will
 357    go through the same process if the evidence of receipt is requested.
 358
 359    3 - The signed data is then sent by the initiator (client or server)
 360    and stored it locally, or by a third party, for a later use if
 361    needed.
 362
 363    4 - The entity that receive the evidence process to verify the
 364    signed data.
 365
 366    5- The evidence is then stored by the receiver entity for a later
 367    use if needed.
 368
 369    6- In this phase, which occurs only if the critical action is
 370    repudiated, the evidence is retrieved from storage, presented, and
 371    verified to resolve the dispute.
 372
 373    With this method, the stored signed data (or evidence) can be
 374    retrieved by both parties, presented and verified if the critical
 375    action is repudiated.
 376
 377 Security Considerations
 378
 379    Security issues are discussed throughout this memo.
 380
 381 References
 382
 383    [TLS]    Dierks, T., et. al, "The TLS Protocol Version 1.0", RFC
 384             2246, January 1999.
 385
 386    [TLSExt] Blake-Wilson, S., et. al, "Transport Layer Security (TLS)
 387             Extensions", RFC 3546, June 2003.
 388
 389
 390
 391 Hajjeh, et. al.       Informational - Expires June 2005        [Page 7]
 392 INTERNET-DRAFT                   TLS Sign                  January 2005
 393
 394    [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message
 395             Syntax Standard," version 1.5, November 1993.
 396
 397    [S/MIME] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
 398             2633, June 1999.
 399
 400    [XMLDSIG]Eastlake, D., et. al, "(Extensible Markup Language) XML
 401             Signature Syntax and Processing", RFC 3275, March 2002.
 402
 403    [TLSSign]Hajjeh, I., Serhrouchni, A., "Integrating a signature
 404             module in SSL/TLS, ICETEÆ2004, ACM/IEEE, First
 405             International Conference on E-Business and
 406             Telecommunication Networks, Portugal, August 2004.
 407
 408    [RFC2828]Shirey, R., "Internet Security Glossary", RFC 2828, May
 409             2000.
 410
 411 Author's Addresses
 412
 413    Ibrahim Hajjeh
 414    ENST
 415    46 rue Barrault
 416    75013 Paris               Phone: NA
 417    France                    Email: Ibrahim.Hajjeh@enst.fr
 418
 419    Ahmed serhrouchni
 420    ENST
 421    46 rue Barrault
 422    75013 Paris               Phone: NA
 423    France                    Email: Ahmed.serhrouchni@enst.fr
 424
 425    Mohamad Badra
 426    UQAM University
 427    Montreal (Quebec)         Phone: NA
 428    Canada                    Email: Mohamad.Badra@uqam.ca
 429
 430    Omar Cherkaoui
 431    UQAM University
 432    Montreal (Quebec)         Phone: NA
 433    Canada                    Email: Omar.Cherkaoui@uqam.ca
 434
 435    Acknowledgements
 436
 437    The authors would like to thank Eric Rescorla for discussions and
 438    comments on the design of TLS Sign.
 439
 440    Intellectual Property Statement
 441
 442    The IETF takes no position regarding the validity or scope of any
 443    Intellectual Property Rights or other rights that might be claimed
 444    to pertain to the implementation or use of the technology described
 445
 446
 447 Hajjeh, et. al.       Informational - Expires June 2005        [Page 8]
 448 INTERNET-DRAFT                   TLS Sign                  January 2005
 449
 450    in this document or the extent to which any license under such
 451    rights might or might not be available; nor does it represent that
 452    it has made any independent effort to identify any such rights.
 453    Information on the IETF's procedures with respect to rights in IETF
 454    Documents can be found in BCP 78 and BCP 79.
 455
 456    Copies of IPR disclosures made to the IETF Secretariat and any
 457    assurances of licenses to be made available, or the result of an
 458    attempt made to obtain a general license or permission for the use
 459    of such proprietary rights by implementers or users of this
 460    specification can be obtained from the IETF on-line IPR repository
 461    at http://www.ietf.org/ipr.
 462
 463    The IETF invites any interested party to bring to its attention any
 464    copyrights, patents or patent applications, or other proprietary
 465    rights that may cover technology that may be required to implement
 466    this standard. Please address the information to the IETF at ietf-
 467    ipr@ietf.org.
 468
 469    Disclaimer of Validity
 470
 471    This document and the information contained herein are provided on
 472    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 473    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 474    INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
 475    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 476    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 477    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 478
 479    Copyright Statement
 480
 481    Copyright (C) The Internet Society (2004). This document is subject
 482    to the rights, licenses and restrictions contained in BCP 78, and
 483    except as set forth therein, the authors retain all their rights.
 484
 485    Acknowledgment
 486
 487    Funding for the RFC Editor function is currently provided by the
 488    Internet Society.
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503 Hajjeh, et. al.       Informational - Expires June 2005        [Page 9]
 504