doc/protocol/draft-salowey-tls-ticket-02.txt

   1
   2 TLS Working Group                                             J. Salowey
   3 Internet-Draft                                                   H. Zhou
   4 Expires: August 23, 2005                                   Cisco Systems
   5                                                                P. Eronen
   6                                                                    Nokia
   7                                                            H. Tschofenig
   8                                                                  Siemens
   9                                                        February 19, 2005
  10
  11
  12             TLS Session Resumption without Server-Side State
  13                     draft-salowey-tls-ticket-02.txt
  14
  15 Status of this Memo
  16
  17    This document is an Internet-Draft and is subject to all provisions
  18    of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
  19    author represents that any applicable patent or other IPR claims of
  20    which he or she is aware have been or will be disclosed, and any of
  21    which he or she become aware will be disclosed, in accordance with
  22    RFC 3668.
  23
  24    Internet-Drafts are working documents of the Internet Engineering
  25    Task Force (IETF), its areas, and its working groups.  Note that
  26    other groups may also distribute working documents as
  27    Internet-Drafts.
  28
  29    Internet-Drafts are draft documents valid for a maximum of six months
  30    and may be updated, replaced, or obsoleted by other documents at any
  31    time.  It is inappropriate to use Internet-Drafts as reference
  32    material or to cite them other than as "work in progress."
  33
  34    The list of current Internet-Drafts can be accessed at
  35    http://www.ietf.org/ietf/1id-abstracts.txt.
  36
  37    The list of Internet-Draft Shadow Directories can be accessed at
  38    http://www.ietf.org/shadow.html.
  39
  40    This Internet-Draft will expire on August 23, 2005.
  41
  42 Copyright Notice
  43
  44    Copyright (C) The Internet Society (2005).
  45
  46 Abstract
  47
  48    This document describes a mechanism which enables the TLS server to
  49    resume sessions and avoid keeping per-client session state.  The TLS
  50
  51
  52
  53 Salowey, et al.          Expires August 23, 2005                [Page 1]
  54 \f
  55 Internet-Draft      Stateless TLS Session Resumption       February 2005
  56
  57
  58    server encapsulates the session state into a ticket and forwards it
  59    to the client.  The client can subsequently resume a session using
  60    the obtained ticket.  This mechanism makes use of new TLS handshake
  61    messages and TLS hello extensions.
  62
  63 Table of Contents
  64
  65    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  66    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
  67    3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  68      3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
  69      3.2   Format of SessionTicket TLS extension  . . . . . . . . . .  5
  70      3.3   Format of NewSessionTicket handshake message . . . . . . .  5
  71    4.  Sample ticket construction . . . . . . . . . . . . . . . . . .  6
  72    5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
  73      5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . .  8
  74      5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . .  8
  75      5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . .  8
  76      5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . .  8
  77    6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
  78    7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
  79    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  80      8.1   Normative References . . . . . . . . . . . . . . . . . . .  9
  81      8.2   Informative References . . . . . . . . . . . . . . . . . .  9
  82        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
  83        Intellectual Property and Copyright Statements . . . . . . . . 11
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109 Salowey, et al.          Expires August 23, 2005                [Page 2]
 110 \f
 111 Internet-Draft      Stateless TLS Session Resumption       February 2005
 112
 113
 114 1.  Introduction
 115
 116    This document defines a way to resume a TLS session without requiring
 117    session-specific state at the TLS server.  This mechanism may be used
 118    with any TLS ciphersuite.  The mechanism makes use of TLS extensions
 119    defined in [RFC3546] and defines a new TLS message type.
 120
 121    This mechanism is useful in the following types of situations
 122       (1) servers that handle a large number of transactions from
 123       different users
 124       (2) servers that desire to cache sessions for a long time
 125       (3) ability to load balance requests across servers
 126       (4) embedded servers with little memory
 127
 128 2.  Terminology
 129
 130    Within this document the term 'ticket' refers to a cryptographically
 131    protected data structure which is created by the server and consumed
 132    by the server to rebuild session specific state.
 133
 134    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 135    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 136    document are to be interpreted as described in [RFC2119].
 137
 138 3.  Protocol
 139
 140 3.1  Overview
 141
 142    The client indicates that it supports this mechanism by including an
 143    empty SessionTicket TLS extension in the ClientHello message.
 144
 145    If the server wants to use this mechanism, it stores its session
 146    state (such as ciphersuite and master secret) to a ticket that is
 147    encrypted and integrity-protected by a key known only to the server.
 148    The ticket is distributed to the client using the NewSessionTicket
 149    TLS handshake message.  This message is sent during the TLS handshake
 150    before the ChangeCipherSpec message after the server has verified the
 151    client's Finished message.
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165 Salowey, et al.          Expires August 23, 2005                [Page 3]
 166 \f
 167 Internet-Draft      Stateless TLS Session Resumption       February 2005
 168
 169
 170          Client                                               Server
 171
 172          ClientHello                   -------->
 173         (empty SessionTicket extension)
 174                                                          ServerHello
 175                                                         Certificate*
 176                                                   ServerKeyExchange*
 177                                                  CertificateRequest*
 178                                       <--------      ServerHelloDone
 179          Certificate*
 180          ClientKeyExchange
 181          CertificateVerify*
 182          [ChangeCipherSpec]
 183          Finished                     -------->
 184                                                   NewSessionTicket
 185                                                   [ChangeCipherSpec]
 186                                       <--------             Finished
 187          Application Data             <------->     Application Data
 188
 189    The client caches this ticket along with the master secret, session
 190    ID and other parameters associated with the current session.  When
 191    the client wishes to resume the session, it includes a SessionTicket
 192    TLS extension in the SessionTicket extension within ClientHello
 193    message.  The server then verifies that the ticket has not been
 194    tampered with, decrypts the contents, and retrieves the session state
 195    from the contents of the ticket and uses this state to resume the
 196    session.  Since separate fields in the request are used for the
 197    session ID and the ticket standard stateful session resume can
 198    co-exist with the ticket based session resume described in this
 199    specification.
 200
 201
 202          ClientHello
 203          (SessionTicket extension)      -------->
 204                                                           ServerHello
 205                                                    [ChangeCipherSpec]
 206                                        <--------             Finished
 207          [ChangeCipherSpec]
 208          Finished                      -------->
 209          Application Data              <------->     Application Data
 210
 211    Since the ticket is typically interpreted by the same server or group
 212    of servers that created it, the exact format of the ticket does not
 213    need to be the same for all implementations.  A sample ticket format
 214    is given in Section 4.  If the server cannot or does not want to
 215    honor the ticket then it can initiate a full handshake with the
 216    client.
 217
 218
 219
 220
 221 Salowey, et al.          Expires August 23, 2005                [Page 4]
 222 \f
 223 Internet-Draft      Stateless TLS Session Resumption       February 2005
 224
 225
 226    It is possible that the session ticket and master session key could
 227    be delivered through some out of band mechanism.  This behavior is
 228    beyond the scope of the document and would need to be described in a
 229    separate specification.
 230
 231 3.2  Format of SessionTicket TLS extension
 232
 233    The format of the ticket is an opaque structure used to carry session
 234    specific state information.
 235
 236
 237       struct {
 238           opaque ticket<0..2^16-1>;
 239       } SessionTicket;
 240
 241
 242 3.3  Format of NewSessionTicket handshake message
 243
 244    This message is sent during the TLS handshake before the
 245    ChangeCipherSpec message after the server has verified the client's
 246    Finished message.
 247
 248
 249       struct {
 250           HandshakeType msg_type;
 251           uint24 length;
 252           select (HandshakeType) {
 253               case hello_request:       HelloRequest;
 254               case client_hello:        ClientHello;
 255               case server_hello:        ServerHello;
 256               case certificate:         Certificate;
 257               case server_key_exchange: ServerKeyExchange;
 258               case certificate_request: CertificateRequest;
 259               case server_hello_done:   ServerHelloDone;
 260               case certificate_verify:  CertificateVerify;
 261               case client_key_exchange: ClientKeyExchange;
 262               case finished:            Finished;
 263               case new_session_ticket:  NewSessionTicket; /* NEW */
 264           } body;
 265       } Handshake;
 266
 267
 268       struct {
 269           opaque ticket<0..2^16-1>;
 270       } NewSessionTicket;
 271
 272
 273
 274
 275
 276
 277 Salowey, et al.          Expires August 23, 2005                [Page 5]
 278 \f
 279 Internet-Draft      Stateless TLS Session Resumption       February 2005
 280
 281
 282 4.  Sample ticket construction
 283
 284    This section describes one possibility how the ticket could be
 285    constructed, other implementations are possible.
 286
 287    The server uses two keys, one 128-bit key for AES encryption and one
 288    128-bit key for HMAC-SHA1.
 289
 290    The ticket is structured as follows:
 291
 292       struct {
 293           uint32 key_version;
 294           opaque iv[16]
 295           opaque encrypted_state<0..2^16-1>;
 296           opaque mac[20];
 297       } ExampleTicket;
 298
 299    Here key_version identifies a particular set of keys.  One
 300    possibility is to generate new random keys every time the server is
 301    started, and use the timestamp as the key version.  The same
 302    mechanisms known from a number of other protocols can be reused for
 303    this purpose.
 304
 305    The actual state information in encrypted_state is encrypted using
 306    128-bit AES in CBC mode with the given IV.  The MAC is calculated
 307    using HMAC-SHA1 over key_version (4 octets) and IV (16 octets),
 308    followed by the contents of the encrypted_state field (without the
 309    length).
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333 Salowey, et al.          Expires August 23, 2005                [Page 6]
 334 \f
 335 Internet-Draft      Stateless TLS Session Resumption       February 2005
 336
 337
 338       struct {
 339           ProtocolVersion protocol_version;
 340           SessionID session_id;
 341           CipherSuite cipher_suite;
 342           CompressionMethod compression_method;
 343           opaque master_secret[48];
 344           ClientIdentity client_identity;
 345           uint32 timestamp;
 346       } ExampleStatePlaintext;
 347
 348       enum {
 349          anonymous(0),
 350          certificate_based(1)
 351      } ExampleClientAuthenticationType;
 352
 353       struct {
 354           ExampleClientAuthenticationType client_authentication_type;
 355           select (ExampleClientAuthenticationType) {
 356               case anonymous: struct {};
 357               case certificate_based:
 358                   ASN.1Cert certificate_list<0..2^24-1>;
 359           }
 360        } ExampleClientIdentity;
 361
 362    The structure ExampleStatePlaintext stores the TLS session state
 363    including the SessionID and the master_secret.  The timestamp within
 364    this structure allows the TLS server to expire tickets.  To cover the
 365    authentication and key exchange protocols provided by TLS the
 366    ExampleClientIdentity structure contains the authentication type of
 367    the client used in the initial exchange (see
 368    ExampleClientAuthenticationType).  To offer the TLS server with the
 369    same capabilities for authentication and authorization a certificate
 370    list is included in case of public key based authentication.  The TLS
 371    server is therefore able to inspect a number of different attributes
 372    within these certificates.  A specific implementation might choose to
 373    store a subset of this information.  Other authentication mechanism
 374    such as Kerberos or pre-shared keys would require different client
 375    identity data.
 376
 377 5.  Security Considerations
 378
 379    This section addresses security issues related to the usage of a
 380    ticket.  Tickets must be sufficiently authenticated and encrypted to
 381    prevent modification or eavesdropping by an attacker.  Several
 382    attacks described below will be possible if this is not carefully
 383    done.
 384
 385    Implementations should take care to ensure that the processing of
 386
 387
 388
 389 Salowey, et al.          Expires August 23, 2005                [Page 7]
 390 \f
 391 Internet-Draft      Stateless TLS Session Resumption       February 2005
 392
 393
 394    tickets does not increase the chance of denial of serve as described
 395    below.
 396
 397 5.1  Invalidating Sessions
 398
 399    The TLS specification requires that TLS sessions be invalidated when
 400    errors occur.  [CSSC] discusses the security implications of this in
 401    detail.  In the analysis in this paper, failure to invalidate
 402    sessions does not pose a security risk.  This is because the TLS
 403    handshake uses a non-reversible function to derive keys for a session
 404    so information about one session does not provide an advantage to
 405    attack the master secret or a different session.  If a session
 406    invalidation scheme is used the implementation should verify the
 407    integrity of the ticket before using the contents to invalidate a
 408    session to ensure an attacker cannot invalidate a chosen session.
 409
 410 5.2  Stolen Tickets
 411
 412    An eavesdropper or man-in-the-middle may obtain the ticket and
 413    attempt to use the ticket to establish a session with the server,
 414    however since the ticket is encrypted and the attacker does not know
 415    the secret key a stolen key does not help an attacker resume a
 416    session.  A TLS server MUST use strong encryption and integrity
 417    protection for the ticket to prevent an attacker from using a brute
 418    force mechanism to obtain the tickets contents.
 419
 420 5.3  Forged Tickets
 421
 422    A malicious user could forge or alter a ticket in order to resume a
 423    session, to extend its lifetime, to impersonate as another user or
 424    gain additional privileges.  This attack is not possible if the
 425    ticket is protected using a strong integrity protection algorithm
 426    such as a keyed HMAC.
 427
 428 5.4  Denial of Service Attacks
 429
 430    An adversary could store or forge a large number of tickets to send
 431    to the TLS server for verification.  To minimize the possibility of a
 432    denial of service the verification of the ticket should be
 433    lightweight (e.g., using efficient symmetric key cryptographic
 434    algorithms).
 435
 436 6.  Acknowledgments
 437
 438    The authors would like to thank the following people for their help
 439    with this document: Eric Rescorla, Nancy Cam-Winget and David McGrew
 440
 441    [RFC2712] describes a mechanism for using Kerberos ([RFC1510]) in TLS
 442
 443
 444
 445 Salowey, et al.          Expires August 23, 2005                [Page 8]
 446 \f
 447 Internet-Draft      Stateless TLS Session Resumption       February 2005
 448
 449
 450    ciphersuites, which helped inspire the use of tickets to avoid server
 451    state.  [EAP-FAST] makes use of a similar mechanism to avoid
 452    maintaining server state for the cryptographic tunnel.  [AURA97] also
 453    investigates the concept of stateless sessions.  [CSSC] describes a
 454    solution that is very similar to the one described in this document
 455    and gives a detailed analysis of the security considerations
 456    involved.
 457
 458 7.  IANA considerations
 459
 460    Needs a TLS extension number (for including the ticket in client
 461    hello), and HandshakeType number (for delivering the ticket to the
 462    client).
 463
 464 8.  References
 465
 466 8.1  Normative References
 467
 468    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 469               Requirement Levels", March 1997.
 470
 471    [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
 472               and T. Wright, "Transport Layer Security (TLS)
 473               Extensions", RFC 3546, June 2003.
 474
 475    [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 476               RFC 2246, January 1999.
 477
 478 8.2  Informative References
 479
 480    [AURA97]   Aura, T. and P. Nikander, "Stateless Connections",
 481               Proceedings of the First International Conference on
 482               Information and Communication Security (ICICS '97) , 1997.
 483
 484    [CSSC]     Shacham, H., Boneh, D. and E. Rescorla, "Client Side
 485               Caching for TLS",
 486               URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf,
 487               2002.
 488
 489    [EAP-FAST]
 490               Cam-Winget, N., McGrew, D., Salowey, J. and H. Zhou, "EAP
 491               Flexible Authentication via Secure Tunneling (EAP-FAST)",
 492               Internet-Draft work-in-progress, February 2004.
 493
 494    [RFC1510]  Kohl, J. and C. Neuman, "The Kerberos Network
 495               Authentication Service (V5)", RFC 1510, September 1993.
 496
 497    [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
 498
 499
 500
 501 Salowey, et al.          Expires August 23, 2005                [Page 9]
 502 \f
 503 Internet-Draft      Stateless TLS Session Resumption       February 2005
 504
 505
 506               Suites to Transport Layer Security (TLS)", RFC 2712,
 507               October 1999.
 508
 509
 510 Authors' Addresses
 511
 512    Joseph Salowey
 513    Cisco Systems
 514    2901 3rd Ave
 515    Seattle, WA  98121
 516    US
 517
 518    Email: jsalowey@cisco.com
 519
 520
 521    Hao Zhou
 522    Cisco Systems
 523    4125 Highlander Parkway
 524    Richfield, OH  44286
 525    US
 526
 527    Email: hzhou@cisco.com
 528
 529
 530    Pasi Eronen
 531    Nokia Research Center
 532    P.O. Box 407
 533    FIN-00045 Nokia Group
 534    Finland
 535
 536    Email: pasi.eronen@nokia.com
 537
 538
 539    Hannes Tschofenig
 540    Siemens
 541    Otto-Hahn-Ring 6
 542    Munich, Bayern  81739
 543    Germany
 544
 545    Email: Hannes.Tschofenig@siemens.com
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557 Salowey, et al.          Expires August 23, 2005               [Page 10]
 558 \f
 559 Internet-Draft      Stateless TLS Session Resumption       February 2005
 560
 561
 562 Intellectual Property Statement
 563
 564    The IETF takes no position regarding the validity or scope of any
 565    Intellectual Property Rights or other rights that might be claimed to
 566    pertain to the implementation or use of the technology described in
 567    this document or the extent to which any license under such rights
 568    might or might not be available; nor does it represent that it has
 569    made any independent effort to identify any such rights.  Information
 570    on the procedures with respect to rights in RFC documents can be
 571    found in BCP 78 and BCP 79.
 572
 573    Copies of IPR disclosures made to the IETF Secretariat and any
 574    assurances of licenses to be made available, or the result of an
 575    attempt made to obtain a general license or permission for the use of
 576    such proprietary rights by implementers or users of this
 577    specification can be obtained from the IETF on-line IPR repository at
 578    http://www.ietf.org/ipr.
 579
 580    The IETF invites any interested party to bring to its attention any
 581    copyrights, patents or patent applications, or other proprietary
 582    rights that may cover technology that may be required to implement
 583    this standard.  Please address the information to the IETF at
 584    ietf-ipr@ietf.org.
 585
 586
 587 Disclaimer of Validity
 588
 589    This document and the information contained herein are provided on an
 590    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 591    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 592    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 593    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 594    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 595    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 596
 597
 598 Copyright Statement
 599
 600    Copyright (C) The Internet Society (2005).  This document is subject
 601    to the rights, licenses and restrictions contained in BCP 78, and
 602    except as set forth therein, the authors retain all their rights.
 603
 604
 605 Acknowledgment
 606
 607    Funding for the RFC Editor function is currently provided by the
 608    Internet Society.
 609
 610
 611
 612
 613 Salowey, et al.          Expires August 23, 2005               [Page 11]
 614 \f