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