Internet Engineering Task Force                                M. Badra 
INTERNET DRAFT                                           A. Serhrouchni 
Expires August 2005                                            P. Urien 
                                                           ENST Telecom 
                                                          February 2005 
 
 
                                TLS Express 
                     <draft-badra-tls-express-01.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. 
    
   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]