diff options
Diffstat (limited to 'doc/protocol/draft-hajjeh-tls-sign-00.txt')
| -rw-r--r-- | doc/protocol/draft-hajjeh-tls-sign-00.txt | 504 |
1 files changed, 0 insertions, 504 deletions
diff --git a/doc/protocol/draft-hajjeh-tls-sign-00.txt b/doc/protocol/draft-hajjeh-tls-sign-00.txt deleted file mode 100644 index 6fc44075ad..0000000000 --- a/doc/protocol/draft-hajjeh-tls-sign-00.txt +++ /dev/null @@ -1,504 +0,0 @@ - -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] - |