idnits 2.17.1 draft-salowey-tls-ticket-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 651. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 25, 2006) is 6637 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 174, but not defined -- Looks like a reference, but probably isn't: '16' on line 322 -- Looks like a reference, but probably isn't: '20' on line 324 -- Looks like a reference, but probably isn't: '48' on line 343 == Unused Reference: 'RFC4279' is defined on line 584, but no explicit reference was found in the text ** Downref: Normative reference to an Historic draft: draft-ietf-tls-rfc2246-bis (ref. 'I-D.ietf-tls-rfc2246-bis') ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) == Outdated reference: A later version (-06) exists of draft-cam-winget-eap-fast-02 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Salowey 3 Internet-Draft H. Zhou 4 Expires: July 29, 2006 Cisco Systems 5 P. Eronen 6 Nokia 7 H. Tschofenig 8 Siemens 9 January 25, 2006 11 Transport Layer Security Session Resumption without Server-Side State 12 draft-salowey-tls-ticket-07.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 29, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document describes a mechanism which enables the Transport Layer 46 Security (TLS) server to resume sessions and avoid keeping per-client 47 session state. The TLS server encapsulates the session state into a 48 ticket and forwards it to the client. The client can subsequently 49 resume a session using the obtained ticket. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2 SessionTicket TLS extension . . . . . . . . . . . . . . . 5 58 3.3 NewSessionTicket handshake message . . . . . . . . . . . . 6 59 3.4 Interaction with TLS session ID . . . . . . . . . . . . . 7 60 4. Recommended Ticket Construction . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 5.1 Invalidating Sessions . . . . . . . . . . . . . . . . . . 10 63 5.2 Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 10 64 5.3 Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 10 65 5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . 10 66 5.5 Ticket Protection Key Management . . . . . . . . . . . . . 10 67 5.6 Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 11 68 5.7 Alternate Ticket Formats and Distribution Schemes . . . . 11 69 5.8 Identity Privacy, Anonymity and Unlinkability . . . . . . 11 70 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 74 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . 16 78 1. Introduction 80 This document defines a way to resume a Transport Layer Security 81 (TLS) session without requiring session-specific state at the TLS 82 server. This mechanism may be used with any TLS ciphersuite. This 83 document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1 84 defined in [I-D.ietf-tls-rfc2246-bis]. The mechanism makes use of 85 TLS extensions defined in [I-D.ietf-tls-rfc3546bis] and defines a new 86 TLS message type. 88 This mechanism is useful in the following types of situations: 90 1. servers that handle a large number of transactions from 91 different users 92 2. servers that desire to cache sessions for a long time 93 3. ability to load balance requests across servers 94 4. embedded servers with little memory 96 2. Terminology 98 Within this document the term 'ticket' refers to a cryptographically 99 protected data structure which is created by the server and consumed 100 by the server to rebuild session specific state. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Protocol 108 This specification describes a mechanism to distribute encrypted 109 session state information in the form of a ticket. The ticket is 110 created by a TLS server and sent to a TLS client. The TLS client 111 presents the ticket to the TLS server to resume a session. 112 Implementations of this specification are expected to support both 113 mechanisms. Other specifications can take advantage of the session 114 tickets, perhaps specifying alternative means for distribution or 115 selection. For example a separate specification may describe an 116 alternate way to distribute a ticket and use the TLS extension in 117 this document to resume the session. This behavior is beyond the 118 scope of the document and would need to be described in a separate 119 specification. 121 3.1 Overview 123 The client indicates that it supports this mechanism by including a 124 SessionTicket TLS extension in the ClientHello message. The 125 extension will be empty if the client does not already possess a 126 ticket for the server. The extension is described in Section 3.2 128 If the server wants to use this mechanism, it stores its session 129 state (such as ciphersuite and master secret) to a ticket that is 130 encrypted and integrity-protected by a key known only to the server. 131 The ticket is distributed to the client using the NewSessionTicket 132 TLS handshake message described in Section 3.3. This message is sent 133 during the TLS handshake before the ChangeCipherSpec message after 134 the server has successfully verified the client's Finished message. 136 Client Server 138 ClientHello --------> 139 (empty SessionTicket extension) 140 ServerHello 141 (empty SessionTicket extension) 142 Certificate* 143 ServerKeyExchange* 144 CertificateRequest* 145 <-------- ServerHelloDone 146 Certificate* 147 ClientKeyExchange 148 CertificateVerify* 149 [ChangeCipherSpec] 150 Finished --------> 151 NewSessionTicket 152 [ChangeCipherSpec] 153 <-------- Finished 154 Application Data <-------> Application Data 156 The client caches this ticket along with the master secret and other 157 parameters associated with the current session. When the client 158 wishes to resume the session, it includes the ticket in the 159 SessionTicket extension within ClientHello message. The server then 160 decrypts the received ticket, verifies that the ticket validity, 161 retrieves the session state from the contents of the ticket and uses 162 this state to resume the session. The interaction with the TLS 163 Session ID is described in Section 3.4. If the server successfully 164 verifies the client's ticket then it may renew the ticket by 165 including a NewSessionTicket handshake message after the ServerHello. 167 ClientHello 168 (SessionTicket extension) --------> 169 ServerHello 170 (empty SessionTicket extension) 171 NewSessionTicket 172 [ChangeCipherSpec] 173 <-------- Finished 174 [ChangeCipherSpec] 175 Finished --------> 176 Application Data <-------> Application Data 178 A recommended ticket format is given in Section 4. 180 If the server cannot or does not want to honor the ticket then it can 181 initiate a full handshake with the client. 183 3.2 SessionTicket TLS extension 185 The SessionTicket TLS extension is based on [I-D.ietf-tls- 186 rfc3546bis]. The format of the ticket is an opaque structure used to 187 carry session specific state information. This extension may be sent 188 in the ClientHello and ServerHello. 190 If the client possesses a ticket that it wants to use to resume a 191 session then it includes the ticket in the SessionTicket extension in 192 the ClientHello. If the client does not have a ticket and it is 193 prepared to receive one in the NewSessionTicket handshake message 194 then it MUST include a zero length ticket in the SessionTicket 195 extension. If the client is not prepared to receive a ticket in the 196 NewSessionTicket handshake message then it MUST NOT include a 197 SessionTicket extension unless it is sending a non-empty ticket it 198 received through some other means from the server. 200 The server uses an zero length SessionTicket extension to indicate to 201 the client that it will send a new session ticket using the 202 NewSessionTicket handshake message described in Section 3.3. The 203 server MUST send this extension in the ServerHello if it wishes to 204 issue a new ticket to the client using the NewSessionTicket handshake 205 message. The server MUST NOT send this extension if it does not 206 receive on in the ClientHello. 208 If the server fails to verify the ticket then it falls back to 209 performing a full handshake. If the ticket is accepted by the server 210 but the handshake fails the client SHOULD delete the ticket. 212 The SessionTicket extension has been assigned the number TBD1. The 213 format of the SessionTicket extension is given at the end of this 214 section. 216 struct { 217 opaque ticket<0..2^16-1>; 218 } SessionTicket; 220 3.3 NewSessionTicket handshake message 222 This message is sent by the server during the TLS handshake before 223 the ChangeCipherSpec message. This message MUST be sent if the 224 server included a SessionTicket extension in the ServerHello. This 225 message MUST NOT be sent if the server did not include a 226 SessionTicket extension in the ServerHello. In the case of a full 227 handshake, the server MUST verify the client's Finished message 228 before sending the ticket. The client MUST NOT treat the ticket as 229 valid until it has verified the server's Finished message. If the 230 server determines that it does not want to include a ticket after it 231 has included the SessionTicket extension in the ServerHello then it 232 sends a zero length ticket in the NewSessionTicket handshake message. 234 If the server successfully verifies the client's ticket then it MAY 235 renew the ticket by including a NewSessionTicket handshake message 236 after the ServerHello in the abbreviated handshake. The client 237 should start using the new ticket as soon as possible after it 238 verifies the Server's finished message for new connections. Note 239 that since the updated ticket is issued before the handshake 240 completes it is possible that the client may not put the new ticket 241 into use before it initiates new connections. The server MUST NOT 242 assume the client actually received the updated ticket until it 243 successfully verifies the client's Finished message. 245 The NewSessionTicket handshake message has been assigned the number 246 TBD2 and its definition is given at the end of this section. The 247 ticket_lifetime_hint field contains a hint from the server about how 248 long the ticket should be stored. The value indicates the lifetime 249 in seconds as a 32 bit unsigned integer in network byte order. A 250 value of zero is reserved to indicate that the lifetime of the ticket 251 is unspecified. A client SHOULD delete the ticket and associated 252 state when the time expires. It MAY delete the ticket earlier based 253 on local policy. A server MAY treat a ticket as valid for a shorter 254 or longer period of time than what is stated in the 255 ticket_lifetime_hint. 257 struct { 258 HandshakeType msg_type; 259 uint24 length; 260 select (HandshakeType) { 261 case hello_request: HelloRequest; 262 case client_hello: ClientHello; 263 case server_hello: ServerHello; 264 case certificate: Certificate; 265 case server_key_exchange: ServerKeyExchange; 266 case certificate_request: CertificateRequest; 267 case server_hello_done: ServerHelloDone; 268 case certificate_verify: CertificateVerify; 269 case client_key_exchange: ClientKeyExchange; 270 case finished: Finished; 271 case session_ticket: NewSessionTicket; /* NEW */ 272 } body; 273 } Handshake; 275 struct { 276 uint32 ticket_lifetime_hint; 277 opaque ticket<0..2^16-1>; 278 } NewSessionTicket; 280 3.4 Interaction with TLS session ID 282 If a server is planning on issuing a SessionTicket to a client that 283 does not present one it SHOULD include an empty Session ID in the 284 ServerHello. If the server includes a non-empty session ID then it 285 is indicating intent to use stateful session resume. If the client 286 receives a SessionTicket from the server then it discards any Session 287 ID that was sent in the ServerHello. 289 When presenting a ticket the client MAY generate and include a 290 Session ID in the TLS ClientHello. If the server accepts the ticket 291 and the Session ID is not empty then it MUST respond with the same 292 Session ID present in the ClientHello. This allows the client to 293 easily differentiate when the server is resuming a session or falling 294 back to a full handshake. Since the client generates a Session ID 295 the server MUST NOT rely upon the Session ID having a particular 296 value when validating the ticket. If a ticket is presented by the 297 client the server MUST NOT attempt to use the Session ID in the 298 ClientHello for stateful session resume. Alternatively, the client 299 MAY include an empty Session ID in the ClientHello. In this case the 300 client ignores the Session ID sent in the ServerHello and determines 301 if the server is resuming a session by the subsequent handshake 302 messages. 304 4. Recommended Ticket Construction 306 This section describes a recommended format and protection for the 307 ticket. Note that the ticket is opaque to the client so the 308 structure is not subject to interoperability concerns, so 309 implementations may diverge from this format. If implementations do 310 diverge from this format they must take security concerns seriously. 311 Clients MUST NOT examine the ticket under the assumption that it 312 complies with this document. 314 The server uses two different keys, one 128-bit key for AES [AES] in 315 CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104] 316 [SHA1]. 318 The ticket is structured as follows: 320 struct { 321 opaque key_name[16]; 322 opaque iv[16]; 323 opaque encrypted_state<0..2^16-1>; 324 opaque mac[20]; 325 } ticket; 327 Here key_name serves to identify a particular set of keys used to 328 protect the ticket. It enables the server to easily recognize 329 tickets it has issued. The key_name should be randomly generated to 330 avoid collisions between servers. One possibility is to generate new 331 random keys and key_name every time the server is started. 333 The actual state information in encrypted_state is encrypted using 334 128-bit AES in CBC mode with the given IV. The MAC is calculated 335 using HMAC-SHA1 over key_name (16 octets)and IV (16 octets), followed 336 by the length of the encrypted_state field (2 octets) and its 337 contents (variable length). 339 struct { 340 ProtocolVersion protocol_version; 341 CipherSuite cipher_suite; 342 CompressionMethod compression_method; 343 opaque master_secret[48]; 344 ClientIdentity client_identity; 345 uint32 timestamp; 346 } StatePlaintext; 348 enum { 349 anonymous(0), 350 certificate_based(1), 351 psk(2) 352 } ClientAuthenticationType; 354 struct { 355 ClientAuthenticationType client_authentication_type; 356 select (ClientAuthenticationType) { 357 case anonymous: struct {}; 358 case certificate_based: 359 ASN.1Cert certificate_list<0..2^24-1>; 360 case psk: 361 opaque psk_identity<0..2^16-1>; 363 } 364 } ClientIdentity; 366 The structure StatePlaintext stores the TLS session state including 367 the master_secret. The timestamp within this structure allows the 368 TLS server to expire tickets. To cover the authentication and key 369 exchange protocols provided by TLS the ClientIdentity structure 370 contains the authentication type of the client used in the initial 371 exchange (see ClientAuthenticationType). To offer the TLS server 372 with the same capabilities for authentication and authorization a 373 certificate list is included in case of public key based 374 authentication. The TLS server is therefore able to inspect a number 375 of different attributes within these certificates. A specific 376 implementation might choose to store a subset of this information or 377 additional information. Other authentication mechanisms, such as 378 Kerberos [RFC2712], would require different client identity data. 380 5. Security Considerations 382 This section addresses security issues related to the usage of a 383 ticket. Tickets must be sufficiently authenticated and encrypted to 384 prevent modification or eavesdropping by an attacker. Several 385 attacks described below will be possible if this is not carefully 386 done. 388 Implementations should take care to ensure that the processing of 389 tickets does not increase the chance of denial of serve as described 390 below. 392 5.1 Invalidating Sessions 394 The TLS specification requires that TLS sessions be invalidated when 395 errors occur. [CSSC] discusses the security implications of this in 396 detail. In the analysis in this paper, failure to invalidate 397 sessions does not pose a security risk. This is because the TLS 398 handshake uses a non-reversible function to derive keys for a session 399 so information about one session does not provide an advantage to 400 attack the master secret or a different session. If a session 401 invalidation scheme is used the implementation should verify the 402 integrity of the ticket before using the contents to invalidate a 403 session to ensure an attacker cannot invalidate a chosen session. 405 5.2 Stolen Tickets 407 An eavesdropper or man-in-the-middle may obtain the ticket and 408 attempt to use the ticket to establish a session with the server, 409 however since the ticket is encrypted and the attacker does not know 410 the secret key, a stolen ticket does not help an attacker resume a 411 session. A TLS server MUST use strong encryption and integrity 412 protection for the ticket to prevent an attacker from using a brute 413 force mechanism to obtain the tickets contents. 415 5.3 Forged Tickets 417 A malicious user could forge or alter a ticket in order to resume a 418 session, to extend its lifetime, to impersonate as another user or 419 gain additional privileges. This attack is not possible if the 420 ticket is protected using a strong integrity protection algorithm 421 such as a keyed HMAC-SHA1. 423 5.4 Denial of Service Attacks 425 The key_name field defined in the recommended ticket format helps the 426 server efficiently reject tickets that it did not issue. However, an 427 adversary could store or generate a large number of tickets to send 428 to the TLS server for verification. To minimize the possibility of a 429 denial of service, the verification of the ticket should be 430 lightweight (e.g., using efficient symmetric key cryptographic 431 algorithms). 433 5.5 Ticket Protection Key Management 435 A full description of the management of the keys used to protect the 436 ticket is beyond the scope of this document. A list of RECOMMENDED 437 practices is given below. 439 o The key should be generated securely following the randomness 440 recommendations in [RFC4086] 441 o The key and cryptographic protection algorithms should be at least 442 128 bits in strength 443 o The key should not be used for any other purpose than generating 444 and verifying tickets 445 o The key should be changed regularly 446 o The key should be changed if the ticket format or cryptographic 447 protection algorithms change 449 5.6 Ticket Lifetime 451 The TLS server controls the lifetime of the ticket. Servers 452 determine the acceptable lifetime based on the operational and 453 security requirements of the environments in which they are deployed. 454 The ticket lifetime may be longer than the 24 hour lifetime 455 recommended in [RFC2246]. TLS clients may be given a hint of the 456 lifetime of the ticket. Since the lifetime of a ticket may be 457 unspecified a client has its own local policy which determines when 458 it discards tickets. 460 5.7 Alternate Ticket Formats and Distribution Schemes 462 If the ticket format or distribution scheme defined in this document 463 is not used then great care must be taken in analyzing the security 464 of the solution. In particular if a confidential information, such 465 as a secret key, is transferred to the client it MUST be done using 466 secure communication so as to prevent attackers from obtaining or 467 modifying the key. Also the ticket MUST have its integrity and 468 privacy protected with strong cryptographic techniques to prevent a 469 breach in the security of the system. 471 5.8 Identity Privacy, Anonymity and Unlinkability 473 This document mandates that the content of the ticket is 474 confidentiality protected in order to avoid leakage of its content, 475 such as user relevant information. As such, it prevents disclosure 476 of potentially sensitive information carried within the ticket. 478 The initial handshake exchange, which was used to obtain the ticket, 479 might not provide identity confidentiality of the client based on the 480 properties of TLS. Another relevant security threat is the ability 481 for an on-path adversary to observe multiple TLS handshakes where the 482 same ticket is used and to therefore conclude that they belong to the 483 same communication endpoints. Application designers that use the 484 ticket mechanism described in this document should consider that 485 unlinkability [ANON] is not necessarily provided. 487 While a full discussion of these topics is beyond the scope of this 488 document, it should be noted that it is possible to issue a ticket 489 using a TLS renegotiation handshake that occurs after a secure tunnel 490 has been established by a previous handshake. This may help address 491 some privacy and unlinkability issues in some environments. 493 6. Acknowledgments 495 The authors would like to thank the following people for their help 496 with preparing and reviewing this document: Eric Rescorla, Mohamad 497 Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew, 498 Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba and members of 499 the TLS working group. 501 [CSSC] describes a solution that is very similar to the one described 502 in this document and gives a detailed analysis of the security 503 considerations involved. [RFC2712] describes a mechanism for using 504 Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use 505 of tickets to avoid server state. [I-D.cam-winget-eap-fast] makes 506 use of a similar mechanism to avoid maintaining server state for the 507 cryptographic tunnel. [SC97] also investigates the concept of 508 stateless sessions. 510 7. IANA considerations 512 IANA has assigned a TLS extension number of TBD1 (the value 35 is 513 suggested) to the SessionTicket TLS extension from the TLS registry 514 of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis]. 516 IANA has assigned a TLS HandshakeType number TBD2 to the 517 NewSessionTicket handshake type from the TLS registry of 518 HandshakeType values defined in [I-D.ietf-tls-rfc2246-bis]. 520 8. References 522 8.1 Normative References 524 [I-D.ietf-tls-rfc2246-bis] 525 Dierks, T. and E. Rescorla, "The TLS Protocol Version 526 1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress), 527 June 2005. 529 [I-D.ietf-tls-rfc3546bis] 530 Blake-Wilson, S., "Transport Layer Security (TLS) 531 Extensions", draft-ietf-tls-rfc3546bis-02 (work in 532 progress), October 2005. 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, March 1997. 537 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 538 RFC 2246, January 1999. 540 8.2 Informative References 542 [AES] National Institute of Standards and Technology, "Advanced 543 Encryption Standard (AES)", Federal Information 544 Processing Standards (FIPS) Publication 197, 545 November 2001. 547 [ANON] Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability, 548 Unobservability, Pseudonymity, and Identity Management - A 549 Consolidated Proposal for Terminology", http:// 550 dud.inf.tu-dresden.de/literatur/ 551 Anon_Terminology_v0.26-1.pdf Draft 0.26, December 2005. 553 [CBC] National Institute of Standards and Technology, 554 "Recommendation for Block Cipher Modes of Operation - 555 Methods and Techniques", NIST Special Publication 800-38A, 556 December 2001. 558 [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side 559 caching for TLS", Transactions on Information and 560 System Security (TISSEC) , Volume 7, Issue 4, 561 November 2004. 563 [I-D.cam-winget-eap-fast] 564 Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP 565 Flexible Authentication via Secure Tunneling (EAP-FAST)", 566 draft-cam-winget-eap-fast-02 (work in progress), 567 April 2005. 569 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 570 Hashing for Message Authentication", RFC 2104, 571 February 1997. 573 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 574 Suites to Transport Layer Security (TLS)", RFC 2712, 575 October 1999. 577 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 578 Requirements for Security", BCP 106, RFC 4086, June 2005. 580 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 581 Kerberos Network Authentication Service (V5)", RFC 4120, 582 July 2005. 584 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 585 for Transport Layer Security (TLS)", RFC 4279, 586 December 2005. 588 [SC97] Aura, T. and P. Nikander, "Stateless Connections", 589 Proceedings of the First International Conference on 590 Information and Communication Security (ICICS '97) , 1997. 592 [SHA1] National Institute of Standards and Technology, "Secure 593 Hash Standard (SHS)", Federal Information Processing 594 Standards (FIPS) Publication 180-2, August 2002. 596 Authors' Addresses 598 Joseph Salowey 599 Cisco Systems 600 2901 3rd Ave 601 Seattle, WA 98121 602 US 604 Email: jsalowey@cisco.com 606 Hao Zhou 607 Cisco Systems 608 4125 Highlander Parkway 609 Richfield, OH 44286 610 US 612 Email: hzhou@cisco.com 614 Pasi Eronen 615 Nokia Research Center 616 P.O. Box 407 617 FIN-00045 Nokia Group 618 Finland 620 Email: pasi.eronen@nokia.com 621 Hannes Tschofenig 622 Siemens 623 Otto-Hahn-Ring 6 624 Munich, Bayern 81739 625 Germany 627 Email: Hannes.Tschofenig@siemens.com 629 Intellectual Property Statement 631 The IETF takes no position regarding the validity or scope of any 632 Intellectual Property Rights or other rights that might be claimed to 633 pertain to the implementation or use of the technology described in 634 this document or the extent to which any license under such rights 635 might or might not be available; nor does it represent that it has 636 made any independent effort to identify any such rights. Information 637 on the procedures with respect to rights in RFC documents can be 638 found in BCP 78 and BCP 79. 640 Copies of IPR disclosures made to the IETF Secretariat and any 641 assurances of licenses to be made available, or the result of an 642 attempt made to obtain a general license or permission for the use of 643 such proprietary rights by implementers or users of this 644 specification can be obtained from the IETF on-line IPR repository at 645 http://www.ietf.org/ipr. 647 The IETF invites any interested party to bring to its attention any 648 copyrights, patents or patent applications, or other proprietary 649 rights that may cover technology that may be required to implement 650 this standard. Please address the information to the IETF at 651 ietf-ipr@ietf.org. 653 Disclaimer of Validity 655 This document and the information contained herein are provided on an 656 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 657 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 658 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 659 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 660 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 661 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 663 Copyright Statement 665 Copyright (C) The Internet Society (2006). This document is subject 666 to the rights, licenses and restrictions contained in BCP 78, and 667 except as set forth therein, the authors retain all their rights. 669 Acknowledgment 671 Funding for the RFC Editor function is currently provided by the 672 Internet Society.