diff options
Diffstat (limited to 'doc/protocol/draft-hajjeh-tls-sign-04.txt')
| -rw-r--r-- | doc/protocol/draft-hajjeh-tls-sign-04.txt | 647 |
1 files changed, 0 insertions, 647 deletions
diff --git a/doc/protocol/draft-hajjeh-tls-sign-04.txt b/doc/protocol/draft-hajjeh-tls-sign-04.txt deleted file mode 100644 index 3dc77cbcee..0000000000 --- a/doc/protocol/draft-hajjeh-tls-sign-04.txt +++ /dev/null @@ -1,647 +0,0 @@ -TLS Working Group I. Hajjeh -Internet Draft INEOVATION - M. Badra - LIMOS Laboratory -Intended status: Experimental December 15, 2007 -Expires: June 2008 - - - - TLS Sign - draft-hajjeh-tls-sign-04.txt - - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - 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 - - This Internet-Draft will expire on June 15, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -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. - - - - -Hajjeh & Badra Expires June 2008 [Page 1] - -Internet-Draft TLS Sign December 2007 - - - 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. - -Table of Contents - - - 1. Introduction...................................................2 - 1.1. Conventions used in this document.........................3 - 2. TLS Sign overview..............................................3 - 2.1. tls sign on off protocol..................................6 - 2.1.1. bad_sign alert.......................................7 - 2.2. Storing signed data.......................................7 - 3. Security Considerations........................................9 - 4. IANA Considerations............................................9 - 5. References.....................................................9 - 5.1. Normative References......................................9 - 5.2. Informative References...................................10 - Author's Addresses...............................................10 - Appendix Changelog...............................................10 - Intellectual Property Statement..................................11 - Disclaimer of Validity...........................................11 - -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. - - - -Hajjeh & Badra Expires June 2008 [Page 2] - -Internet-Draft TLS Sign December 2007 - - - 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. - -1.1. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC-2119 [RFC2119]. - -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; - SignType sign_type<2..2^16-1>; - } SignatureRequest; - - enum { - ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255); - } SignMethod; - - - -Hajjeh & Badra Expires June 2008 [Page 3] - -Internet-Draft TLS Sign December 2007 - - - uint8 SignType[2]; - - The client initiates the TLS Sign module by sending the - ExtendedClientHello including the 'signature' extension. This - extension contains: - - - the SignType carrying the type of the non repudiation proof. It can - have one of these two values: - - SignType non_repudiation_with_proof_of_origin = { 0x00, 0x01 }; - SignType non_repudiation_without_proof_of_origin = { 0x00, 0x02 }; - - - the ContentFormat carrying the format of signed data. It can be - PKCS7 [PKCS7], S/MIME [SMIME] or XMLDSIG [XMLDSIG] - - ContentFormat PKCS7 = { 0x00, 0xA1 }; - ContentFormat SMIME = { 0x00, 0xA2 }; - ContentFormat XMLDSIG = { 0x00, 0xA3 }; - - o if the value of the ContentFormat is PKCS7, then the PKCS7 - Content_type is of type signed-data. - - o if the value of the ContentFormat is S/MIME, then S/MIME - Content_type is of type SignedData - - o if the value of the ContentFormat is XMLDSIG, then XMLDSIG - signatureMethod algorithms. - - - the SignMethod carrying the signature method that is used to sign - the application data (e.g. X509 authentication certificate). - - SignMethod X509 = { 0x00, 0xB1 }; - - 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. - - The client and the server MAY use the same certificates used by the - Handshake protocol. Several cases are possible: - - - 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 - (upon reception of tls_sign_on_off protocol message not followed by a - - -Hajjeh & Badra Expires June 2008 [Page 4] - -Internet-Draft TLS Sign December 2007 - - - certificate with a type equals to ExtendedServerHello.sign_method) - 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 - SHOULD 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 using the TLS - certificate request message (e.g., an RSA or a DSS signature-capable - certificate). If the client does not send a certificate during the - TLS Handshake, the server MUST close the TLS session by sending a - fatal error in the case where the client sends a tls_sign_on_off - protocol message not followed by a certificate with a type equals to - ExtendedServerHello.sign_method. - - - The client or the server MAY use a certificate different to these - being used by TLS Handshake. This MAY happen when the server agrees - in getting non-repudiation data from the client and that the type of - the client certificate used by TLS Handshake and the type selected by - the server from the list in ExtendedClientHello.sign_method are - different, or when the ExtendedServerHello.cipher_suite does not - require client and/or server certificates. In these cases, the client - or the server sends a new message called certificate_sign, right - after sending the tls_sign_on_off protocol messages. The new message - contains the sender's certificate in which the type is the same type - selected by the server from the list in - ExtendedClientHello.sign_method. The certificate_sign is therefore - used to generate signed data. It is defined as follows: - - opaque ASN.1Cert<2^24-1>; - - struct { - ASN.1Cert certificate_list<1..2^24-1>; - } CertificateSign; - - The certificate_list, as defined in [TLS], is a sequence (chain) of - certificates. The sender's certificate MUST come first in the list. - If the server has no interest in getting non-repudiation data from - the client, it replays with an ordinary TLS ServerHello or return a - handshake failure alert and close the connection [TLS]. - - Client Server - - ClientHello --------> - ServerHello - Certificate* - - -Hajjeh & Badra Expires June 2008 [Page 5] - -Internet-Draft TLS Sign December 2007 - - - ServerKeyExchange* - CertificateRequest* - <-------- ServerHelloDone - Certificate* - ClientKeyExchange - CertificateVerify* - ChangeCipherSpec - Finished --------> - ChangeCipherSpec - <-------- Finished - TLSSignOnOff <-------------------------> TLSSignOnOff - CertificateSign* <----------------------> CertificateSign* - (Signed) Application Data <-----> (Signed) Application Data - - * Indicates optional or situation-dependent messages that are not - always sent. - -2.1. tls sign on off protocol - - To manage the generation of evidence, new sub-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. This message can be sent at any time after the TLS - session has been established. Thus, no man in the middle can replay - or inject this message. It consists of a single byte of value 1 - (tls_sign_on) or 0 (tls_sign_off). - - enum { - change_cipher_spec(20), alert(21), handshake(22), - application_data(23), tls_sign(TBC), (255) - } ContentType; - - struct { - enum { tls_sign_off(0), tls_sign_on(1), (255) } type; - } TLSSignOnOff; - - The tls_sign_on_off message is sent by the client and/or server to - notify the receiving party that subsequent records will carry data - signed under the negotiated parameters. - - Note: TLSSignOnOff is an independent TLS Protocol content type, and - is not actually a TLS handshake message. - - 2.1.1 TLS sign packet format - - - - - -Hajjeh & Badra Expires June 2008 [Page 6] - -Internet-Draft TLS Sign December 2007 - - - This document defines a new packet format that encapsulates signed - data, the TLSSigntext. 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 | Flag | Version | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length | Signed Data ... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Content-Type - - Same as TLSPlaintext.type. - - Flag - - 0 1 2 3 4 5 6 7 8 - +-+-+-+-+-+-+-+-+ - |A R R R R R R R| - +-+-+-+-+-+-+-+-+ - - A = acknowledgement of receipt - 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 - TLSSigntext packet with the bit A set to 1 (acknowledgement of - receipt). This helps the receiver of the acknowledgment of receipt in - storing the data-field for later use (see section 2.2). The data - field of that message contains the digest of the whole data receiver - by the generator of the acknowledgement of receipt. The digest is - signed before sending the result to the other side. - -2.1.1. bad_sign alert - - This alert is returned if a record is received with an incorrect - signature. This message is always fatal. - -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 - - - -Hajjeh & Badra Expires June 2008 [Page 7] - -Internet-Draft TLS Sign December 2007 - - - 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 [RFC4949]. RFC 4949 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: - - -------- -------- -------- -------- -------- . -------- - 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. - - -Hajjeh & Badra Expires June 2008 [Page 8] - -Internet-Draft TLS Sign December 2007 - - - 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. - -3. Security Considerations - - Security issues are discussed throughout this memo. - -4. IANA Considerations - - This document defines a new TLS extension "signature", assigned the - value TBD from the TLS ExtensionType registry defined in [TLSEXT]. - - This document defines one TLS ContentType: tls_sign(TBD). This - ContentType value is assigned from the TLS ContentType registry - defined in [TLS]. - - This document defines a new handshake message, certificate_sign, - whose value is to be allocated from the TLS HandshakeType registry - defined in [TLS]. - - The bad_sign alert that is defined in this document is assigned to - the TLS Alert registry defined in [TLS]. - -5. References - -5.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [TLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version - 1.1", RFC 4346, April 2005. - - -Hajjeh & Badra Expires June 2008 [Page 9] - -Internet-Draft TLS Sign December 2007 - - - [TLSEXT] Blake-Wilson, S., et. al., "Transport Layer Security TLS) - Extensions", RFC 4366, April 2006. - - [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message - Syntax Standard," version 1.5, November 1993. - - [SMIME] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC - 3851, July 2004. - - [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML - Signature Syntax and Processing", RFC 3275, March 2002. - -5.2. Informative References - - [RFC4949] Shirey, R., "Internet Security Glossary", RFC 4949, August - 2007. - - [TLSSIGN] Hajjeh, I., Serhrouchni, A., "Integrating a signature - module in SSL/TLS, ICETE2004., ACM/IEEE, First - International Conference on E-Business and - Telecommunication Networks, Portugal, August 2004. - -Author's Addresses - - Ibrahim Hajjeh - INEOVATION - France - - Email: hajjeh@ineovation.com - - - Mohamad Badra - LIMOS Laboratory - UMR6158, CNRS - France - - Email: badra@isima.fr - - -Appendix Changelog - - Changes from -01 to -02: - - o Add an IANA section. - - o Small clarifications to section 2. - - o Add the bad_sign alert and the certificate_sign message. - - -Hajjeh & Badra Expires June 2008 [Page 10] - -Internet-Draft TLS Sign December 2007 - - - Changes from -00 to -01: - - o Clarifications to the format of the signed data in Section 2. - - o Small clarifications to TLS SIGN negotiation in Section 2. - - o Added Jacques Demerjian and Mohammed Achemlal as - contributors/authors. - -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 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 procedures with respect to rights in RFC 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, THE IETF TRUST 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 IETF Trust (2007). - - - -Hajjeh & Badra Expires June 2008 [Page 11] - -Internet-Draft TLS Sign December 2007 - - - 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 & Badra Expires June 2008 [Page 12] - |