--- /dev/null
+
+
+
+Internet Engineering Task Force M. Badra
+INTERNET DRAFT LIMOS Laboratory
+Updates: 4785, 4279
+
+Expires: November 2007 July 2007
+
+ ECDHE_PSK Ciphersuites for TLS
+ <draft-badra-ecdhe-tls-psk-00.txt>
+
+
+Status
+
+ 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 November 2007.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document updates RFC 4785 and RFC 4279 and specifies a set of
+ ciphersuites that use an Elliptic Curve Diffie-Hellman exchange
+ authenticated with a pre-shared key. These ciphersuites provides
+ Perfect Forward Secrecy. It specifies as well one authentication-
+ only ciphersuites (with no encryption). This ciphersuite is useful
+ when authentication and integrity protection is desired, but
+ confidentiality is not needed or not permitted.
+
+ The reader is expected to become familiar with RFC 4785 and RFC 4279
+ prior to studying this document.
+
+
+Badra Expires November 2007 [Page 1] \f
+
+Internet-Draft ECDHE_PSK Ciphersuites for TLS July 2007
+
+
+1. Introduction
+
+ RFC 4279 specifies ciphersuites for supporting TLS using pre-shared
+ symmetric keys and they (a) use only symmetric key operations for
+ authentication, (b) use a Diffie-Hellman exchange authenticated
+ with a pre-shared key, or (c) combines public key authentication of
+ the server with pre-shared key authentication of the client.
+
+ RFC 4785 specifies authentication-only ciphersuites (with no
+ encryption).
+
+ This document specifies a set of ciphersuites that use an Elliptic
+ Curve Diffie-Hellman exchange authenticated with a pre-shared key.
+ These ciphersuites provides Perfect Forward Secrecy. It specifies as
+ well one authentication-only ciphersuites (with no encryption). This
+ ciphersuite is useful when authentication and integrity protection
+ is desired, but confidentiality is not needed or not permitted.
+
+2. Updating RFC4279
+
+ The new ciphersuites proposed here match the ciphersuites defined in
+ [RFC4279], except that they use an Elliptic Curve Diffie-Hellman
+ exchange [RFC4492] authenticated with a pre-shared key. They are
+ defined as follow:
+
+ CipherSuite Key Exchange Cipher Hash
+
+ TLS_ECDHE_PSK_WITH_RC4_128_SHA ECDHE_PSK RC4_128 SHA
+ TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA ECDHE_PSK 3DES_EDE_CBC SHA
+ TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA ECDHE_PSK AES_128_CBC SHA
+ TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA ECDHE_PSK AES_256_CBC SHA
+
+ When these ciphersuites are used, the ServerKeyExchange and
+ ClientKeyExchange messages also include the Diffie-Hellman
+ parameters. The PSK identity and identity hint fields have the same
+ meaning as in the previous section (note that the ServerKeyExchange
+ message is always sent, even if no PSK identity hint is provided).
+
+ The format of the ServerKeyExchange and ClientKeyExchange messages
+ is shown below.
+
+ struct {
+ select (KeyExchangeAlgorithm) {
+ /* other cases for rsa, diffie_hellman, etc. */
+ case ec_diffie_hellman_psk: /* NEW */
+ opaque psk_identity_hint<0..2^16-1>;
+ ServerECDHParams params;
+ };
+ } ServerKeyExchange;
+
+
+Badra Expires November 2007 [Page 2] \f
+
+Internet-Draft ECDHE_PSK Ciphersuites for TLS July 2007
+
+
+ struct {
+ select (KeyExchangeAlgorithm) {
+ /* other cases for rsa, diffie_hellman, etc. */
+ case ec_diffie_hellman_psk: /* NEW */
+ opaque psk_identity<0..2^16-1>;
+ ClientECDiffieHellmanPublic public;
+ } exchange_keys;
+ } ClientKeyExchange;
+
+ The premaster secret is formed as follows. First, perform the
+ Elliptic Curve Diffie-Hellman computation in the same way as for
+ other Diffie-Hellman-based ciphersuites in [TLS1.0] or [TLS1.1]. Let
+ Z be the value produced by this computation. Concatenate a uint16
+ containing the length of Z (in octets), Z itself, a uint16
+ containing the length of the PSK (in octets), and the PSK itself.
+
+ This corresponds to the general structure for the premaster secrets
+ (see Note 1 in Section 2 in RFC 4279) in [RFC4279], with
+ "other_secret" containing Z:
+
+ struct {
+ opaque other_secret<0..2^16-1>;
+ opaque psk<0..2^16-1>;
+ };
+
+ Here "other_secret" comes from the Elliptic Curve Diffie-Hellman
+ exchange (ECDHE_PSK).
+
+3. Updating RFC4785
+
+ The new ciphersuite proposed here match the ciphersuites defined in
+ [RFC4785], except that it uses an Elliptic Curve Diffie-Hellman
+ exchange authenticated with a pre-shared key
+
+ CipherSuite Key Exchange Cipher Hash
+
+ TLS_ECDHE_PSK_WITH_NULL_SHA ECDHE_PSK NULL SHA
+
+4. Security Considerations
+
+ The security considerations described throughout [TLS1.0],
+ [TLSv1.1], RFC 4785 and RFC 4279 apply here as well.
+
+5. IANA Considerations
+
+ This document defines the following new ciphersuites, whose values
+ are to be assigned from the TLS Cipher Suite registry defined in
+ [TLS1.1].
+
+ CipherSuite TLS_ECDHE_PSK_WITH_RC4_128_SHA = { 0xXX, 0xXX };
+
+Badra Expires November 2007 [Page 3] \f
+
+Internet-Draft ECDHE_PSK Ciphersuites for TLS July 2007
+
+
+ CipherSuite TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA = { 0xXX, 0xXX };
+ CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA = { 0xXX, 0xXX };
+
+6. References
+
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [TLS1.0] T., Dierks, C., Allen, "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+ [TLS1.1] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
+ RFC 4346, April 200P.
+
+ [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
+ for Transport Layer Security (TLS)", RFC 4279, December
+ 2005.
+
+ [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK)
+ Ciphersuites with NULL Encryption for Transport Layer
+ Security (TLS)", RFC 4785, January 2007.
+
+ [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,
+ Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
+ Suites for Transport Layer Security (TLS)", RFC 4492, May
+ 2006.
+
+Acknowledgements
+
+ The authors would like to thank Bodo Moeller for comments on the
+ document.
+
+Author's Addresses
+
+ Mohamad Badra
+ LIMOS Laboratory - UMR (6158), CNRS
+ France Email: badra@isima.fr
+
+ Full Copyright Statement
+
+ Copyright (C) The IETF Trust (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.
+
+Badra Expires November 2007 [Page 4] \f
+
+Internet-Draft ECDHE_PSK Ciphersuites for TLS July 2007
+
+
+
+ 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.
+
+ Intellectual Property
+
+ 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.
+
+ Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Badra Expires November 2007 [Page 5] \f
\ No newline at end of file
--- /dev/null
+
+
+
+Internet Engineering Task Force I. Hajjeh
+ ESRGroups
+ M. Badra
+ LIMOS Laboratory
+
+Expires: November 2007 June, 2007
+
+ Credential Protection Ciphersuites for Transport Layer Security
+ <draft-hajjeh-tls-identity-protection-01.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 November 2007.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ TLS defines several ciphersuites providing authentication, data
+ protection and session key exchange between two communicating
+ entities. Some of these ciphersuites are used for completely
+ anonymous key exchange, in which neither party is authenticated.
+ However, they are vulnerable to man-in-the-middle attacks and are
+ therefore deprecated.
+
+ This document defines a set of ciphersuites to add client credential
+ protection to the Transport Layer Security (TLS) protocol.
+
+
+Hajjeh & Badra Expires November 2007 [Page 1] \f
+
+Internet-draft Credential protection Ciphersuites for TLS June 2007
+
+1. Introduction
+
+ 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.
+
+ TLS supports three authentication modes: authentication of both
+ parties, only server-side authentication, and anonymous key
+ exchange. For each mode, TLS specifies a set of ciphersuites.
+ However, anonymous ciphersuites are strongly discouraged because
+ they cannot prevent man-in-the-middle attacks.
+
+ Client credential protection may be established by changing the
+ order of the messages that the client sends after receiving
+ ServerHelloDone [CORELLA]. This is done by sending the
+ ChangeCipherSpec message before the Certificate and the
+ CertificateVerify messages and after the ClientKeyExchange message.
+ However, it requires a major change to TLS machine state as long as
+ a new TLS version.
+
+ Client credential protection may also be done through a DHE exchange
+ before establishing an ordinary handshake with identity information
+ [RESCORLA]. This wouldn't however be secure enough against active
+ attackers, which will be able to disclose the client's credentials
+ and wouldn't be favorable for some environments (e.g. mobile), due
+ to the additional cryptographic computations.
+
+ Client credential protection may be also possible, assuming that the
+ client permits renegotiation after the first server authentication.
+ However, this requires more cryptographic computations and augments
+ significantly the number of rounds trips.
+
+ Client credential protection may as well be realized by exchanging a
+ TLS extension that negotiates the symmetric encryption algorithm to
+ be used for client certificate encrypting/decrypting [EAPTLSIP].
+ This solution may suffer from interoperability issues related to TLS
+ Extensions, TLS 1.0 and TLS 1.1 implementations, as described in
+ [INTEROP].
+
+ This document defines a set of ciphersuites to add client credential
+ protection to TLS protocol. Client credential protection is provided
+ by symmetrically encrypting the client certificate with a key
+ derived from the SecurityParameters.master_secret,
+ SecurityParameters.server_random and
+ SecurityParameters.client_random. The symmetric encryption algorithm
+ is set to the cipher algorithm of the ServerHello.cipher_suite.
+
+1.2. Requirements language
+
+
+
+
+Hajjeh & Badra Expires November 2007 [Page 2] \f
+
+Internet-draft Credential protection Ciphersuites for TLS June 2007
+
+ The key words "MUST", "MUST NOT" and "MAY" in this document are to
+ be interpreted as described in RFC-2119.
+
+2. TLS credential protection overview
+
+ This document specifies a set of ciphersuites for TLS. These
+ ciphersuites reuse existing key exchange algorithms that require
+ based-certificates authentication, and reuse also existing MAC,
+ stream and bloc ciphers algorithms from [TLS] and [TLSCTR],
+ [TLSECC], [TLSAES] and [TLSCAM]. Their names include the text "CP"
+ to refer to the client credential protection. An example is shown
+ below.
+
+ CipherSuite Key Exchange Cipher Hash
+
+ TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5 RSA RC4_40 MD5
+ TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA DHE AES_128_CBC SHA
+
+ If the client has not a certificate with a type appropriate for one
+ of the supported cipher key exchange algorithms or if the client
+ will not be able to send such a certificate, it MUST NOT include any
+ ciphersuite with client credential protection in the
+ ClientHello.cipher_suites.
+
+ If the server selects a ciphersuite with client credential
+ protection, the server MUST request a certificate from the client.
+
+ If the server selects one of the ciphersuites defined in this
+ document, the client MUST encrypt the Certificate and the
+ CertificateVerify messages using the symmetric algorithm selected by
+ the server from the list in ClientHello.cipher_suites and a key
+ derived from the SecurityParameters.master_secret. This key is the
+ same key used to encrypt data written by the client.
+
+ If a stream cipher encryption algorithm has been selected, the
+ client symmetrically encrypts Certificate and CertificateVerify
+ messages without any padding byte.
+
+ If a block cipher encryption algorithm has been selected, the client
+ uses an explicit IV and adds padding value to force the length of
+ the plaintext to be an integral multiple of the block cipher's block
+ length, as it is described in section 6.2.3.2 of [TLS1.1].
+
+ For DHE key exchange algorithm, the client always sends the
+ ClientKeyExchange message conveying its ephemeral DH public key Yc.
+
+ For ECDHE key exchange algorithm, the client always sends the
+ ClientKeyExchange message conveying its ephemeral ECDH public key
+ Yc.
+
+
+
+Hajjeh & Badra Expires November 2007 [Page 3] \f
+
+Internet-draft Credential protection Ciphersuites for TLS June 2007
+
+ Current TLS specifications note that if the client certificate
+ already contains a suitable DH or ECDH public key, then Yc is
+ implicit and does not need to be sent again and consequently, the
+ client key exchange message will be sent, but it MUST be empty.
+ Implementations of this document MUST send ClientKeyExchange message
+ but always carrying the client Yc, whatever the PublicValueEncoding
+ is implicit or explicit. Note that it is possible to correlate
+ sessions by the same client when DH or ECDH are in use.
+
+ Client Server
+
+ ClientHello -------->
+ ServerHello
+ Certificate
+ ServerKeyExchange*
+ CertificateRequest
+ <-------- ServerHelloDone
+ {Certificate}
+ ClientKeyExchange
+ {CertificateVerify}
+ [ChangeCipherSpec]
+ Finished -------->
+ [ChangeCipherSpec]
+ <-------- Finished
+ Application Data <-------> Application Data
+
+ * Indicates optional or situation-dependent messages that are not
+ always sent.
+ {} Indicates messages that are symmetrically encrypted.
+
+ The ciphersuites in Section 3 (CP_RSA Key Exchange Algorithm) use
+ RSA based certificates to mutually authenticate a RSA exchange with
+ the client credential protection.
+
+ The ciphersuites in Section 4 (CP_DHE and CP_DH Key Exchange
+ Algorithm) use DHE_RSA, DH_RSA, DHE_DSS or DH_DSS to mutually
+ authenticate a (Ephemeral) Diffie-Hellman exchange.
+
+ The ciphersuites in Section 5 (CP_ECDH and CP_ECDHE Key Exchange
+ Algorithms) use ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA or ECDHE_RSA to
+ mutually authenticate a (Ephemeral) EC Diffie-Hellman exchange.
+
+3. CP_RSA Key Exchange Algorithm
+
+ This section defines additional ciphersuites that use RSA based
+ certificates to authenticate a RSA exchange. These ciphersuites give
+ client credential protection.
+
+ CipherSuite Key Exchange Cipher Hash
+
+
+
+Hajjeh & Badra Expires November 2007 [Page 4] \f
+
+Internet-draft Credential protection Ciphersuites for TLS June 2007
+
+ TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5 RSA RC4_40 MD5
+ TLS_CP_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
+ TLS_CP_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
+ TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RSA RC2_CBC_40 MD5
+ TLS_CP_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
+ TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA RSA DES40_CBC_ SHA
+ TLS_CP_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
+ TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE SHA
+ TLS_CP_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
+ TLS_CP_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA
+ TLS_CP_RSA_WITH_AES_128_CTR_SHA RSA AES_128_CTR SHA
+ TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA RSA CAMELLIA_128_CBC SHA
+ TLS_CP_RSA_WITH_AES_256_CTR_SHA RSA AES_256_CTR SHA
+ TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA RSA CAMELLIA_256_CBC SHA
+
+4. CP_DHE and CP_DH Key Exchange Algorithms
+
+ This section defines additional ciphersuites that use DH and DHE as
+ key exchange algorithms, with RSA or DSS based certificates to
+ authenticate a (Ephemeral) Diffie-Hellman exchange. These
+ ciphersuites give client credential protection.
+
+ CipherSuite Key Exchange Cipher Hash
+
+ TLS_CP_DHE_DSS_WITH_DES_CBC_SHA DHE DES_CBC SHA
+ TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE 3DES_EDE_CBC SHA
+ TLS_CP_DHE_RSA_WITH_DES_CBC_SHA DHE DES_CBC SHA
+ TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE 3DES_EDE_CBC SHA
+ TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA DHE AES_128_CBC SHA
+ TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA DHE AES_128_CBC SHA
+ TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA DHE AES_256_CBC SHA
+ TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA DHE AES_256_CBC SHA
+ TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE CAMELLIA_128_CBC SHA
+ TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE CAMELLIA_128_CBC SHA
+ TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE CAMELLIA_256_CBC SHA
+ TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE CAMELLIA_256_CBC SHA
+ TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA DHE AES_128_CTR SHA
+ TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA DHE AES_128_CTR SHA
+ TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA DHE AES_256_CTR SHA
+ TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA DHE AES_256_CTR SHA
+ TLS_CP_DH_DSS_WITH_DES_CBC_SHA DH DES_CBC SHA
+ TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA DH 3DES_EDE_CBC SHA
+ TLS_CP_DH_RSA_WITH_DES_CBC_SHA DH DES_CBC SHA
+ TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA DH 3DES_EDE_CBC SHA
+ TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA DH AES_128_CBC SHA
+ TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA DH AES_128_CBC SHA
+ TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA DH AES_256_CBC SHA
+ TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA DH AES_256_CBC SHA
+
+
+
+
+Hajjeh & Badra Expires November 2007 [Page 5] \f
+
+Internet-draft Credential protection Ciphersuites for TLS June 2007
+
+5. CP_ECDH and CP_ECDHE Key Exchange Algorithm
+
+ This section defines additional ciphersuites that use ECDH and ECDHE
+ as key exchange algorithms, with RSA or ECDSA based certificates to
+ authenticate a (Ephemeral) ECDH exchange. These ciphersuites give
+ client credential protection.
+
+ CipherSuite Key Exchange Cipher Hash
+
+ TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA ECDH RC4_128_ SHA
+ TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ECDH 3DES_EDE_CBC SHA
+ TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA ECDH AES_128_CBC SHA
+ TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA ECDHE AES_256_CBC SHA
+ TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA ECDHE RC4_128 SHA
+ TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ECDHE 3DES_EDE_CBC SHA
+ TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ECDHE AES_128_CBC SHA
+ TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ECDHE AES_256_CBC SHA
+ TLS_CP_ECDH_RSA_WITH_RC4_128_SHA ECDH RC4_128 SHA
+ TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA ECDH 3DES_EDE_CBC SHA
+ TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA ECDH AES_256_CBC SHA
+ TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA ECDH AES_256_CBC SHA
+ TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA ECDHE RC4_128 SHA
+ TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ECDHE 3DES_EDE_CBC SHA
+ TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA ECDHE AES_256_CBC SHA
+ TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA ECDHE AES_256_CBC SHA
+
+6. Security Considerations
+
+ The security considerations described throughout [TLS], [DTLS],
+ [TLS1.1], [TLSAES], [TLSECC] and [TLSAES] apply here as well.
+
+7. IANA Considerations
+
+ This section provides guidance to the IANA regarding registration of
+ values related to the credential protection ciphersuites.
+
+ CipherSuite TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5 = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_RC4_128_MD5 = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_RC4_128_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_IDEA_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_DES_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_AES_128_CTR_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_AES_256_CTR_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0xXX,0xXX };
+
+
+Hajjeh & Badra Expires November 2007 [Page 6] \f
+
+Internet-draft Credential protection Ciphersuites for TLS June 2007
+
+ CipherSuite TLS_CP_DHE_DSS_WITH_DES_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_RSA_WITH_DES_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DH_DSS_WITH_DES_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DH_RSA_WITH_DES_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA= { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDH_RSA_WITH_RC4_128_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX };
+ CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX };
+
+ Note: For implementation and deployment facilities, it is helpful to
+ reserve a specific registry sub-range (minor, major) for credential
+ protection ciphersuites.
+
+8. References
+
+8.1. Normative References
+
+ [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+
+
+Hajjeh & Badra Expires November 2007 [Page 7] \f
+
+Internet-draft Credential protection Ciphersuites for TLS June 2007
+
+ RFC 2246, January 1999.
+
+ [TLS1.1] Dierks, T. and E. Rescorla, "The TLS Protocol Version
+ 1.1", RFC 4346, April 2005.
+
+ [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, April 2006.
+
+ [TLSCAM] Moriai, S., Kato, A., Kanda M., "Addition of Camellia
+ Cipher Suites to Transport Layer Security (TLS)",
+ RFC 4132, July 2005.
+
+ [TLSAES] Chown, P., "Advanced Encryption Standard (AES)
+ Ciphersuites for Transport Layer Security (TLS)",
+ RFC 3268, June 2002.
+
+ [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,
+ Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
+ Suites for Transport Layer Security (TLS)", RFC 4492, May
+ 2006
+
+ [TLSCTR] Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher
+ Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work
+
+8.1. Informative References
+
+ [RESCORLA] Rescorla, E., "SSL and TLS: Designing and Building Secure
+ Systems", Addison-Wesley, March 2001.
+
+ [CORELLA] Corella, F., "adding client identity protection to TLS",
+ message on ietf-tls@lists.certicom.com mailing list,
+ http://www.imc.org/ietf-tls/mail-archive/msg02004.html,
+ August 2000.
+
+ [INTEROP] Pettersen, Y., "Clientside interoperability
+ experiences for the SSL and TLS protocols", draft-ietf-
+ tls-interoperability-00 (work in progress), October 2006.
+ in progress), June 2006.
+
+ [EAPTLSIP] Urien, P. and M. Badra, "Identity Protection within EAP-
+ TLS",
+ draft-urien-badra-eap-tls-identity-protection-01.txt
+ (work in progress), October 2006.
+
+Author's Addresses
+
+ Ibrahim Hajjeh
+ ESRGroups, Security WG
+ France Email: Ibrahim.Hajjeh@esrgroups.org
+
+
+
+Hajjeh & Badra Expires November 2007 [Page 8] \f
+
+Internet-draft Credential protection Ciphersuites for TLS June 2007
+
+ Mohamad Badra
+ LIMOS Laboratory - UMR (6158), CNRS
+ France Email: badra@isima.fr
+
+ Full Copyright Statement
+
+ Copyright (C) The IETF Trust (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.
+
+ 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.
+
+ Intellectual Property
+
+ 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.
+
+ Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+Hajjeh & Badra Expires November 2007 [Page 9] \f
\ No newline at end of file
--- /dev/null
+
+
+
+Internet Engineering Task Force I. Hajjeh
+INTERNET DRAFT ESRGroups
+ M. Badra
+ LIMOS Laboratory
+
+Expires: November 2007 June 2007
+
+ TLS Sign
+ <draft-hajjeh-tls-sign-03.txt>
+
+
+Status
+
+ 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 November 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.
+
+ 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 & Badra Expires November 2007 [Page 1] \f
+INTERNET-DRAFT TLS Sign June 2007
+
+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.
+
+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
+
+
+Hajjeh & Badra Expires November 2007 [Page 2] \f
+INTERNET-DRAFT TLS Sign June 2007
+
+ 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;
+
+ 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 [S/MIME] 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 };
+
+
+Hajjeh & Badra Expires November 2007 [Page 3] \f
+INTERNET-DRAFT TLS Sign June 2007
+
+
+ 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 or MAY NOT 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 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;
+
+
+
+Hajjeh & Badra Expires November 2007 [Page 4] \f
+INTERNET-DRAFT TLS Sign June 2007
+
+ 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*
+ 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;
+
+
+Hajjeh & Badra Expires November 2007 [Page 5] \f
+INTERNET-DRAFT TLS Sign June 2007
+
+
+ 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
+
+ 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.3 bad_sign alert
+
+ This alert is returned if a record is received with an incorrect
+ signature. This message is always fatal.
+
+
+
+Hajjeh & Badra Expires November 2007 [Page 6] \f
+INTERNET-DRAFT TLS Sign June 2007
+
+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:
+
+ -------- -------- -------- -------- -------- --------
+ 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 November 2007 [Page 7] \f
+INTERNET-DRAFT TLS Sign June 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.
+
+Security Considerations
+
+ Security issues are discussed throughout this memo.
+
+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].
+
+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.
+
+ [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",
+
+
+Hajjeh & Badra Expires November 2007 [Page 8] \f
+INTERNET-DRAFT TLS Sign June 2007
+
+ 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, ICETE2004., 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
+ Engineering and Scientific Research Groups (ESRGroups)
+ 82 rue Baudricourt
+ 75013 Paris Phone: NA
+ France Email: Ibrahim.Hajjeh@esrgroups.org
+
+ Mohamad Badra
+ LIMOS Laboratory - UMR 6158, CNRS
+ France Email: badra@isima.fr
+
+ Acknowledgements
+
+ The authors would like to thank Eric Rescorla for discussions and
+ comments on the design of TLS Sign.
+
+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.
+
+ 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.
+
+ Full Copyright Statement
+
+
+
+Hajjeh & Badra Expires November 2007 [Page 9] \f
+INTERNET-DRAFT TLS Sign June 2007
+
+ Copyright (C) The IETF Trust (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.
+
+ 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.
+
+ Intellectual Property
+
+ 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.
+
+ Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+
+
+
+Hajjeh & Badra Expires November 2007 [Page 10] \f
\ No newline at end of file
projects / thirdparty / gnutls.git / commitdiff
