idnits 2.17.00 (12 Aug 2021) /tmp/idnits50777/draft-nir-tls-eap-00.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, updated by RFC 4748 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 617. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (June 7, 2007) is 5462 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '12' on line 296 ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (ref. 'TLS-EXT') (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. 'Diameter') (Obsoleted by RFC 6733) == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Y. Nir 3 Internet-Draft Y. Sheffer 4 Intended status: Standards Track Check Point 5 Expires: December 9, 2007 H. Tschofenig 6 NSN 7 P. Gutmann 8 University of Auckland 9 June 7, 2007 11 TLS using EAP Authentication 12 draft-nir-tls-eap-00.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 December 9, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document describes an extension to the TLS protocol to allow TLS 46 clients to authenticate with legacy credentials using the Extensible 47 Authentication Protocol (EAP). 49 This work follows the example of IKEv2, where EAP has been added to 50 the IKEv2 protocol to allow clients to use different credentials such 51 as passwords, token cards, and shared secrets. 53 When TLS is used with EAP, additional records are sent after the 54 ChangeCipherSpec protocol message and before the Finished message, 55 effectively creating an extended handshake before the application 56 layer data can be sent. Each EapMsg handshake record contains 57 exactly one EAP message. Using EAP for client authentication allows 58 TLS to be used with various AAA back-end servers such as RADIUS or 59 Diameter. 61 TLS with EAP may be used for securing a data connection such as HTTP 62 or POP3. We believe it has three main benefits: 63 o The ability of EAP to work with backend servers can remove that 64 burden from the application layer. 65 o Moving the user authentication into the TLS handshake protects the 66 presumably less secure application layer from attacks by 67 unauthenticated parties. 68 o Using mutual authentication methods within EAP can help thwart 69 certain classes of phishing attacks. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. EAP Applicability . . . . . . . . . . . . . . . . . . . . 5 75 1.2. Conventions Used in This Document . . . . . . . . . . . . 5 76 2. Operating Environment . . . . . . . . . . . . . . . . . . . . 6 77 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 78 3.1. The tee_supported Extension . . . . . . . . . . . . . . . 8 79 3.2. The InterimAuth Handshake Message . . . . . . . . . . . . 8 80 3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 8 81 3.4. Calculating the Finished message . . . . . . . . . . . . . 9 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10 84 4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10 85 4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 11 86 5. Performance Considerations . . . . . . . . . . . . . . . . . . 12 87 6. Operational Considerations . . . . . . . . . . . . . . . . . . 13 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 90 9. Changes from Previous Versions . . . . . . . . . . . . . . . . 16 91 9.1. Changes from the protocol model draft . . . . . . . . . . 16 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 96 Intellectual Property and Copyright Statements . . . . . . . . . . 20 98 1. Introduction 100 This document describes a new extension to [TLS]. This extension 101 allows a TLS client to authenticate using [EAP] instead of performing 102 the authentication at the application level. The extension follows 103 [TLS-EXT]. For the remainder of this document we will refer to this 104 extension as TEE (TLS with EAP Extension). 106 TEE extends the TLS handshake beyond the regular setup, to allow the 107 EAP protocol to run between the TLS server (called an "authenticator" 108 in EAP) and the TLS client (called a "supplicant"). This allows the 109 TLS architecture to handle client authentication before exposing the 110 server application software to an unauthenticated client. In doing 111 this, we follow the approach taken for IKEv2 in [RFC4306]. However, 112 similar to regular TLS, we protect the user identity by only sending 113 the client identity after the server has authenticated. In this our 114 solution differs from that of IKEv2. 116 Currently used applications that rely on non-certificate user 117 credentials use TLS to authenticate the server only. After that, the 118 application takes over, and presents a login screen where the user is 119 expected to present their credentials. 121 This creates several problems. It allows a client to access the 122 application before authentication, thus creating a potential for 123 anonymous attacks on non-hardened applications. Additionally, web 124 pages are not particularly well suited for long shared secrets and 125 for interfacing with certain devices such as USB tokens. 127 TEE allows full mutual authentication to occur for all these 128 applications within the TLS exchange. The application receives 129 control only when the user is identified and authenticated. The 130 authentication can be built into the server infrastructure by 131 connecting to an AAA server. The client side can be integrated into 132 client software such as web browsers and mail clients. An EAP 133 infrastructure is already built into some operating systems providing 134 a user interface for each authentication method within EAP. 136 We intend TEE to be used for various protocols that use TLS such as 137 HTTPS, in cases where certificate based client authentication is not 138 practical. This includes web-based mail services, online banking, 139 premium content websites and mail clients. 141 Another class of applications that may see benefit from TEE are TLS 142 based VPN clients used as part of so-called "SSL VPN" products. No 143 such client protocols have so far been standardized. 145 1.1. EAP Applicability 147 Section 1.3 of [EAP] states that EAP is only applicable for network 148 access authentication, rather than for "bulk data transfer". It then 149 goes on to explain why the transport properties of EAP indeed make it 150 unsuitable for bulk data transfer, e.g. for large file transport. 151 Our proposed use of EAP falls squarely within the applicability as 152 defined, since we make no further use of EAP beyond access 153 authentication. 155 1.2. Conventions Used in This Document 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 2. Operating Environment 163 TEE will work between a client application and a server application, 164 performing either client authentication or mutual authentication 165 within the TLS exchange. 167 Client Server 168 +-------------------------+ +------------------------+ 169 | |GUI| | Client | |TLS+-+-----+-+TLS| |Server | | 170 | +-^-+ |Software| +-^-+ | +-+-^-+ |Application | | 171 | | +--------+ | | | | |Software | | 172 | | | | | | +------------+ | 173 | +-v----------------v-+ | | | | 174 | | EAP | | +---|--------------------+ 175 | | Infrastructure | | | 176 | +--------------------+ | | +--------+ 177 +-------------------------+ | | AAA | 178 | | Server | 179 +----- | 180 +--------+ 182 The above diagram shows the typical deployment. The client has 183 software that either includes a UI for some EAP methods, or else is 184 able to invoke some operating system EAP infrastructure that takes 185 care of the user interaction. The server is configured with the 186 address and protocol of the AAA server. Typically the AAA server 187 communicates using the RADIUS protocol with EAP ([RADIUS] and 188 [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]). 190 As stated in the introduction, we expect TEE to be used in both 191 browsers and applications. Further uses may be authentication and 192 key generation for other protocols, and tunneling clients, which so 193 far have not been standardized. 195 3. Protocol Overview 197 The TEE extension defines the following: 198 o A new extension type called tee_supported, used to indicate that 199 the client supports this extension. 200 o A new message type for the handshake protocol, called InterimAuth, 201 which is used to sign previous messages. 202 o A new message type for the handshake protocol, called EapMsg, 203 which is used to carry a single EAP message. 205 The diagram below outlines the protocol structure. For illustration 206 purposes only, we use the MSCHAPv2 EAP method 207 [I-D.dpotter-pppext-eap-mschap]. 209 Client Server 210 ------ ------ 212 ClientHello(*) --------> 213 ServerHello(*) 214 (Certificate) 215 ServerKeyExchange 216 EapMsg(Identity-Request) 217 <-------- ServerHelloDone 218 ClientKeyExchange 219 (CertificateVerify) 220 ChangeCipherSpec 221 InterimAuth 222 EapMsg(Identity-Reply) --------> 223 ChangeCipherSpec 224 InterimAuth 225 EapMsg(MS-CHAP-v2-Request) 226 <-------- 227 EapMsg(MS-CHAP-v2-Reply) --------> 228 EapMsg(Success) 229 <-------- Finished 230 Finished --------> 232 (*) The ClientHello and ServerHello include the tee_supported 233 extension to indicate support for TEE 235 The client indicates in the first message its support for TEE. The 236 server sends an EAP identity request in the reply. The client sends 237 the identity reply after the handshake completion. The EAP request- 238 response sequence continues until the client is either authenticated 239 or rejected. 241 3.1. The tee_supported Extension 243 The tee_supported extension is a ClientHello and ServerHello 244 extension as defined in section 2.3 of [TLS-EXT]. The extension_type 245 field is TBA by IANA. The extension_data is zero-length. 247 3.2. The InterimAuth Handshake Message 249 The InterimAuth message is identical in syntax to the Finished 250 message described in section 7.4.9 of [TLS]. It is calculated in 251 exactly the same way. 253 The semantics, however, are somewhat different. The "Finished" 254 message indicates that application data may now be sent. The 255 "InterimAuth" message does not indicate this. Instead, further 256 handshake messages are needed. 258 The HandshakeType value for the InterimAuth handshake message is TBA 259 by IANA. 261 3.3. The EapMsg Handshake Message 263 The EapMsg handshake message carries exactly one EAP message as 264 defined in [EAP]. 266 The HandshakeType value for the EapMsg handshake message is TBA by 267 IANA. 269 The EapMsg message is used to tunnel EAP messages between the 270 authentication server, which may be co-located with the TLS server, 271 or else may be a separate AAA server, and the supplicant, which is 272 co-located with the TLS client. TLS on either side receives the EAP 273 data from the EAP infrastructure, and treats it as opaque. TLS does 274 not make any changes to the EAP payload or make any decisions based 275 on the contents of an EapMsg handshake message. 277 Note that it is expected that the authentication server notifies the 278 TLS server about authentication success or failure, and so TLS need 279 not inspect the eap_payload within the EapMsg to detect success or 280 failure. 282 struct { 283 opaque eap_payload[4..65535]; 284 } EapMsg; 286 eap_payload is defined in section 4 of RFC 3748. It includes 287 the Code, Identifier, Length and Data fields of the EAP 288 packet. 290 3.4. Calculating the Finished message 292 If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the 293 Finished message is calculated as follows: 295 struct { 296 opaque verify_data[12]; 297 } Finished; 299 verify_data 300 PRF(MSK, finished_label, MD5(handshake_messages) + 301 SHA-1(handshake_messages)) [0..11]; 303 The finished_label and the PRF are as defined in section 7.4.9 of 304 [TLS]. 306 The handshake_messages field, similar to regular TLS, comprises all 307 of the data from all messages in this handshake, including any EapMsg 308 and InterimAuth messages, up to but not including this Finished 309 message. This is the concatenation of all the Handshake structures 310 exchanged thus far, as defined in section 7.4 of [TLS]. 312 The Master Session Key (MSK) is derived by the AAA server and by the 313 client if the EAP method is key-generating. On the server-side, it 314 is typically received from the AAA server over the RADIUS or Diameter 315 protocol. On the client-side, it is passed to TLS by some other 316 method. 318 If the EAP method is not key-generating, then the Finished message is 319 calculated exactly as described in [TLS]. For a discussion on the 320 use of such methods, see Section 4.1. 322 4. Security Considerations 324 4.1. InterimAuth vs. Finished 326 In regular TLS, the Finished message provides two functions: it signs 327 all preceding messages, and it signals that application data can now 328 be sent. In TEE, some of the messages are signed twice. 330 Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate 331 keys in addition to authenticating clients. Such methods are said to 332 be resistant to man-in-the-middle (MITM) attacks as discussed in 333 [MITM]. Such methods are called key-generating methods. 335 To realize the benefit of such methods, we need to verify the key 336 that was generated within the EAP method. This is referred to as the 337 MSK in EAP. In TEE, the InterimAuth message signs all previous 338 messages with the master_secret, just like the Finished message in 339 regular TLS. The Finished message signs all previous messages using 340 the MSK if such exists. If not, then the messages are signed with 341 the master_secret as in regular TLS. 343 The need for signing twice arises from the fact that we need to use 344 both the master_secret and the MSK. It was possible to use just one 345 Finished record and blend the MSK into the master_secret. However, 346 this would needlessly complicate the protocol and make security 347 analysis more difficult. Instead, we have decided to follow the 348 example of IKEv2, where two AUTH payloads are exchanged. 350 It should be noted that using non-key-generating methods may expose 351 the client to a MITM attack if the same method and credentials are 352 used in some other situation, in which the EAP is done outside of a 353 protected tunnel with an authenticated server. Unless it can be 354 determined that the EAP method is never used in such a situation, 355 non-key-generating methods SHOULD NOT be used. 357 4.2. Identity Protection 359 Unlike [TLS-PSK], TEE provides identity protection for the client. 360 The client's identity is hidden from a passive eavesdropper using TLS 361 encryption. Active attacks are discussed in Section 4.3. 363 We could save one round-trip by having the client send its identity 364 within the Client Hello message. This is similar to TLS-PSK. 365 However, we believe that identity protection is a worthy enough goal, 366 so as to justify the extra round-trip. 368 4.3. Mutual Authentication 370 In order to achieve our security goals, we need to have both the 371 server and the client authenticate. Client authentication is 372 obviously done using the EAP method. The server authentication can 373 be done in either of two ways: 374 1. The client can verify the server certificate. This may work well 375 depending on the scenario, but implies that the client or its 376 user can recognize the right DN or alternate name, and 377 distinguish it from plausible alternatives. The introduction to 378 [I.D.Webauth-phishing] shows that at least in HTTPS, this is not 379 always the case. 380 2. The client can use a mutually authenticated (MA) EAP method such 381 as MS-CHAPv2. In this case, server certificate verification does 382 not matter, and the TLS handshake may as well be anonymous. Note 383 that in this case, the client identity is sent to the server 384 before server authentication. 386 To summarize: 387 o Clients MUST NOT propose anonymous ciphersuites, unless they 388 support MA EAP methods. 389 o Servers MUST NOT accept anonymous ciphersuites, unless they 390 support MA EAP methods. If they support both MA and non-MA 391 methods, they SHOULD prefer to use the MA methods. 392 o Clients MUST NOT accept non-MA methods if the ciphersuite is 393 anonymous. 394 o Clients MUST NOT accpet non-MA mehtods if they are not able to 395 verify the server credentials. Note that this document does not 396 define what verification involves. If the server DN is known and 397 stored on the client, verifying certificate signature and checking 398 revocation may be enough. For web browsers, the case is not as 399 clear cut, and MA methods SHOULD be used. 401 5. Performance Considerations 403 Regular TLS adds two round-trips to a TCP connection. However, 404 because of the stream nature of TCP, the client does not really need 405 to wait for the server's Finished message, and can begin sending 406 application data immediately after its own Finished message. In 407 practice, many clients do so, and TLS only adds one round-trip of 408 delay. 410 TEE adds as many round-trips as the EAP method requires. For 411 example, EAP-MD5 requires 1 round-trip, while EAP-SIM requires 2 412 round-trips. Additionally, the client MUST wait for the EAP-Success 413 message before sending its own Finished message, so we need at least 414 3 round-trips for the entire handshake. The best a client can do is 415 two round-trips plus however many round-trips the EAP method 416 requires. 418 It should be noted, though, that these extra round-trips save 419 processing time at the application level. Two extra round-trips take 420 a lot less time than presenting a log-in web page and processing the 421 user's input. 423 It should also be noted, that TEE reverses the order of the Finished 424 messages. In regular TLS the client sends the Finished message 425 first. In TEE it is the server that sends the Finished message 426 first. This should not affect performance, and it is clear that the 427 client may send application data immediately after the Finished 428 message. 430 6. Operational Considerations 432 Section 4.3 defines a dependency between the TLS state and the EAP 433 state in that it mandates that certain EAP methods should not be used 434 with certain TLS ciphersuites. To avoid such dependencies, there are 435 two approaches that implementations can take. They can either not 436 use any anonymous ciphersuites, or else they can use only MA EAP 437 methods. 439 Where certificate validation is problematic, such as in browser-based 440 HTTPS, we recommend the latter approach. 442 In cases where the use of EAP within TLS is not known before opening 443 the connection, it is necessary to consider the implications of 444 requiring the user to type in credentials after the connection has 445 already started. TCP sessions may time out, because of security 446 considerations, and this may lead to session setup failure. 448 7. IANA Considerations 450 IANA is asked to assign an extension type value from the 451 "ExtensionType Values" registry for the tee_supported extension. 453 IANA is asked to assign two handshake message types from the "TLS 454 HandshakeType Registry", one for "EapMsg" and one for "InterimAuth". 456 8. Acknowledgments 458 The TLS Inner Application Extension work ([TLS/IA]) has inspired the 459 authors to create this simplified work. TLS/IA provides a somewhat 460 different approach to integrating non-certificate credentials into 461 the TLS protocol, in addition to several other features available 462 from the RADIUS namespace. 464 The authors would also like to thank the various contributors to 465 [RFC4306] whose work inspired this one. 467 9. Changes from Previous Versions 469 9.1. Changes from the protocol model draft 471 o Added diagram for EapMsg 472 o Added discussion of EAP applicability 473 o Added discussion of mutually-authenticated EAP methods vs other 474 methods in the security considerations. 475 o Added operational considerations. 476 o Other minor nits. 478 10. References 480 10.1. Normative References 482 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 483 Levkowetz, "Extensible Authentication Protocol (EAP)", 484 RFC 3748, June 2004. 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 490 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 492 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 493 and T. Wright, "Transport Layer Security (TLS) 494 Extensions", RFC 4366, April 2006. 496 10.2. Informative References 498 [Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 499 Authentication Protocol (EAP) Application", RFC 4072, 500 August 2005. 502 [Diameter] 503 Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 504 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 506 [I-D.dpotter-pppext-eap-mschap] 507 Potter, D. and J. Zamick, "PPP EAP MS-CHAP-V2 508 Authentication Protocol", 509 draft-dpotter-pppext-eap-mschap-01 (work in progress), 510 January 2002. 512 [I-D.ietf-eap-keying] 513 Aboba, B., "Extensible Authentication Protocol (EAP) Key 514 Management Framework", draft-ietf-eap-keying-18 (work in 515 progress), February 2007. 517 [I.D.Webauth-phishing] 518 Hartman, S., "Requirements for Web Authentication 519 Resistant to Phishing", draft-hartman-webauth-phishing-03 520 (work in progress), March 2007. 522 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 523 in Tunneled Authentication Protocols", October 2002. 525 [RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 526 Dial In User Service) Support For Extensible 527 Authentication Protocol (EAP)", RFC 3579, September 2003. 529 [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 530 "Remote Authentication Dial In User Service (RADIUS)", 531 RFC 2865, June 2000. 533 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 534 RFC 4306, December 2005. 536 [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 537 for Transport Layer Security (TLS)", RFC 4279, 538 December 2005. 540 [TLS/IA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and 541 T. Hardjono, "TLS Inner Application Extension (TLS/IA)", 542 draft-funk-tls-inner-application-extension-03 (work in 543 progress), June 2006. 545 Authors' Addresses 547 Yoav Nir 548 Check Point Software Technologies Ltd. 549 5 Hasolelim st. 550 Tel Aviv 67897 551 Israel 553 Email: ynir@checkpoint.com 555 Yaron Sheffer 556 Check Point Software Technologies Ltd. 557 5 Hasolelim st. 558 Tel Aviv 67897 559 Israel 561 Email: yaronf at checkpoint dot com 563 Hannes Tschofenig 564 Nokia Siemens Networks 565 Otto-Hahn-Ring 6 566 Munich, Bavaria 81739 567 Germany 569 Email: Hannes.Tschofenig@siemens.com 570 URI: http://www.tschofenig.com 572 Peter Gutmann 573 University of Auckland 574 Department of Computer Science 575 New Zealand 577 Email: pgut001@cs.auckland.ac.nz 579 Full Copyright Statement 581 Copyright (C) The IETF Trust (2007). 583 This document is subject to the rights, licenses and restrictions 584 contained in BCP 78, and except as set forth therein, the authors 585 retain all their rights. 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, THE IETF TRUST AND 590 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 591 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 592 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 Intellectual Property 597 The IETF takes no position regarding the validity or scope of any 598 Intellectual Property Rights or other rights that might be claimed to 599 pertain to the implementation or use of the technology described in 600 this document or the extent to which any license under such rights 601 might or might not be available; nor does it represent that it has 602 made any independent effort to identify any such rights. Information 603 on the procedures with respect to rights in RFC documents can be 604 found in BCP 78 and BCP 79. 606 Copies of IPR disclosures made to the IETF Secretariat and any 607 assurances of licenses to be made available, or the result of an 608 attempt made to obtain a general license or permission for the use of 609 such proprietary rights by implementers or users of this 610 specification can be obtained from the IETF on-line IPR repository at 611 http://www.ietf.org/ipr. 613 The IETF invites any interested party to bring to its attention any 614 copyrights, patents or patent applications, or other proprietary 615 rights that may cover technology that may be required to implement 616 this standard. Please address the information to the IETF at 617 ietf-ipr@ietf.org. 619 Acknowledgment 621 Funding for the RFC Editor function is provided by the IETF 622 Administrative Support Activity (IASA).