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

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