--- /dev/null
+Internet Engineering Task Force M. Badra
+INTERNET DRAFT O. Cherkaoui
+ UQAM University
+ I. Hajjeh
+Expires: 8, February 2004 A. Serhrouchni
+ ENST, Paris
+ August, 10 2004
+
+
+ Pre-Shared-Key key Exchange methods for TLS
+ <draft-badra-tls-key-exchange-00.txt>
+
+
+Status of this Memo
+
+ 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.
+
+ This Internet-Draft will expire on February 8, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document specifies new key exchange methods for Transport Layer
+ Security protocol to support authentication based on pre installed
+ key and to allow anonymous exchanges, identity protection And
+ Perfect Forward Secrecy.
+
+
+
+
+
+
+Badra, et. al. Expires February 2005 [Page 1]
+
+INTERNET-DRAFT PSK key Exchange methods for TLS August 2004
+
+1. Introduction
+
+ Transport Layer Security (TLS) [TLS] is an authentication protocol
+ that establishes a secure channel, as well as mutual authentication,
+ protected cipher suite negotiation and key exchange between two
+ entities. TLS handshake uses certificates and PKI for mutual
+ authentication and key exchange. In many cases, a TLS public-key-
+ based handshake is unnecessary; especially for closed environments
+ or for clients pre-configured. This document specifies how to
+ establish a TLS session using symmetric keys.
+
+ Although several Internet Draft authors ([TLSPSK], [TLSSK],
+ [TSLEXP], etc) propose the pre shared key mechanism, none of them
+ provides neither anonymous exchanges and identity protection against
+ eavesdropping nor Perfect Forward Secrecy (PFS). On the other hand,
+ some approaches like [ISATLS], propose a radical change to the TLS
+ protocol. Other like [SPTLS], propose Password-based cipher suite
+ for TLS Handshake scheme.
+
+ This document specifies new key exchange methods for TLS for pre
+ shared key. The advantageous use of the pre shared key regarding the
+ Public Key Infrastructure (PKI) based certificates is that the pre
+ shared key reduces the cryptographic operations, the messages load
+ and the number of round trips.
+
+1.1. Requirements language
+
+ The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document
+ are to be interpreted as described in RFC-2119.
+
+2. Changes to the TLS Handshake protocol
+
+ TLS [TLS] defines the client key exchange message that is always
+ sent by the client. With this message [TLS], the premaster secret is
+ set, either though direct transmission of the RSA-encrypted secret,
+ or by the transmission of Diffie-Hellman parameters which will allow
+ each side to agree upon the same premaster secret. The structure of
+ this message depends on which key exchange method has been selected.
+ The actual TLS standard defines two methods using RSA or
+ Diffie_Hellman algorithms.
+
+ The rest of this document describes the changes to the handshake
+ messages contents when the pre shared key is being used.
+
+2.1. Client Hello
+
+ In order to negotiate and to signal to the server that the client
+ wishes to use a pre_shared_key key exchange method, the client MAY
+ include an extension of type "psk_key_exchange (9)" in the extended
+ client hello, such is defined in [TLSEXT]. The "extension_data"
+
+
+Badra, et. al. Expires - February 2005 [Page 2]
+
+INTERNET-DRAFT PSK key Exchange methods for TLS August 2004
+
+ field of the psk key exchange extension SHALL contain
+ "PSKKeyExchangeMethod" where:
+
+ struct {
+ PSKMethod psk_methods_list<0..2^16-1>;
+ } PSKKeyExchangeMethod;
+
+ struct {
+ MethodType method_type;
+ Select (method_type) {
+ case rsa_psk : RSAPSK
+ case diffie_hellman_psk : DHPSK
+ } method;
+ } PSKMethod;
+
+ enum { rsa_psk(0), diffie_hellmen_psk(1), (255) } MethodType;
+
+ Here, "PSKKeyExchangeMethod" provides a list of PSK key exchange
+ methods that the client supports.
+
+2.3. Server Key Exchange
+
+ The format of ServerKeyExchange is as follow:
+
+ struct {
+ select (KeyExchangeAlgorithm) {
+ case diffie_hellman:
+ ServerDHParams params;
+ Signature signed_params;
+ case rsa:
+ ServerRSAParams params;
+ Signature signed_params;
+ case rsa_psk: /*NEW/
+ ServerRSAParamsPSK params;
+ Signature signed_params; /*optional/
+ case diffie_hellman_psk: /*NEW/
+ ServerDHParamsPSK params;
+ Signature signed_params;/*optional/
+ };
+ } ServerKeyExchange;
+
+ rsa_psk and diffie_hellman_psk cases are respectively identical to
+ rsa and diffie_hellman cases that are definied in [TLS].
+
+ Note that because the pre_shared_key SHOULD protect entities against
+ man-in-the-middle attack (see section 2.4), the server MAY not sign
+ its Diffie_Hellman parameters and thus the signed_params field MAY
+ be omitted. For more information, see security considerations
+ section.
+
+
+
+Badra, et. al. Expires - February 2005 [Page 3]
+
+INTERNET-DRAFT PSK key Exchange methods for TLS August 2004
+
+2.2. Client Key Exchange
+
+ This document adds two new key exchange methods to the enumerated
+ KeyExchangeAlgorithm originally defined in [TLS].
+
+ enum {
+ rsa, diffie_hellman, rsa_psk, diffie_hellman_psk
+ } KeyExchangeAlgorithm;
+
+ Thus, the structure of the client key exchange becomes as follow:
+
+ struct {
+ select (KeyEchangeAlgorithm){
+ case rsa: EncryptedPreMasterSecret;
+ case diffie_hellman: ClientDiffieHellmanPublic;
+ case rsa_psk: EncryptPreMasterSecretPSK; /*NEW/
+ case diffie_hellman_psk: ClientDiffieHellmanPublicPSK; /*NEW/
+ } exchange_key;
+ } ClientKeyExchange;
+
+ 2.2.1. rsa_psk encrypted premaster secret message
+
+ If rsa_psk is being used for key agreement, the client generates a
+ 30-byte random value, concatenates it with the pre shared key
+ identity, encrypts the result (premaster secret) using the server
+ public key and sends it in an encrypted premaster secret message.
+
+ Structure of the premaster secret:
+
+ struct {
+ ProtocolVersion client_version;
+ opaque random[30];
+ opaque psk_identity<1..2^16-1>;
+ opaque pad[16-psk_identity.length];
+ } PreMasterSecret;
+
+ struct { public-key-encrypted PreMasterSecret pre_master_secret;
+ } EncryptedPreMasterSecretPSK;
+
+ For interoperation issues, this document uses the same definition
+ used in [TLSSRP]. Thus, the psk_identity SHALL be UTF-8 encoded
+ Unicode, where the psk_identity is the pre shared key identifier.
+
+ If the psk_identity is less than 16 bytes in length, the premaster
+ secret will be padded to obtain 46 bytes. For example, if the
+ psk_identity length is 13 bytes, then the last three bytes of the
+ premaster secret will be 0x03 0x03 0x03. This mechanism will allow
+ the server to extract the psk_identity from the premaster secret.
+
+
+
+
+Badra, et. al. Expires - February 2005 [Page 4]
+
+INTERNET-DRAFT PSK key Exchange methods for TLS August 2004
+
+ 2.2.2. diffie_hellman_psk encrypted premaster secret message
+
+ Because the client does not use any certificate, its value Yc needs
+ to be sent. As a result, the case implicit MAY be omitted.
+
+ struct {
+ select (PublicValueEncoding) {
+ case implicit: struct { };
+ case explicit: opaque dh_Yc<1..2^16-1>;
+ } dh_public;
+ opaque psk_identity<1..2^16-1>;
+ } ClientDiffieHellmanPublicPSK;
+
+ dh_Yc
+ The client's Diffie-Hellman public value (Yc).
+
+ psk_identity
+ The pre shared key identifier.
+
+ The psk_identity helps the client to indicate which key it wants to
+ use and the server to retrieve the corresponding pre shared key
+ value, if exists. When using a Diffie-Hellman based key exchange
+ method, the psk_identity is sent in the clear.
+
+2.4. Computing the master secret
+
+ This document uses the same mechanism defined in [TLS] for keys
+ computation and calculation, except the master secret key. It
+ generates the master secret by applying the PRF on the premaster
+ secret XOR pre_shared_key value instead of the premaster secret:
+
+ master_secret = PRF(pre_master_secret XOR pre_shared_key,
+ "master_secret",
+ ClientHello.random + ServerHello.random)[0..47];
+
+ As a result, if the server uses a static private key and if this key
+ is compromised, the intruder must have the pre_shared_key to decrypt
+ old sessions.
+
+ On the other hand, if either the client or the server calculates an
+ incorrect premaster_secret XOR pre_shared_key value, the finished
+ messages will fail to decrypt properly and the other party will
+ return a bad_record_mac alert. This MAY happen when the server does
+ not send its certificate and that a man-in-the-middle intercepts the
+ session exchanges and sends its public key instead of the server
+ public key.
+
+
+
+
+
+
+Badra, et. al. Expires - February 2005 [Page 5]
+
+INTERNET-DRAFT PSK key Exchange methods for TLS August 2004
+
+2.5. Error Alerts
+
+ Three new TLS error alerts are defined by this document (This
+ section is inspired by [TLSSRP]):
+
+ a) "unknown_psk_key_exchange" (integer) - this alert MAY be sent by
+ a server that does not support any PSK key exchange methods sent
+ by the client. This alert is always a warning. Upon receiving
+ this alert, the client MAY send a new hello message on the same
+ connection using another TLS authentication methods.
+
+ b) "unknown_psk_identity" (integer) - this alert MAY be sent by a
+ server that receives an unknown ticket identity. This alert is
+ always fatal.
+
+ c) "missing_psk_identity" (integer) - this alert MAY be sent by a
+ server that would like to select an offered PSK key exchange
+ method, if the MethodType extension is absent from the client's
+ hello message. This alert is always a warning. Upon receiving
+ this alert, the client MAY send a new hello message on the same
+ connection, this time including the MethodType extension.
+
+2.6. Handshake
+
+ In order to indicate the support of the shared key type, the client
+ adds the extension "psk_key_exchange (9)" to its extended hello
+ message.
+
+ When the server receives an extended client hello message, it
+ replies by its hello that contains the following attributes:
+ Protocol Version, Random, Session ID, Cipher Suite, and Compression
+ Method.
+
+ If the server is able to agree on a key exchange method using the
+ pre shared key, it will send its server key exchange message that
+ contains the selected method. In this case, the Certificate message
+ MAY be omitted from the response.
+
+ If the server does not support any PSK key exchange methods sent by
+ the client, the server MAY abort the handshake with a
+ unknown_key_exchange alert.
+
+ Now the server will send the server hello done message, indicating
+ that the hello-message phase of the handshake is completed.
+
+ The client send its client key exchange message. The content of this
+ message depends on the method selected between the client hello and
+ the server key exchange messages.
+
+
+
+Badra, et. al. Expires - February 2005 [Page 6]
+
+INTERNET-DRAFT PSK key Exchange methods for TLS August 2004
+
+ The handshake exchange is given in the following diagram:
+
+ ClientHello -------->
+ (MethodType) ServerHello
+ Certificate*
+ ServerKeyExchange
+ <-------- ServerHelloDone
+ ClientKeyExchange
+ ChangeCipherSpec
+ Finished -------->
+ ChangeCipherSpec
+ <-------- Finished
+
+ * Indicates an optional message which is not always sent.
+
+3. Security considerations
+
+ The server MUST stock the shared key in a secure and protected
+ manner in order to prevent attackers from retrieving its value.
+
+ During the handshake phase, the server MAY send its certificate. The
+ certificate's use protects entities against man-in-the-middle
+ attack.
+
+ If the server certificate is omitted, the client and the server
+ authenticate each other via the finished messages. In fact, the
+ finished value is computed using the master_secret calculated during
+ the establishment session and the pre shared key. Thus, if the
+ client is intercepted by a bogus server, this later will be
+ detectable by the client during the finished phase. As a result, no
+ third party can calculate the same finished value without having the
+ correct pre_shared_key. Instead, the third party MAY discover the
+ pre shared key identity sent in the client key exchange message.
+
+ When using a Diffie-Hellman based PSK key exchange method, the
+ client sends its psk_identity in the clear. In order to avoid this
+ issue, the client could first open a conventional anonymous and then
+ renegotiate a PSK key exchange method with the handshake protected
+ by the first connection. Another solution MAY be done using the
+ pseudonym management.
+
+3.1. Key management with non-human support
+
+ In the case where the client does not enter his credentials manually
+ during the session establishment and that he does not need to
+ remember them, then he can stock them on a secure token (e.g.
+ smartcard) or in a local file. In this case, the server and the
+ client MAY update the pre shared key value after each session has
+ been formed. In this case, the both MAY add a seed to their
+ credentials entries. By this method, the client's support and the
+
+
+Badra, et. al. Expires - February 2005 [Page 7]
+
+INTERNET-DRAFT PSK key Exchange methods for TLS August 2004
+
+ server calculate the seed and update the pre shared key as following
+ (in the session i):
+
+ seed(0) is a random on 16 bytes.
+
+ seed(i) = P_MD5(seed(i-1) XOR psk_identity,
+ "seed" +
+ ClientHello.random + ServerHello.random)[0..16];
+
+ psk(i) = PRF(psk(i-1) XOR premaster secret(i), "pre shared key",
+ ServerHello.random + ClientHello.random)[0..48];
+
+ With this mechanism, the psk_identity remains unchanged. However,
+ when the client connect to the server, it sends the seed (seed(i-1)
+ for session i) instead of the psk_identity. The rest of the protocol
+ is unchangeable. This SHALL ensure, among other, PFS and anonymity.
+
+4. IANA Considerations
+
+ To be specified.
+
+5. Acknowledgment
+
+ This document has been inspired by [TLS], [TLSSRP] and [TLSPSK].
+ Thus, it reused extracts of these documents.
+
+6. References
+
+6.1. Normative References
+
+ [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J.
+ and Wright, T., "Transport Layer Security (TLS)
+ Extensions", RFC 3546, June 2003.
+
+ [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
+ RFC 2246, November 1998.
+
+ [ISATLS] Hajjeh, I., and Serhrouchni, A., "ISAKMP Handshake for
+ SSL/TLS", IEEE GLOBECOM'03, Vol. 3, San Francisco, USA,
+ 1-5 December 2003, Pages: 1481-1485.
+
+ [SPTLS] Steiner, Michael, et. al., "Secure Password-Based Cipher
+ Suite for TLS", ACM Transaction on Information and System
+ Security, Vol. 4, No. 2, May 2001, Pages 134-157.
+
+6.2. Informative References
+
+ [TLSSRP] Taylor, D., Wu, T., Mavroyanopoulos, N., and Perrin,
+ T., "Using SRP for TLS Authentication",
+ draft-ietf-tls-srp-07.txt, Internet Draft (work in
+ progress), June 2004.
+Badra, et. al. Expires - February 2005 [Page 8]
+
+INTERNET-DRAFT PSK key Exchange methods for TLS August 2004
+
+ [TLSPSK] Eronen, P., and Tschofenig, H., "Pre-Shared Key
+ Ciphersuites for Transport Layer Security (TLS)",
+ draft-eronen-tls-psk-00.txt, Internet Draft (work in
+ progress), August 2004.
+
+ [TLSSK] Gutmann, P.,"Use of Shared Keys in the TLS Protocol",
+ draft-ietf-tls-sharedkeys-02.txt, Internet Draft
+ (expired), October 2003.
+
+ [TSLEXP] Badra, M., Serhrouchni, A., and Urien, P., "TLS Express",
+ draft-badra-tls-express-00.txt, Internet Draft (work in
+ progress), June 2004.
+
+6. Author's Addresses
+
+ Mohamad Badra
+ ENST Telecom
+ 46 rue Barrault
+ 75634 Paris Phone: NA
+ France Email: Mohamad.Badra@enst.fr
+
+ Omar Cherkaoui
+ UQAM University
+ Montreal (Quebec) Phone: NA
+ Canada Email: cherkaoui.omar@uqam.ca
+
+ Ibrahim Hajjeh
+ ENST Telecom
+ 46 rue Barrault
+ 75634 Paris Phone: NA
+ France Email: Ibrahim.Hajjeh@enst.fr
+
+ Ahmed Serhrouchni
+ ENST Telecom
+ 46 rue Barrault
+ 75634 Paris Phone: NA
+ France Email: Ahmed.Serhrouchni@enst.fr
+
+ 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 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
+Badra, et. al. Expires - February 2005 [Page 9]
+
+INTERNET-DRAFT PSK key Exchange methods for TLS August 2004
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Badra, et. al. Expires - February 2005 [Page 10]
\ No newline at end of file
projects / thirdparty / gnutls.git / commitdiff
