doc/protocol/draft-badra-tls-express-00.txt

   1 Internet Engineering Task Force                                M. Badra
   2 INTERNET DRAFT                                           A. Serhrouchni
   3 Expires December 2004                                          P. Urien
   4                                                            ENST Telecom
   5                                                               June 2004
   6
   7
   8                                 TLS Express
   9                      <draft-badra-tls-express-00.txt>
  10
  11
  12 Status of this Memo
  13
  14    By submitting this Internet-Draft, I certify that any applicable
  15    patent or other IPR claims of which I am aware have been disclosed,
  16    or will be disclosed, and any of which I become aware will be
  17    disclosed, in accordance with RFC 3668.
  18
  19    This document is an Internet-Draft and is in full conformance with
  20    all provisions of Section 10 of RFC2026.
  21
  22    Internet-Drafts are working documents of the Internet Engineering
  23    Task Force (IETF), its areas, and its working groups. Note that
  24    other groups may also distribute working documents as Internet
  25    Drafts.
  26
  27    Internet-Drafts are draft documents valid for a maximum of six
  28    months and may be updated, replaced, or obsoleted by other documents
  29    at any time. It is inappropriate to use Internet-Drafts as reference
  30    material or to cite them other than as "work in progress."
  31
  32    The list of current Internet-Drafts can be accessed at
  33    http://www.ietf.org/ietf/1id-abstracts.txt
  34
  35    The list of Internet-Draft Shadow Directories can be accessed at
  36    http://www.ietf.org/shadow.html
  37
  38 Copyright Notice
  39
  40    Copyright (C) The Internet Society (2004).  All Rights Reserved.
  41
  42 Abstract
  43
  44    This document defines a new extension that may be used to add Pre
  45    Shared Key authentication functionality to TLS. It is based on the
  46    TLS abbreviated handshake and it provides the ability to share a
  47    session key for data encryption.
  48
  49
  50
  51
  52
  53
  54
  55 Badra, et. al.     Informational - Expires December 2004       [Page 1]
  56
  57 INTERNET-DRAFT                  TLS express                   June 2004
  58
  59 1. Introduction
  60
  61    [TLSEXT] describes extensions that MAY be used to add functionality
  62    to Transport Layer Security (TLS). It provides both generic
  63    extension mechanisms for the TLS handshake client and server hellos,
  64    and specific extensions using these generic mechanisms.
  65
  66    In this document, we propose a new extension to add pre shared key
  67    functionality to TLS handshake protocol. It is based on [PIMRC] and
  68    uses the TLS session resume logic. It provides the client and the
  69    server the ability to share a session key for data encryption and to
  70    authenticate each other by sending a correct finished message,
  71    parties thus prove that they know the correct pre shared key.
  72
  73 1.1. Requirements language
  74
  75    The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document
  76    are to be interpreted as described in RFC-2119.
  77
  78 2. Extension Type
  79
  80    The TLS extensions [TLSEXT] specify extensions using the following
  81    generic mechanism:
  82
  83        struct {
  84            ExtensionType extension_type;
  85            opaque extension_data<0.. 2^16-1>;
  86           } Extension;
  87
  88    where "extension_type" identifies the particular extension type, and
  89    "extension_data" contains information specific to the particular
  90    extension type.
  91
  92        enum {
  93            server_name(0), max_fragment_length(1),
  94            client_certificate_url(2), trusted_ca_keys(3),
  95            truncated_hmac(4), status_request(5), srp(6), cert_type(7),
  96            ticket_identity(8), (65535)
  97            } ExtensionType;
  98
  99    A new value, "ticket_identity(8)", has been added to the enumerated
 100    ExtensionType defined in [TLSEXT]. This value is used as the
 101    extension number for the extensions in the client hello message.
 102    This new extension type will be used for shared key type
 103    negotiation.
 104
 105    The "extension_data" field of the ticket extension SHALL contain:
 106
 107          opaque ticket_to_enter<1..2^16-1>
 108
 109
 110
 111 Badra, et. al.           Expires - December 2004               [Page 2]
 112
 113 INTERNET-DRAFT                  TLS express                   June 2004
 114
 115    where ticket_to_enter is the shared key identifier and/or data
 116    related to the shared key.
 117
 118    Note that the secret key MAY be delivered by a trusted third party.
 119    In [PIMRC], we gave a method for this topic. By the way, the secret
 120    MAY be also issued directly by the server. Kerberos [KERBEROS] is a
 121    particular example for this issue.
 122
 123 2.1. Handshake
 124
 125    In order to indicate the support of the shared key type, the client
 126    will include an extension of type "ticket_identity" to the extended
 127    client hello message.
 128
 129    When the server receives an extended client hello containing the
 130    "ticket_identity" extension, it checks its ticket_identity's
 131    database for a match. If a match is found, the server calculates the
 132    finished and waits for the client one.
 133
 134    If the server understood the client hello extension but does not
 135    recognize the ticket identity, it SHOULD send a "decode_error"
 136    alert. Alternatively and like in [TLSSRP], if the server wishes to
 137    hide the fact that the ticket_identity does not have a match, the
 138    server MAY simulate the protocol as if a ticket existed, but then
 139    reject the client's finished message with a bad_record_mac alert, as
 140    if the shared key was incorrect.
 141
 142    The handshake exchange is given in the following diagram:
 143
 144          ClientHello            -------->
 145       (ticket_identity)                    ServerHello
 146                                            ChangeCipherSpec
 147                                 <--------  Finished
 148          ChangeCipherSpec
 149          Finished               -------->
 150
 151 3. Security considerations
 152
 153    The server MUST stock the shared key in a secure and protected
 154    manner in order to prevent attackers from retrieving its value.
 155
 156 4. IANA Considerations
 157
 158    To be continued.
 159
 160
 161
 162
 163
 164
 165
 166 Badra, et. al.           Expires - December 2004               [Page 3]
 167
 168 INTERNET-DRAFT                  TLS express                   June 2004
 169
 170 5. References
 171
 172 5.1  Normative References
 173
 174    [TLSEXT]  Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J.
 175              and Wright, T., "Transport Layer Security (TLS)
 176              Extensions", RFC 3546, June 2003
 177
 178    [KERBEROS]Kohl J. and C. Neuman, "The Kerberos Network
 179              Authentication Service (V5)", RFC 1510, September 1993.
 180
 181 5.2  Informative References
 182
 183    [TLSSRP]  Taylor, D., Wu, T., Mavroyanopoulos, N., and Perrin,
 184              T., "Using SRP for TLS Authentication",
 185              draft-ietf-tls-srp-07.txt, Internet Draft (work in
 186              progress), June 2004.
 187
 188    [PIMRC]   Badra, M., and Serhrouchni, A., "A new secure session
 189              exchange key protocol for wireless communications", the
 190              14 IEEE Proceedings on Personal, Indoor and Mobile Radio
 191              Communications, PIMRC 2003, Volume: 3, 7-10 Sept. 2003,
 192              Pages:2765 - 2769. An extracted text could be found at
 193              http://www.infres.enst.fr/~badra/pimrc2003.pdf
 194
 195 6. Author's Addresses
 196
 197    Mohamad Badra
 198    ENST
 199    46 rue Barrault
 200    75634 Paris               Phone: NA
 201    France                    Email: Mohamad.Badra@enst.fr
 202
 203    Ahmed Serhrouchni
 204    ENST
 205    46 rue Barrault
 206    75634 Paris               Phone: NA
 207    France                    Email: Ahmed.Serhrouchni@enst.fr
 208
 209    Pascal Urien
 210    ENST
 211    46 rue Barrault
 212    75634 Paris               Phone: NA
 213    France                    Email: Pascal.Urien@enst.fr
 214
 215
 216
 217
 218
 219
 220
 221 Badra, et. al.           Expires - December 2004               [Page 4]
 222
 223 INTERNET-DRAFT                  TLS express                   June 2004
 224
 225    Intellectual Property Statement
 226
 227    The IETF takes no position regarding the validity or scope of any
 228    Intellectual Property Rights or other rights that might be claimed
 229    to pertain to the implementation or use of the technology described
 230    in this document or the extent to which any license under such
 231    rights might or might not be available; nor does it represent that
 232    it has made any independent effort to identify any such rights.
 233    Information on the IETF's procedures with respect to rights in IETF
 234    Documents can be found in BCP 78 and BCP 79.
 235
 236    Copies of IPR disclosures made to the IETF Secretariat and any
 237    assurances of licenses to be made available, or the result of an
 238    attempt made to obtain a general license or permission for the use
 239    of such proprietary rights by implementers or users of this
 240    specification can be obtained from the IETF on-line IPR repository
 241    at http://www.ietf.org/ipr.
 242
 243    The IETF invites any interested party to bring to its attention any
 244    copyrights, patents or patent applications, or other proprietary
 245    rights that may cover technology that may be required to implement
 246    this standard. Please address the information to the IETF at
 247    ietf-ipr@ietf.org.
 248
 249    Disclaimer of Validity
 250
 251    This document and the information contained herein are provided on
 252    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 253    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 254    INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
 255    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 256    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 257    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 258
 259    Copyright Statement
 260
 261    Copyright (C) The Internet Society (2004). This document is subject
 262    to the rights, licenses and restrictions contained in BCP 78, and
 263    except as set forth therein, the authors retain all their rights.
 264
 265    Acknowledgment
 266
 267    Funding for the RFC Editor function is currently provided by the
 268    Internet Society.
 269
 270
 271
 272
 273
 274
 275
 276
 277 Badra, et. al.           Expires - December 2004               [Page 5]