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

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