--- /dev/null
+\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
\ No newline at end of file
projects / thirdparty / gnutls.git / commitdiff
