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

   1
   2
   3
   4 Network Working Group                                         J. Salowey
   5 Internet-Draft                                                   H. Zhou
   6 Expires: June 18, 2006                                     Cisco Systems
   7                                                                P. Eronen
   8                                                                    Nokia
   9                                                            H. Tschofenig
  10                                                                  Siemens
  11                                                        December 15, 2005
  12
  13
  14  Transport Layer Security Session Resumption without Server-Side State
  15                     draft-salowey-tls-ticket-06.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 June 18, 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 June 18, 2006                 [Page 1]
  56 \f
  57 Internet-Draft      Stateless TLS Session Resumption       December 2005
  58
  59
  60    resume a session using the obtained ticket.
  61
  62 Table of Contents
  63
  64    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  65    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
  66    3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  67      3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
  68      3.2   SessionTicket TLS extension  . . . . . . . . . . . . . . .  5
  69      3.3   SessionTicket handshake message  . . . . . . . . . . . . .  6
  70      3.4   Interaction with TLS session ID  . . . . . . . . . . . . .  7
  71    4.  Recommended Ticket Construction  . . . . . . . . . . . . . . .  8
  72    5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
  73      5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . . 10
  74      5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 10
  75      5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 10
  76      5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . . 10
  77      5.5   Ticket Protection Key Lifetime . . . . . . . . . . . . . . 10
  78      5.6   Alternate Ticket Formats and Distribution Schemes  . . . . 11
  79    6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
  80    7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 11
  81    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  82      8.1   Normative References . . . . . . . . . . . . . . . . . . . 11
  83      8.2   Informative References . . . . . . . . . . . . . . . . . . 12
  84        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
  85        Intellectual Property and Copyright Statements . . . . . . . . 14
  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 June 18, 2006                 [Page 2]
 112 \f
 113 Internet-Draft      Stateless TLS Session Resumption       December 2005
 114
 115
 116 1.  Introduction
 117
 118    This document defines a way to resume a Transport Layer Security
 119    (TLS) session without requiring session-specific state at the TLS
 120    server.  This mechanism may be used with any TLS ciphersuite.  This
 121    document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1
 122    defined in [I-D.ietf-tls-rfc2246-bis].  The mechanism makes use of
 123    TLS extensions defined in [I-D.ietf-tls-rfc3546bis] and defines a new
 124    TLS message type.
 125
 126    This mechanism is useful in the following types of situations
 127       (1) servers that handle a large number of transactions from
 128       different users
 129       (2) servers that desire to cache sessions for a long time
 130       (3) ability to load balance requests across servers
 131       (4) embedded servers with little memory
 132
 133 2.  Terminology
 134
 135    Within this document the term 'ticket' refers to a cryptographically
 136    protected data structure which is created by the server and consumed
 137    by the server to rebuild session specific state.
 138
 139    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 140    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 141    document are to be interpreted as described in [RFC2119].
 142
 143 3.  Protocol
 144
 145    This specification describes a mechanism to distribute encrypted
 146    session state information in a ticket from a TLS server to a TLS
 147    client and a mechanism for a TLS client to present a ticket to a TLS
 148    server to resume a session.  Implementations of this specification
 149    are expected to support both mechanisms.  Other specifications can
 150    take advantage of the session tickets, perhaps specifying alternative
 151    means for distribution or selection.  For example a separate
 152    specification may describe an alternate way to distribute a ticket
 153    and use the TLS extension in this document to resume the session.
 154    This behavior is beyond the scope of the document and would need to
 155    be described in a separate specification.
 156
 157 3.1  Overview
 158
 159    The client indicates that it supports this mechanism by including a
 160    SessionTicket TLS extension in the ClientHello message.  The
 161    extension will be empty if the client does not already possess a
 162    ticket for the server.  The extension is described in Section 3.2
 163
 164
 165
 166
 167 Salowey, et al.           Expires June 18, 2006                 [Page 3]
 168 \f
 169 Internet-Draft      Stateless TLS Session Resumption       December 2005
 170
 171
 172    If the server wants to use this mechanism, it stores its session
 173    state (such as ciphersuite and master secret) to a ticket that is
 174    encrypted and integrity-protected by a key known only to the server.
 175    The ticket is distributed to the client using the SessionTicket TLS
 176    handshake message described in Section 3.3.  This message is sent
 177    during the TLS handshake before the ChangeCipherSpec message after
 178    the server has successfully verified the client's Finished message.
 179
 180
 181          Client                                               Server
 182
 183          ClientHello                   -------->
 184         (empty SessionTicket extension)
 185                                                          ServerHello
 186                                      (empty SessionTicket extension)
 187                                                         Certificate*
 188                                                   ServerKeyExchange*
 189                                                  CertificateRequest*
 190                                       <--------      ServerHelloDone
 191          Certificate*
 192          ClientKeyExchange
 193          CertificateVerify*
 194          [ChangeCipherSpec]
 195          Finished                     -------->
 196                                                        SessionTicket
 197                                                   [ChangeCipherSpec]
 198                                       <--------             Finished
 199          Application Data             <------->     Application Data
 200
 201    The client caches this ticket along with the master secret and other
 202    parameters associated with the current session.  When the client
 203    wishes to resume the session, it includes the ticket in the
 204    SessionTicket extension within ClientHello message.  The server then
 205    decrypts the received ticket, verifies that the ticket is valid and
 206    has not been tampered with, retrieves the session state from the
 207    contents of the ticket and uses this state to resume the session.
 208    The interaction with the TLS Session ID is described in Section 3.4.
 209    If the server successfully verifies the client's ticket then it may
 210    renew the ticket by including a SessionTicket handshake message after
 211    the ServerHello.
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223 Salowey, et al.           Expires June 18, 2006                 [Page 4]
 224 \f
 225 Internet-Draft      Stateless TLS Session Resumption       December 2005
 226
 227
 228          ClientHello
 229          (SessionTicket extension)      -------->
 230                                                           ServerHello
 231                                       (empty SessionTicket extension)
 232                                                         SessionTicket
 233                                                    [ChangeCipherSpec]
 234                                        <--------             Finished
 235          [ChangeCipherSpec]
 236          Finished                      -------->
 237          Application Data              <------->     Application Data
 238
 239    A recommended ticket format is given in Section 4.
 240
 241    If the server cannot or does not want to honor the ticket then it can
 242    initiate a full handshake with the client.
 243
 244 3.2  SessionTicket TLS extension
 245
 246    The SessionTicket TLS extension is based on [I-D.ietf-tls-
 247    rfc3546bis].  The format of the ticket is an opaque structure used to
 248    carry session specific state information.  This extension may be sent
 249    in the ClientHello and ServerHello.
 250
 251    If the client possesses a ticket that it wants to use to resume a
 252    session then it includes it in the SessionTicket extension in the
 253    ClientHello.  If the client does not have a ticket and it is prepared
 254    to receive one in the SessionTicket handshake message then it MUST
 255    include a zero length ticket in the SessionTicket extension.  If the
 256    client is not prepared to receive a ticket in the SessionTicket
 257    handshake message then it MUST NOT include a SessionTicket extension
 258    unless it is sending a non-empty ticket it received through some
 259    other means from the server.
 260
 261    The server uses an zero length SessionTicket extension to indicate to
 262    the client that it will send a new session ticket using the
 263    SessionTicket handshake message described in Section 3.3.  The server
 264    MUST send this extension in the ServerHello if the server wishes to
 265    issue a new ticket to the client using the SessionTicket handshake
 266    message.  The server MUST NOT send this extension if the client does
 267    not include a SessionTicket handshake message in the client hello.
 268
 269    If the server fails to verify the ticket then it falls back to
 270    performing a full handshake.  If the ticket is accepted by the server
 271    but the handshake fails the client SHOULD delete the ticket.
 272
 273    The SessionTicket extension has been assigned the number TBD1.  The
 274    format of the SessionTicket extension is given below.
 275
 276
 277
 278
 279 Salowey, et al.           Expires June 18, 2006                 [Page 5]
 280 \f
 281 Internet-Draft      Stateless TLS Session Resumption       December 2005
 282
 283
 284       struct {
 285           opaque ticket<0..2^16-1>;
 286       } SessionTicket;
 287
 288
 289 3.3  SessionTicket handshake message
 290
 291    This message is sent by the server during the TLS handshake before
 292    the ChangeCipherSpec message.  This message MUST be sent if the
 293    server included a SessionTicket extension in the ServerHello.  This
 294    message MUST NOT be sent if the server did not include a
 295    SessionTicket extension in the ServerHello.  In the case of a full
 296    handshake, the server MUST verify the client's Finished message
 297    before sending the ticket.  The client MUST NOT treat the ticket as
 298    valid until it has verified the server's Finished message.  If the
 299    server determines that it does not want to include a ticket after it
 300    has included the SessionTicket extension in the ServerHello then it
 301    MAY send a zero length ticket in the SessionTicket handshake message.
 302
 303    If the server successfully verifies the client's ticket then it MAY
 304    renew the ticket by including a SessionTicket handshake message after
 305    the ServerHello in the abbreviated handshake.  The client should
 306    start using the new ticket as soon as possible after it verifies the
 307    Server's finished message for new connections.  Note that since the
 308    updated ticket is issued before the handshake completes it is
 309    possible that the client may not put the new ticket into use before
 310    it initiates new connections.  The server MUST NOT assume the client
 311    actually received the updated ticket until it successfully verifies
 312    the client's Finished message.
 313
 314    The SessionTicket handshake message has been assigned the number
 315    TBD2.  The definition of the SessionTicket handshake message is given
 316    below.
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335 Salowey, et al.           Expires June 18, 2006                 [Page 6]
 336 \f
 337 Internet-Draft      Stateless TLS Session Resumption       December 2005
 338
 339
 340       struct {
 341           HandshakeType msg_type;
 342           uint24 length;
 343           select (HandshakeType) {
 344               case hello_request:       HelloRequest;
 345               case client_hello:        ClientHello;
 346               case server_hello:        ServerHello;
 347               case certificate:         Certificate;
 348               case server_key_exchange: ServerKeyExchange;
 349               case certificate_request: CertificateRequest;
 350               case server_hello_done:   ServerHelloDone;
 351               case certificate_verify:  CertificateVerify;
 352               case client_key_exchange: ClientKeyExchange;
 353               case finished:            Finished;
 354               case session_ticket:  SessionTicket; /* NEW */
 355           } body;
 356       } Handshake;
 357
 358
 359       struct {
 360           opaque ticket<0..2^16-1>;
 361       } SessionTicket;
 362
 363
 364 3.4  Interaction with TLS session ID
 365
 366    If a server is planning on issuing a SessionTicket to a client that
 367    does not present one it SHOULD include an empty Session ID in the
 368    ServerHello.  If the server includes a non-empty session ID then it
 369    is indicating intent to use stateful session resume.  If the client
 370    receives a SessionTicket from the server then it discards any Session
 371    ID that was sent in the ServerHello.
 372
 373    When presenting a ticket the client MAY generate and include a
 374    Session ID in the TLS ClientHello.  If the server accepts the ticket
 375    and the Session ID is not empty then it MUST respond with the same
 376    Session ID present in the ClientHello.  This allows the client to
 377    easily differentiate when the server is resuming a session or falling
 378    back to a full handshake.  Since the client generates a Session ID
 379    the server MUST NOT rely upon the Session ID having a particular
 380    value when validating the ticket.  If a ticket is presented by the
 381    client the server MUST NOT attempt to use the Session ID in the
 382    ClientHello for stateful session resume.  Alternatively, the client
 383    MAY include an empty Session ID in the ClientHello.  In this case the
 384    client ignores the Session ID sent in the ServerHello and determines
 385    if the server is resuming a session by the subsequent handshake
 386    messages.
 387
 388
 389
 390
 391 Salowey, et al.           Expires June 18, 2006                 [Page 7]
 392 \f
 393 Internet-Draft      Stateless TLS Session Resumption       December 2005
 394
 395
 396 4.  Recommended Ticket Construction
 397
 398    This section describes a recommended format and protection for the
 399    ticket.  Note that the ticket is opaque to the client so the
 400    structure is not subject to interoperability concerns, so
 401    implementations may diverge from this format.  If implementations do
 402    diverge from this format they must take security concerns seriously.
 403    Clients MUST NOT examine the ticket under the assumption that it
 404    complies with this document.
 405
 406    The server uses two different keys, one 128-bit key for AES [AES] in
 407    CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104]
 408    [SHA1].
 409
 410    The ticket is structured as follows:
 411
 412       struct {
 413           uint32 key_version;
 414           opaque iv[16]
 415           opaque encrypted_state<0..2^16-1>;
 416           opaque mac[20];
 417       } Ticket;
 418
 419    Here key_version identifies a particular set of keys.  One
 420    possibility is to generate new random keys every time the server is
 421    started, and use the timestamp as the key version.  The same
 422    mechanisms known from a number of other protocols can be reused for
 423    this purpose.
 424
 425    The actual state information in encrypted_state is encrypted using
 426    128-bit AES in CBC mode with the given IV.  The MAC is calculated
 427    using HMAC-SHA1 over key_version (4 octets)and IV (16 octets),
 428    followed by the length of the encrypted_state field (2 octets) and
 429    its contents (variable length).
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447 Salowey, et al.           Expires June 18, 2006                 [Page 8]
 448 \f
 449 Internet-Draft      Stateless TLS Session Resumption       December 2005
 450
 451
 452       struct {
 453           ProtocolVersion protocol_version;
 454           CipherSuite cipher_suite;
 455           CompressionMethod compression_method;
 456           opaque master_secret[48];
 457           ExampleClientIdentity client_identity;
 458           uint32 timestamp;
 459       } StatePlaintext;
 460
 461       enum {
 462          anonymous(0),
 463          certificate_based(1),
 464          psk(2)
 465      } ClientAuthenticationType;
 466
 467       struct {
 468           ClientAuthenticationType client_authentication_type;
 469           select (ClientAuthenticationType) {
 470               case anonymous: struct {};
 471               case certificate_based:
 472                   ASN.1Cert certificate_list<0..2^24-1>;
 473               case psk:
 474                   opaque psk_identity<0..2^16-1>;
 475
 476           }
 477        } ClientIdentity;
 478
 479    The structure StatePlaintext stores the TLS session state including
 480    the master_secret.  The timestamp within this structure allows the
 481    TLS server to expire tickets.  To cover the authentication and key
 482    exchange protocols provided by TLS the ClientIdentity structure
 483    contains the authentication type of the client used in the initial
 484    exchange (see ClientAuthenticationType).  To offer the TLS server
 485    with the same capabilities for authentication and authorization a
 486    certificate list is included in case of public key based
 487    authentication.  The TLS server is therefore able to inspect a number
 488    of different attributes within these certificates.  A specific
 489    implementation might choose to store a subset of this information or
 490    additional information.  Other authentication mechanism such as
 491    Kerberos [RFC2712] would require different client identity data.
 492
 493 5.  Security Considerations
 494
 495    This section addresses security issues related to the usage of a
 496    ticket.  Tickets must be sufficiently authenticated and encrypted to
 497    prevent modification or eavesdropping by an attacker.  Several
 498    attacks described below will be possible if this is not carefully
 499    done.
 500
 501
 502
 503 Salowey, et al.           Expires June 18, 2006                 [Page 9]
 504 \f
 505 Internet-Draft      Stateless TLS Session Resumption       December 2005
 506
 507
 508    Implementations should take care to ensure that the processing of
 509    tickets does not increase the chance of denial of serve as described
 510    below.
 511
 512 5.1  Invalidating Sessions
 513
 514    The TLS specification requires that TLS sessions be invalidated when
 515    errors occur.  [CSSC] discusses the security implications of this in
 516    detail.  In the analysis in this paper, failure to invalidate
 517    sessions does not pose a security risk.  This is because the TLS
 518    handshake uses a non-reversible function to derive keys for a session
 519    so information about one session does not provide an advantage to
 520    attack the master secret or a different session.  If a session
 521    invalidation scheme is used the implementation should verify the
 522    integrity of the ticket before using the contents to invalidate a
 523    session to ensure an attacker cannot invalidate a chosen session.
 524
 525 5.2  Stolen Tickets
 526
 527    An eavesdropper or man-in-the-middle may obtain the ticket and
 528    attempt to use the ticket to establish a session with the server,
 529    however since the ticket is encrypted and the attacker does not know
 530    the secret key, a stolen ticket does not help an attacker resume a
 531    session.  A TLS server MUST use strong encryption and integrity
 532    protection for the ticket to prevent an attacker from using a brute
 533    force mechanism to obtain the tickets contents.
 534
 535 5.3  Forged Tickets
 536
 537    A malicious user could forge or alter a ticket in order to resume a
 538    session, to extend its lifetime, to impersonate as another user or
 539    gain additional privileges.  This attack is not possible if the
 540    ticket is protected using a strong integrity protection algorithm
 541    such as a keyed HMAC-SHA1.
 542
 543 5.4  Denial of Service Attacks
 544
 545    An adversary could store or forge a large number of tickets to send
 546    to the TLS server for verification.  To minimize the possibility of a
 547    denial of service, the verification of the ticket should be
 548    lightweight (e.g., using efficient symmetric key cryptographic
 549    algorithms).
 550
 551 5.5  Ticket Protection Key Lifetime
 552
 553    The management of the keys used to protect the ticket is beyond the
 554    scope of this document.  It is advisable to limit the lifetime of
 555    these keys to ensure they are not overused.
 556
 557
 558
 559 Salowey, et al.           Expires June 18, 2006                [Page 10]
 560 \f
 561 Internet-Draft      Stateless TLS Session Resumption       December 2005
 562
 563
 564 5.6  Alternate Ticket Formats and Distribution Schemes
 565
 566    If a different ticket format or distribution scheme than the ones
 567    defined in this document is used then great care must be taken in
 568    analyzing the security of the solution.  In particular if a secret is
 569    transferred to the client it MUST be done using secure communication
 570    so as to prevent attackers from obtaining or modifying the key.  Also
 571    the ticket MUST have its integrity and privacy protected with strong
 572    cryptographic techniques to prevent a breach in the security of the
 573    system.
 574
 575 6.  Acknowledgments
 576
 577    The authors would like to thank the following people for their help
 578    with preparing and reviewing this document: Eric Rescorla, Mohamad
 579    Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
 580    Rob Dugal and members of the TLS working group.
 581
 582    [CSSC] describes a solution that is very similar to the one described
 583    in this document and gives a detailed analysis of the security
 584    considerations involved.  [RFC2712] describes a mechanism for using
 585    Kerberos ([RFC4120]) in TLS ciphersuites, which helped inspire the
 586    use of tickets to avoid server state.  [I-D.cam-winget-eap-fast]
 587    makes use of a similar mechanism to avoid maintaining server state
 588    for the cryptographic tunnel.  [SC97] also investigates the concept
 589    of stateless sessions.
 590
 591 7.  IANA considerations
 592
 593    IANA has assigned a TLS extension number of TBD1 (the value 35 is
 594    suggested) to the SessionTicket TLS extension from the TLS registry
 595    of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis].
 596
 597    IANA has assigned a TLS HandshakeType number TBD2 to the
 598    SessionTicket handshake type from the TLS registry of HandshakeType
 599    values defined in [I-D.ietf-tls-rfc2246-bis].
 600
 601 8.  References
 602
 603 8.1  Normative References
 604
 605    [I-D.ietf-tls-rfc2246-bis]
 606               Dierks, T. and E. Rescorla, "The TLS Protocol Version
 607               1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),
 608               June 2005.
 609
 610    [I-D.ietf-tls-rfc3546bis]
 611               Blake-Wilson, S., "Transport Layer Security (TLS)
 612
 613
 614
 615 Salowey, et al.           Expires June 18, 2006                [Page 11]
 616 \f
 617 Internet-Draft      Stateless TLS Session Resumption       December 2005
 618
 619
 620               Extensions", draft-ietf-tls-rfc3546bis-02 (work in
 621               progress), October 2005.
 622
 623    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 624               Requirement Levels", BCP 14, RFC 2119, March 1997.
 625
 626    [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 627               RFC 2246, January 1999.
 628
 629 8.2  Informative References
 630
 631    [AES]      National Institute of Standards and Technology, "Advanced
 632               Encryption Standard (AES)", Federal Information
 633               Processing Standards (FIPS) Publication 197,
 634               November 2001.
 635
 636    [CBC]      National Institute of Standards and Technology,
 637               "Recommendation for Block Cipher Modes of Operation -
 638               Methods and Techniques", NIST Special Publication 800-38A,
 639               December 2001.
 640
 641    [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client-side
 642               caching for TLS", Transactions on Information and
 643               System Security (TISSEC) , Volume 7, Issue 4,
 644               November 2004.
 645
 646    [I-D.cam-winget-eap-fast]
 647               Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP
 648               Flexible Authentication via Secure Tunneling (EAP-FAST)",
 649               draft-cam-winget-eap-fast-02 (work in progress),
 650               April 2005.
 651
 652    [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
 653               Hashing for Message Authentication", RFC 2104,
 654               February 1997.
 655
 656    [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
 657               Suites to Transport Layer Security (TLS)", RFC 2712,
 658               October 1999.
 659
 660    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 661               Kerberos Network Authentication Service (V5)", RFC 4120,
 662               July 2005.
 663
 664    [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
 665               for Transport Layer Security (TLS)", RFC 4279,
 666               December 2005.
 667
 668
 669
 670
 671 Salowey, et al.           Expires June 18, 2006                [Page 12]
 672 \f
 673 Internet-Draft      Stateless TLS Session Resumption       December 2005
 674
 675
 676    [SC97]     Aura, T. and P. Nikander, "Stateless Connections",
 677               Proceedings of the First International Conference on
 678               Information and Communication Security (ICICS '97) , 1997.
 679
 680    [SHA1]     National Institute of Standards and Technology, "Secure
 681               Hash Standard (SHS)", Federal Information Processing
 682               Standards    (FIPS) Publication  180-2, August 2002.
 683
 684
 685 Authors' Addresses
 686
 687    Joseph Salowey
 688    Cisco Systems
 689    2901 3rd Ave
 690    Seattle, WA  98121
 691    US
 692
 693    Email: jsalowey@cisco.com
 694
 695
 696    Hao Zhou
 697    Cisco Systems
 698    4125 Highlander Parkway
 699    Richfield, OH  44286
 700    US
 701
 702    Email: hzhou@cisco.com
 703
 704
 705    Pasi Eronen
 706    Nokia Research Center
 707    P.O. Box 407
 708    FIN-00045 Nokia Group
 709    Finland
 710
 711    Email: pasi.eronen@nokia.com
 712
 713
 714    Hannes Tschofenig
 715    Siemens
 716    Otto-Hahn-Ring 6
 717    Munich, Bayern  81739
 718    Germany
 719
 720    Email: Hannes.Tschofenig@siemens.com
 721
 722
 723
 724
 725
 726
 727 Salowey, et al.           Expires June 18, 2006                [Page 13]
 728 \f
 729 Internet-Draft      Stateless TLS Session Resumption       December 2005
 730
 731
 732 Intellectual Property Statement
 733
 734    The IETF takes no position regarding the validity or scope of any
 735    Intellectual Property Rights or other rights that might be claimed to
 736    pertain to the implementation or use of the technology described in
 737    this document or the extent to which any license under such rights
 738    might or might not be available; nor does it represent that it has
 739    made any independent effort to identify any such rights.  Information
 740    on the procedures with respect to rights in RFC documents can be
 741    found in BCP 78 and BCP 79.
 742
 743    Copies of IPR disclosures made to the IETF Secretariat and any
 744    assurances of licenses to be made available, or the result of an
 745    attempt made to obtain a general license or permission for the use of
 746    such proprietary rights by implementers or users of this
 747    specification can be obtained from the IETF on-line IPR repository at
 748    http://www.ietf.org/ipr.
 749
 750    The IETF invites any interested party to bring to its attention any
 751    copyrights, patents or patent applications, or other proprietary
 752    rights that may cover technology that may be required to implement
 753    this standard.  Please address the information to the IETF at
 754    ietf-ipr@ietf.org.
 755
 756
 757 Disclaimer of Validity
 758
 759    This document and the information contained herein are provided on an
 760    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 761    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 762    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 763    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 764    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 765    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 766
 767
 768 Copyright Statement
 769
 770    Copyright (C) The Internet Society (2005).  This document is subject
 771    to the rights, licenses and restrictions contained in BCP 78, and
 772    except as set forth therein, the authors retain all their rights.
 773
 774
 775 Acknowledgment
 776
 777    Funding for the RFC Editor function is currently provided by the
 778    Internet Society.
 779
 780
 781
 782
 783 Salowey, et al.           Expires June 18, 2006                [Page 14]
 784 \f