summaryrefslogtreecommitdiff
path: root/doc/protocol/draft-hajjeh-tls-sign-04.txt
diff options
context:
space:
mode:
authorSimon Josefsson <simon@josefsson.org>2007-12-17 12:14:02 +0100
committerSimon Josefsson <simon@josefsson.org>2007-12-17 12:14:02 +0100
commita826c1d4451e69b66a565bc1b090f07cfcfac0e8 (patch)
treedad85ba5a6c44cc220e5bcc62f32a0e1331bfd01 /doc/protocol/draft-hajjeh-tls-sign-04.txt
parent1fb66b3738da50cbecd7327cd354765ff2a123cb (diff)
downloadgnutls-a826c1d4451e69b66a565bc1b090f07cfcfac0e8.tar.gz
Add.
Diffstat (limited to 'doc/protocol/draft-hajjeh-tls-sign-04.txt')
-rw-r--r--doc/protocol/draft-hajjeh-tls-sign-04.txt647
1 files changed, 647 insertions, 0 deletions
diff --git a/doc/protocol/draft-hajjeh-tls-sign-04.txt b/doc/protocol/draft-hajjeh-tls-sign-04.txt
new file mode 100644
index 0000000000..3dc77cbcee
--- /dev/null
+++ b/doc/protocol/draft-hajjeh-tls-sign-04.txt
@@ -0,0 +1,647 @@
+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]
+