diff options
Diffstat (limited to 'doc/protocol/draft-nir-tls-eap-00.txt')
| -rw-r--r-- | doc/protocol/draft-nir-tls-eap-00.txt | 1120 |
1 files changed, 0 insertions, 1120 deletions
diff --git a/doc/protocol/draft-nir-tls-eap-00.txt b/doc/protocol/draft-nir-tls-eap-00.txt deleted file mode 100644 index d740f04917..0000000000 --- a/doc/protocol/draft-nir-tls-eap-00.txt +++ /dev/null @@ -1,1120 +0,0 @@ - - - -TLS Working Group Y. Nir -Internet-Draft Y. Sheffer -Intended status: Standards Track Check Point -Expires: December 9, 2007 H. Tschofenig - NSN - P. Gutmann - University of Auckland - June 7, 2007 - - - TLS using EAP Authentication - draft-nir-tls-eap-00.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on December 9, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 1] - -Internet-Draft EAP-in-TLS June 2007 - - -Abstract - - This document describes an extension to the TLS protocol to allow TLS - clients to authenticate with legacy credentials using the Extensible - Authentication Protocol (EAP). - - This work follows the example of IKEv2, where EAP has been added to - the IKEv2 protocol to allow clients to use different credentials such - as passwords, token cards, and shared secrets. - - When TLS is used with EAP, additional records are sent after the - ChangeCipherSpec protocol message and before the Finished message, - effectively creating an extended handshake before the application - layer data can be sent. Each EapMsg handshake record contains - exactly one EAP message. Using EAP for client authentication allows - TLS to be used with various AAA back-end servers such as RADIUS or - Diameter. - - TLS with EAP may be used for securing a data connection such as HTTP - or POP3. We believe it has three main benefits: - o The ability of EAP to work with backend servers can remove that - burden from the application layer. - o Moving the user authentication into the TLS handshake protects the - presumably less secure application layer from attacks by - unauthenticated parties. - o Using mutual authentication methods within EAP can help thwart - certain classes of phishing attacks. - - - - - - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 2] - -Internet-Draft EAP-in-TLS June 2007 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. EAP Applicability . . . . . . . . . . . . . . . . . . . . 5 - 1.2. Conventions Used in This Document . . . . . . . . . . . . 5 - 2. Operating Environment . . . . . . . . . . . . . . . . . . . . 6 - 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1. The tee_supported Extension . . . . . . . . . . . . . . . 8 - 3.2. The InterimAuth Handshake Message . . . . . . . . . . . . 8 - 3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 8 - 3.4. Calculating the Finished message . . . . . . . . . . . . . 9 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10 - 4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10 - 4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 11 - 5. Performance Considerations . . . . . . . . . . . . . . . . . . 12 - 6. Operational Considerations . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - 9. Changes from Previous Versions . . . . . . . . . . . . . . . . 16 - 9.1. Changes from the protocol model draft . . . . . . . . . . 16 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 - Intellectual Property and Copyright Statements . . . . . . . . . . 20 - - - - - - - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 3] - -Internet-Draft EAP-in-TLS June 2007 - - -1. Introduction - - This document describes a new extension to [TLS]. This extension - allows a TLS client to authenticate using [EAP] instead of performing - the authentication at the application level. The extension follows - [TLS-EXT]. For the remainder of this document we will refer to this - extension as TEE (TLS with EAP Extension). - - TEE extends the TLS handshake beyond the regular setup, to allow the - EAP protocol to run between the TLS server (called an "authenticator" - in EAP) and the TLS client (called a "supplicant"). This allows the - TLS architecture to handle client authentication before exposing the - server application software to an unauthenticated client. In doing - this, we follow the approach taken for IKEv2 in [RFC4306]. However, - similar to regular TLS, we protect the user identity by only sending - the client identity after the server has authenticated. In this our - solution differs from that of IKEv2. - - Currently used applications that rely on non-certificate user - credentials use TLS to authenticate the server only. After that, the - application takes over, and presents a login screen where the user is - expected to present their credentials. - - This creates several problems. It allows a client to access the - application before authentication, thus creating a potential for - anonymous attacks on non-hardened applications. Additionally, web - pages are not particularly well suited for long shared secrets and - for interfacing with certain devices such as USB tokens. - - TEE allows full mutual authentication to occur for all these - applications within the TLS exchange. The application receives - control only when the user is identified and authenticated. The - authentication can be built into the server infrastructure by - connecting to an AAA server. The client side can be integrated into - client software such as web browsers and mail clients. An EAP - infrastructure is already built into some operating systems providing - a user interface for each authentication method within EAP. - - We intend TEE to be used for various protocols that use TLS such as - HTTPS, in cases where certificate based client authentication is not - practical. This includes web-based mail services, online banking, - premium content websites and mail clients. - - Another class of applications that may see benefit from TEE are TLS - based VPN clients used as part of so-called "SSL VPN" products. No - such client protocols have so far been standardized. - - - - - -Nir, et al. Expires December 9, 2007 [Page 4] - -Internet-Draft EAP-in-TLS June 2007 - - -1.1. EAP Applicability - - Section 1.3 of [EAP] states that EAP is only applicable for network - access authentication, rather than for "bulk data transfer". It then - goes on to explain why the transport properties of EAP indeed make it - unsuitable for bulk data transfer, e.g. for large file transport. - Our proposed use of EAP falls squarely within the applicability as - defined, since we make no further use of EAP beyond access - authentication. - -1.2. Conventions Used in This Document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 5] - -Internet-Draft EAP-in-TLS June 2007 - - -2. Operating Environment - - TEE will work between a client application and a server application, - performing either client authentication or mutual authentication - within the TLS exchange. - - - Client Server - +-------------------------+ +------------------------+ - | |GUI| | Client | |TLS+-+-----+-+TLS| |Server | | - | +-^-+ |Software| +-^-+ | +-+-^-+ |Application | | - | | +--------+ | | | | |Software | | - | | | | | | +------------+ | - | +-v----------------v-+ | | | | - | | EAP | | +---|--------------------+ - | | Infrastructure | | | - | +--------------------+ | | +--------+ - +-------------------------+ | | AAA | - | | Server | - +----- | - +--------+ - - The above diagram shows the typical deployment. The client has - software that either includes a UI for some EAP methods, or else is - able to invoke some operating system EAP infrastructure that takes - care of the user interaction. The server is configured with the - address and protocol of the AAA server. Typically the AAA server - communicates using the RADIUS protocol with EAP ([RADIUS] and - [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]). - - As stated in the introduction, we expect TEE to be used in both - browsers and applications. Further uses may be authentication and - key generation for other protocols, and tunneling clients, which so - far have not been standardized. - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 6] - -Internet-Draft EAP-in-TLS June 2007 - - -3. Protocol Overview - - The TEE extension defines the following: - o A new extension type called tee_supported, used to indicate that - the client supports this extension. - o A new message type for the handshake protocol, called InterimAuth, - which is used to sign previous messages. - o A new message type for the handshake protocol, called EapMsg, - which is used to carry a single EAP message. - - The diagram below outlines the protocol structure. For illustration - purposes only, we use the MSCHAPv2 EAP method - [I-D.dpotter-pppext-eap-mschap]. - - Client Server - ------ ------ - - ClientHello(*) --------> - ServerHello(*) - (Certificate) - ServerKeyExchange - EapMsg(Identity-Request) - <-------- ServerHelloDone - ClientKeyExchange - (CertificateVerify) - ChangeCipherSpec - InterimAuth - EapMsg(Identity-Reply) --------> - ChangeCipherSpec - InterimAuth - EapMsg(MS-CHAP-v2-Request) - <-------- - EapMsg(MS-CHAP-v2-Reply) --------> - EapMsg(Success) - <-------- Finished - Finished --------> - - (*) The ClientHello and ServerHello include the tee_supported - extension to indicate support for TEE - - - The client indicates in the first message its support for TEE. The - server sends an EAP identity request in the reply. The client sends - the identity reply after the handshake completion. The EAP request- - response sequence continues until the client is either authenticated - or rejected. - - - - - -Nir, et al. Expires December 9, 2007 [Page 7] - -Internet-Draft EAP-in-TLS June 2007 - - -3.1. The tee_supported Extension - - The tee_supported extension is a ClientHello and ServerHello - extension as defined in section 2.3 of [TLS-EXT]. The extension_type - field is TBA by IANA. The extension_data is zero-length. - -3.2. The InterimAuth Handshake Message - - The InterimAuth message is identical in syntax to the Finished - message described in section 7.4.9 of [TLS]. It is calculated in - exactly the same way. - - The semantics, however, are somewhat different. The "Finished" - message indicates that application data may now be sent. The - "InterimAuth" message does not indicate this. Instead, further - handshake messages are needed. - - The HandshakeType value for the InterimAuth handshake message is TBA - by IANA. - -3.3. The EapMsg Handshake Message - - The EapMsg handshake message carries exactly one EAP message as - defined in [EAP]. - - The HandshakeType value for the EapMsg handshake message is TBA by - IANA. - - The EapMsg message is used to tunnel EAP messages between the - authentication server, which may be co-located with the TLS server, - or else may be a separate AAA server, and the supplicant, which is - co-located with the TLS client. TLS on either side receives the EAP - data from the EAP infrastructure, and treats it as opaque. TLS does - not make any changes to the EAP payload or make any decisions based - on the contents of an EapMsg handshake message. - - Note that it is expected that the authentication server notifies the - TLS server about authentication success or failure, and so TLS need - not inspect the eap_payload within the EapMsg to detect success or - failure. - - struct { - opaque eap_payload[4..65535]; - } EapMsg; - - eap_payload is defined in section 4 of RFC 3748. It includes - the Code, Identifier, Length and Data fields of the EAP - packet. - - - -Nir, et al. Expires December 9, 2007 [Page 8] - -Internet-Draft EAP-in-TLS June 2007 - - -3.4. Calculating the Finished message - - If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the - Finished message is calculated as follows: - - struct { - opaque verify_data[12]; - } Finished; - - verify_data - PRF(MSK, finished_label, MD5(handshake_messages) + - SHA-1(handshake_messages)) [0..11]; - - The finished_label and the PRF are as defined in section 7.4.9 of - [TLS]. - - The handshake_messages field, similar to regular TLS, comprises all - of the data from all messages in this handshake, including any EapMsg - and InterimAuth messages, up to but not including this Finished - message. This is the concatenation of all the Handshake structures - exchanged thus far, as defined in section 7.4 of [TLS]. - - The Master Session Key (MSK) is derived by the AAA server and by the - client if the EAP method is key-generating. On the server-side, it - is typically received from the AAA server over the RADIUS or Diameter - protocol. On the client-side, it is passed to TLS by some other - method. - - If the EAP method is not key-generating, then the Finished message is - calculated exactly as described in [TLS]. For a discussion on the - use of such methods, see Section 4.1. - - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 9] - -Internet-Draft EAP-in-TLS June 2007 - - -4. Security Considerations - -4.1. InterimAuth vs. Finished - - In regular TLS, the Finished message provides two functions: it signs - all preceding messages, and it signals that application data can now - be sent. In TEE, some of the messages are signed twice. - - Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate - keys in addition to authenticating clients. Such methods are said to - be resistant to man-in-the-middle (MITM) attacks as discussed in - [MITM]. Such methods are called key-generating methods. - - To realize the benefit of such methods, we need to verify the key - that was generated within the EAP method. This is referred to as the - MSK in EAP. In TEE, the InterimAuth message signs all previous - messages with the master_secret, just like the Finished message in - regular TLS. The Finished message signs all previous messages using - the MSK if such exists. If not, then the messages are signed with - the master_secret as in regular TLS. - - The need for signing twice arises from the fact that we need to use - both the master_secret and the MSK. It was possible to use just one - Finished record and blend the MSK into the master_secret. However, - this would needlessly complicate the protocol and make security - analysis more difficult. Instead, we have decided to follow the - example of IKEv2, where two AUTH payloads are exchanged. - - It should be noted that using non-key-generating methods may expose - the client to a MITM attack if the same method and credentials are - used in some other situation, in which the EAP is done outside of a - protected tunnel with an authenticated server. Unless it can be - determined that the EAP method is never used in such a situation, - non-key-generating methods SHOULD NOT be used. - -4.2. Identity Protection - - Unlike [TLS-PSK], TEE provides identity protection for the client. - The client's identity is hidden from a passive eavesdropper using TLS - encryption. Active attacks are discussed in Section 4.3. - - We could save one round-trip by having the client send its identity - within the Client Hello message. This is similar to TLS-PSK. - However, we believe that identity protection is a worthy enough goal, - so as to justify the extra round-trip. - - - - - - -Nir, et al. Expires December 9, 2007 [Page 10] - -Internet-Draft EAP-in-TLS June 2007 - - -4.3. Mutual Authentication - - In order to achieve our security goals, we need to have both the - server and the client authenticate. Client authentication is - obviously done using the EAP method. The server authentication can - be done in either of two ways: - 1. The client can verify the server certificate. This may work well - depending on the scenario, but implies that the client or its - user can recognize the right DN or alternate name, and - distinguish it from plausible alternatives. The introduction to - [I.D.Webauth-phishing] shows that at least in HTTPS, this is not - always the case. - 2. The client can use a mutually authenticated (MA) EAP method such - as MS-CHAPv2. In this case, server certificate verification does - not matter, and the TLS handshake may as well be anonymous. Note - that in this case, the client identity is sent to the server - before server authentication. - - To summarize: - o Clients MUST NOT propose anonymous ciphersuites, unless they - support MA EAP methods. - o Servers MUST NOT accept anonymous ciphersuites, unless they - support MA EAP methods. If they support both MA and non-MA - methods, they SHOULD prefer to use the MA methods. - o Clients MUST NOT accept non-MA methods if the ciphersuite is - anonymous. - o Clients MUST NOT accpet non-MA mehtods if they are not able to - verify the server credentials. Note that this document does not - define what verification involves. If the server DN is known and - stored on the client, verifying certificate signature and checking - revocation may be enough. For web browsers, the case is not as - clear cut, and MA methods SHOULD be used. - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 11] - -Internet-Draft EAP-in-TLS June 2007 - - -5. Performance Considerations - - Regular TLS adds two round-trips to a TCP connection. However, - because of the stream nature of TCP, the client does not really need - to wait for the server's Finished message, and can begin sending - application data immediately after its own Finished message. In - practice, many clients do so, and TLS only adds one round-trip of - delay. - - TEE adds as many round-trips as the EAP method requires. For - example, EAP-MD5 requires 1 round-trip, while EAP-SIM requires 2 - round-trips. Additionally, the client MUST wait for the EAP-Success - message before sending its own Finished message, so we need at least - 3 round-trips for the entire handshake. The best a client can do is - two round-trips plus however many round-trips the EAP method - requires. - - It should be noted, though, that these extra round-trips save - processing time at the application level. Two extra round-trips take - a lot less time than presenting a log-in web page and processing the - user's input. - - It should also be noted, that TEE reverses the order of the Finished - messages. In regular TLS the client sends the Finished message - first. In TEE it is the server that sends the Finished message - first. This should not affect performance, and it is clear that the - client may send application data immediately after the Finished - message. - - - - - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 12] - -Internet-Draft EAP-in-TLS June 2007 - - -6. Operational Considerations - - Section 4.3 defines a dependency between the TLS state and the EAP - state in that it mandates that certain EAP methods should not be used - with certain TLS ciphersuites. To avoid such dependencies, there are - two approaches that implementations can take. They can either not - use any anonymous ciphersuites, or else they can use only MA EAP - methods. - - Where certificate validation is problematic, such as in browser-based - HTTPS, we recommend the latter approach. - - In cases where the use of EAP within TLS is not known before opening - the connection, it is necessary to consider the implications of - requiring the user to type in credentials after the connection has - already started. TCP sessions may time out, because of security - considerations, and this may lead to session setup failure. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 13] - -Internet-Draft EAP-in-TLS June 2007 - - -7. IANA Considerations - - IANA is asked to assign an extension type value from the - "ExtensionType Values" registry for the tee_supported extension. - - IANA is asked to assign two handshake message types from the "TLS - HandshakeType Registry", one for "EapMsg" and one for "InterimAuth". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 14] - -Internet-Draft EAP-in-TLS June 2007 - - -8. Acknowledgments - - The TLS Inner Application Extension work ([TLS/IA]) has inspired the - authors to create this simplified work. TLS/IA provides a somewhat - different approach to integrating non-certificate credentials into - the TLS protocol, in addition to several other features available - from the RADIUS namespace. - - The authors would also like to thank the various contributors to - [RFC4306] whose work inspired this one. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 15] - -Internet-Draft EAP-in-TLS June 2007 - - -9. Changes from Previous Versions - -9.1. Changes from the protocol model draft - - o Added diagram for EapMsg - o Added discussion of EAP applicability - o Added discussion of mutually-authenticated EAP methods vs other - methods in the security considerations. - o Added operational considerations. - o Other minor nits. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 16] - -Internet-Draft EAP-in-TLS June 2007 - - -10. References - -10.1. Normative References - - [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. - Levkowetz, "Extensible Authentication Protocol (EAP)", - RFC 3748, June 2004. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.1", RFC 4346, April 2006. - - [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., - and T. Wright, "Transport Layer Security (TLS) - Extensions", RFC 4366, April 2006. - -10.2. Informative References - - [Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible - Authentication Protocol (EAP) Application", RFC 4072, - August 2005. - - [Diameter] - Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. - Arkko, "Diameter Base Protocol", RFC 3588, September 2003. - - [I-D.dpotter-pppext-eap-mschap] - Potter, D. and J. Zamick, "PPP EAP MS-CHAP-V2 - Authentication Protocol", - draft-dpotter-pppext-eap-mschap-01 (work in progress), - January 2002. - - [I-D.ietf-eap-keying] - Aboba, B., "Extensible Authentication Protocol (EAP) Key - Management Framework", draft-ietf-eap-keying-18 (work in - progress), February 2007. - - [I.D.Webauth-phishing] - Hartman, S., "Requirements for Web Authentication - Resistant to Phishing", draft-hartman-webauth-phishing-03 - (work in progress), March 2007. - - [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle - in Tunneled Authentication Protocols", October 2002. - - [RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication - - - -Nir, et al. Expires December 9, 2007 [Page 17] - -Internet-Draft EAP-in-TLS June 2007 - - - Dial In User Service) Support For Extensible - Authentication Protocol (EAP)", RFC 3579, September 2003. - - [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, - "Remote Authentication Dial In User Service (RADIUS)", - RFC 2865, June 2000. - - [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", - RFC 4306, December 2005. - - [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites - for Transport Layer Security (TLS)", RFC 4279, - December 2005. - - [TLS/IA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and - T. Hardjono, "TLS Inner Application Extension (TLS/IA)", - draft-funk-tls-inner-application-extension-03 (work in - progress), June 2006. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 18] - -Internet-Draft EAP-in-TLS June 2007 - - -Authors' Addresses - - Yoav Nir - Check Point Software Technologies Ltd. - 5 Hasolelim st. - Tel Aviv 67897 - Israel - - Email: ynir@checkpoint.com - - - Yaron Sheffer - Check Point Software Technologies Ltd. - 5 Hasolelim st. - Tel Aviv 67897 - Israel - - Email: yaronf at checkpoint dot com - - - Hannes Tschofenig - Nokia Siemens Networks - Otto-Hahn-Ring 6 - Munich, Bavaria 81739 - Germany - - Email: Hannes.Tschofenig@siemens.com - URI: http://www.tschofenig.com - - - Peter Gutmann - University of Auckland - Department of Computer Science - New Zealand - - Email: pgut001@cs.auckland.ac.nz - - - - - - - - - - - - - - - -Nir, et al. Expires December 9, 2007 [Page 19] - -Internet-Draft EAP-in-TLS June 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Nir, et al. Expires December 9, 2007 [Page 20] - |