From: Simon Josefsson Date: Thu, 12 Aug 2004 20:34:40 +0000 (+0000) Subject: Add. X-Git-Tag: gnutls_1_1_15~24 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=802ab612c66d5ed63f307263aa87a97f5d52f1db;p=thirdparty%2Fgnutls.git Add. --- diff --git a/doc/protocol/draft-badra-tls-key-exchange-00.txt b/doc/protocol/draft-badra-tls-key-exchange-00.txt new file mode 100644 index 0000000000..76f8148835 --- /dev/null +++ b/doc/protocol/draft-badra-tls-key-exchange-00.txt @@ -0,0 +1,556 @@ +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 + + + +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