From 7c72857fb40aadc52546ec676bf6750cd58b741a Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Mon, 11 Jun 2007 22:10:52 +0200 Subject: [PATCH] Add. --- doc/protocol/draft-nir-tls-eap-00.txt | 1120 +++++++++++++++++++++++++++++++++ 1 file changed, 1120 insertions(+) create mode 100644 doc/protocol/draft-nir-tls-eap-00.txt diff --git a/doc/protocol/draft-nir-tls-eap-00.txt b/doc/protocol/draft-nir-tls-eap-00.txt new file mode 100644 index 000000000..d740f0491 --- /dev/null +++ b/doc/protocol/draft-nir-tls-eap-00.txt @@ -0,0 +1,1120 @@ + + + +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] + -- 2.11.4.GIT