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

   1
   2
   3
   4 Network Working Group                                         J. Salowey
   5 Internet-Draft                                                   H. Zhou
   6 Expires: February 2, 2006                                  Cisco Systems
   7                                                                P. Eronen
   8                                                                    Nokia
   9                                                            H. Tschofenig
  10                                                                  Siemens
  11                                                              August 2005
  12
  13
  14  Transport Layer Security Session Resumption without Server-Side State
  15                     draft-salowey-tls-ticket-04.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 February 2, 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 February 2, 2006                [Page 1]
  56 \f
  57 Internet-Draft      Stateless TLS Session Resumption         August 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 . . . . . . . . . . . . . . . . . . 10
  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 February 2, 2006                [Page 2]
 112 \f
 113 Internet-Draft      Stateless TLS Session Resumption         August 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 [I-D.ietf-tls-
 122    rfc3546bis] and 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 a
 146    SessionTicket TLS extension in the ClientHello message.  The
 147    extension will be empty if the client does not already possess a
 148    ticket for the server.
 149
 150    If the server wants to use this mechanism, it stores its session
 151    state (such as ciphersuite and master secret) to a ticket that is
 152    encrypted and integrity-protected by a key known only to the server.
 153    The ticket is distributed to the client using the NewSessionTicket
 154    TLS handshake message.  This message is sent during the TLS handshake
 155    before the ChangeCipherSpec message after the server has verified the
 156    client's Finished message.
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167 Salowey, et al.         Expires February 2, 2006                [Page 3]
 168 \f
 169 Internet-Draft      Stateless TLS Session Resumption         August 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 February 2, 2006                [Page 4]
 224 \f
 225 Internet-Draft      Stateless TLS Session Resumption         August 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    The SessionTicket extension has been assigned the number TBD1.
 244
 245 3.3  Format of NewSessionTicket handshake message
 246
 247    This message is sent during the TLS handshake before the
 248    ChangeCipherSpec message after the server has verified the client's
 249    Finished message.
 250
 251
 252       struct {
 253           HandshakeType msg_type;
 254           uint24 length;
 255           select (HandshakeType) {
 256               case hello_request:       HelloRequest;
 257               case client_hello:        ClientHello;
 258               case server_hello:        ServerHello;
 259               case certificate:         Certificate;
 260               case server_key_exchange: ServerKeyExchange;
 261               case certificate_request: CertificateRequest;
 262               case server_hello_done:   ServerHelloDone;
 263               case certificate_verify:  CertificateVerify;
 264               case client_key_exchange: ClientKeyExchange;
 265               case finished:            Finished;
 266               case new_session_ticket:  NewSessionTicket; /* NEW */
 267           } body;
 268       } Handshake;
 269
 270
 271       struct {
 272           opaque ticket<0..2^16-1>;
 273       } NewSessionTicket;
 274
 275    The NewSessionTicket handshake message has been assigned the number
 276
 277
 278
 279 Salowey, et al.         Expires February 2, 2006                [Page 5]
 280 \f
 281 Internet-Draft      Stateless TLS Session Resumption         August 2005
 282
 283
 284    TBD2.
 285
 286 4.  Sample ticket construction
 287
 288    This section describes one possibility how the ticket could be
 289    constructed, other implementations are possible.
 290
 291    The server uses two keys, one 128-bit key for AES encryption and one
 292    128-bit key for HMAC-SHA1.
 293
 294    The ticket is structured as follows:
 295
 296       struct {
 297           uint32 key_version;
 298           opaque iv[16]
 299           opaque encrypted_state<0..2^16-1>;
 300           opaque mac[20];
 301       } ExampleTicket;
 302
 303    Here key_version identifies a particular set of keys.  One
 304    possibility is to generate new random keys every time the server is
 305    started, and use the timestamp as the key version.  The same
 306    mechanisms known from a number of other protocols can be reused for
 307    this purpose.
 308
 309    The actual state information in encrypted_state is encrypted using
 310    128-bit AES in CBC mode with the given IV.  The MAC is calculated
 311    using HMAC-SHA1 over key_version (4 octets) and IV (16 octets),
 312    followed by the contents of the encrypted_state field (without the
 313    length).
 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 February 2, 2006                [Page 6]
 336 \f
 337 Internet-Draft      Stateless TLS Session Resumption         August 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           ExampleClientIdentity 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 February 2, 2006                [Page 7]
 392 \f
 393 Internet-Draft      Stateless TLS Session Resumption         August 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 February 2, 2006                [Page 8]
 448 \f
 449 Internet-Draft      Stateless TLS Session Resumption         August 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    IANA has assigned a TLS extension number of TBD1 (the value 35 is
 476    suggested) to the SessionTicket TLS extension from the TLS registry
 477    of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis].
 478
 479    IANA has assigned a TLS HandshakeType number TBD2 to the
 480    NewSessionTicket handshake type from the TLS registry of
 481    HandshakeType values defined in [I-D.ietf-tls-rfc2246-bis].
 482
 483 8.  References
 484
 485 8.1  Normative References
 486
 487    [I-D.ietf-tls-rfc2246-bis]
 488               Dierks, T. and E. Rescorla, "The TLS Protocol Version
 489               1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),
 490               June 2005.
 491
 492    [I-D.ietf-tls-rfc3546bis]
 493               Blake-Wilson, S., "Transport Layer Security (TLS)
 494               Extensions", draft-ietf-tls-rfc3546bis-01 (work in
 495               progress), May 2005.
 496
 497    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 498               Requirement Levels", BCP 14, RFC 2119, March 1997.
 499
 500
 501
 502
 503 Salowey, et al.         Expires February 2, 2006                [Page 9]
 504 \f
 505 Internet-Draft      Stateless TLS Session Resumption         August 2005
 506
 507
 508    [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 509               RFC 2246, January 1999.
 510
 511 8.2  Informative References
 512
 513    [AURA97]   Aura, T. and P. Nikander, "Stateless Connections",
 514               Proceedings of the First International Conference on
 515               Information and Communication Security (ICICS '97) , 1997.
 516
 517    [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client Side
 518               Caching for TLS",
 519               URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf.
 520
 521    [I-D.cam-winget-eap-fast]
 522               Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP
 523               Flexible Authentication via Secure Tunneling (EAP-FAST)",
 524               draft-cam-winget-eap-fast-02 (work in progress),
 525               April 2005.
 526
 527    [I-D.ietf-tls-psk]
 528               Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
 529               for Transport Layer Security (TLS)", draft-ietf-tls-psk-09
 530               (work in progress), June 2005.
 531
 532    [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
 533               Authentication Service (V5)", RFC 1510, September 1993.
 534
 535    [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
 536               Suites to Transport Layer Security (TLS)", RFC 2712,
 537               October 1999.
 538
 539
 540 Authors' Addresses
 541
 542    Joseph Salowey
 543    Cisco Systems
 544    2901 3rd Ave
 545    Seattle, WA  98121
 546    US
 547
 548    Email: jsalowey@cisco.com
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559 Salowey, et al.         Expires February 2, 2006               [Page 10]
 560 \f
 561 Internet-Draft      Stateless TLS Session Resumption         August 2005
 562
 563
 564    Hao Zhou
 565    Cisco Systems
 566    4125 Highlander Parkway
 567    Richfield, OH  44286
 568    US
 569
 570    Email: hzhou@cisco.com
 571
 572
 573    Pasi Eronen
 574    Nokia Research Center
 575    P.O. Box 407
 576    FIN-00045 Nokia Group
 577    Finland
 578
 579    Email: pasi.eronen@nokia.com
 580
 581
 582    Hannes Tschofenig
 583    Siemens
 584    Otto-Hahn-Ring 6
 585    Munich, Bayern  81739
 586    Germany
 587
 588    Email: Hannes.Tschofenig@siemens.com
 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 February 2, 2006               [Page 11]
 616 \f
 617 Internet-Draft      Stateless TLS Session Resumption         August 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 February 2, 2006               [Page 12]
 672 \f