Internet Engineering Task Force M. Badra INTERNET DRAFT A. Serhrouchni Expires August 2005 P. Urien ENST Telecom February 2005 TLS Express 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. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a new extension that may be used to add Pre Shared Key authentication functionality to TLS. It is based on the TLS abbreviated handshake and it provides the ability to share a session key for data encryption. Badra, et. al. Informational [Page 1] INTERNET-DRAFT TLS express Fubruary 2005 1. Introduction [TLSEXT] describes extensions that MAY be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. In this document, we propose a new extension to add pre shared key functionality to TLS handshake protocol. It is based on [PIMRC] and uses the TLS session resume logic. It provides the client and the server the ability to share a session key for data encryption and to authenticate each other by sending a correct finished message, parties thus prove that they know the correct pre shared key. 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. Extension Type The TLS extensions [TLSEXT] specify extensions using the following generic mechanism: struct { ExtensionType extension_type; opaque extension_data<0.. 2^16-1>; } Extension; where "extension_type" identifies the particular extension type, and "extension_data" contains information specific to the particular extension type. enum { server_name(0), max_fragment_length(1), client_certificate_url(2), trusted_ca_keys(3), truncated_hmac(4), status_request(5), srp(6), cert_type(7), ticket_identity(8), (65535) } ExtensionType; A new value, "ticket_identity(8)", has been added to the enumerated ExtensionType defined in [TLSEXT]. This value is used as the extension number for the extensions in the client hello message. This new extension type will be used for shared key type negotiation. The "extension_data" field of the ticket extension SHALL contain: opaque ticket_to_enter<1..2^16-1> Badra, et. al. Informational [Page 2] INTERNET-DRAFT TLS express Fubruary 2005 where ticket_to_enter is the shared key identifier and/or data related to the shared key. Note that the secret key MAY be delivered by a trusted third party. In [PIMRC], we gave a method for this topic. By the way, the secret MAY be also issued directly by the server. Kerberos [KERBEROS] is a particular example for this issue. 2.1. Handshake In order to indicate the support of the shared key type, the client will include an extension of type "ticket_identity" to the extended client hello message. When the server receives an extended client hello containing the "ticket_identity" extension, it checks its ticket_identity's database for a match. If a match is found, the server calculates the finished and waits for the client one. If the server understood the client hello extension but does not recognize the ticket identity, it SHOULD send a "decode_error" alert. Alternatively and like in [TLSSRP], if the server wishes to hide the fact that the ticket_identity does not have a match, the server MAY simulate the protocol as if a ticket existed, but then reject the client's finished message with a bad_record_mac alert, as if the shared key was incorrect. The handshake exchange is given in the following diagram: ClientHello --------> (ticket_identity) ServerHello ChangeCipherSpec <-------- Finished ChangeCipherSpec Finished --------> 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. 4. IANA Considerations This document defines a new extension type to deliver the ticket. Badra, et. al. Informational [Page 3] INTERNET-DRAFT TLS express Fubruary 2005 5. References 5.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 [KERBEROS]Kohl J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. 5.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. [PIMRC] Badra, M., and Serhrouchni, A., "A new secure session exchange key protocol for wireless communications", the 14 IEEE Proceedings on Personal, Indoor and Mobile Radio Communications, PIMRC 2003, Volume: 3, 7-10 Sept. 2003, Pages:2765 - 2769. An extracted text could be found at http://www.infres.enst.fr/~badra/pimrc2003.pdf 6. Author's Addresses Mohamad Badra ENST 46 rue Barrault 75634 Paris Phone: NA France Email: Mohamad.Badra@enst.fr Ahmed Serhrouchni ENST 46 rue Barrault 75634 Paris Phone: NA France Email: Ahmed.Serhrouchni@enst.fr Pascal Urien ENST 46 rue Barrault 75634 Paris Phone: NA France Email: Pascal.Urien@enst.fr Badra, et. al. Informational [Page 4] INTERNET-DRAFT TLS express Fubruary 2005 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 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. Informational [Page 5]