Network Working Group T. Hiller Internet-Draft Lucent Technologies Category: Standards Track G. Zorn <draft-ietf-aaa-eap-01.txt> Cisco Systems March 2003 Diameter Extensible Authentication Protocol (EAP) Application Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. The distribution of this memo is unlimited. It is filed as <draft- ietf-aaa-eap-01.txt> and expires September 2, 2003. Please send comments to the AAA Working Group mailing list (aaa-wg@merit.edu) or to the authors (tom.hiller@lucent.com and gwz@cisco.com). Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary for a Diameter Hiller & Zorn [Page 1]
INTERNET-DRAFT Diameter EAP Application March 2003 node to support the PPP Extensible Authentication Protocol (EAP). 1. 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 RFC 2119. 2. Extensible Authentication Protocol Support in Diameter The Extensible Authentication Protocol (EAP) [RFC2284] provides a standard mechanism for support of various authentication methods. Through the use of EAP, support for a number of authentication schemes may be added, including smart and token cards, Kerberos [RFC1510], public-key, one-time passwords [RFC1938], and others. This document describes the Command-Code values and AVPs that are required for an EAP packet to be encapsulated within the Diameter protocol. Since authentication occurs between the EAP client and its home Diameter server, end-to-end authentication is achieved, reducing the possibility for fraudulent authentication, such as replay and man-in-the-middle attacks. End-to-end authentication also provides for mutual (bi-directional) authentication, which is not possible with PAP and CHAP in a roaming PPP environment. 2.1. Protocol Overview The EAP conversation between the authenticating peer and the access device begins with the initiation of EAP within a link layer, such as PPP [STD51] or IEEE 802.1x [IEEE802.1x]. Once EAP has been initiated, the access device will typically send to the Diameter server a Diameter-EAP-Request message with a NULL EAP-Payload AVP, signifying an EAP-Start. The Port number and the identity of the access device (e.g. Origin-Host or NAS-Identifier) MUST be included in the Diameter-EAP-Request message. If the Diameter home server supports EAP, it MUST respond with a Diameter-EAP-Answer message containing an EAP-Payload AVP that includes an encapsulated EAP packet [RFC2284], and the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent request is expected. The EAP payload is forwarded by the access device to the EAP client. The initial Diameter-EAP-Answer in a multi-round exchange normally includes an EAP-Request/Identity, requesting the EAP client to Hiller & Zorn [Page 2]
INTERNET-DRAFT Diameter EAP Application March 2003 identify itself. Upon receipt of the EAP client's EAP-Response [RFC2284], the access device will then issue a second Diameter-EAP- Request message, with the client's EAP payload encapsulated within the EAP-Payload AVP. A preferred approach is for the access device to issue the EAP- Request/Identity message to the EAP client, and forward the EAP- Response/Identity packet, encapsulated within the EAP-Payload AVP, as a Diameter-EAP-Request to the Diameter server. This alternative reduces the number of Diameter message round trips, and is compatible with roaming environments, since the Destination-Realm is needed by Diameter agents for routing purposes. Note that this alternative cannot be universally employed, as there are circumstances where a user's identity is not needed (such as when authorization occurs based on a calling or called phone number). The conversation continues until the Diameter server sends a Diameter-EAP-Answer with a Result-Code AVP indicating success or failure, and an optional EAP-Payload. The Result-Code AVP is used by the access device to determine whether service is to be provided to the EAP client. The access device MUST NOT rely on the contents of the optional EAP-Payload to determine whether service is to be provided. A Diameter-EAP-Answer message containing an EAP-Payload of type EAP- Success or EAP-Failure MUST NOT have the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. If authorization was requested, a Diameter-EAP-Answer signifying successful authentication MUST also include the appropriate authorization AVPs required for the service requested (see sections 4 and 7). Diameter-EAP-Answer messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs. Unless the access device interprets the EAP-Response/Identity packet returned by the authenticating peer, it will not have access to the user's identity. Therefore, the Diameter Server SHOULD return the user's identity by inserting it in the User-Name attribute of subsequent Diameter-EAP-Answer packets. Without the user's identity, the Session-Id AVP MAY be used for accounting and billing, however operationally this MAY be very difficult to manage. A home Diameter server MAY request EAP re-authentication by issuing the Re-Auth-Request [BASE] message to the Diameter client. Should an EAP authentication session be interrupted due to a home server failure, the session MAY be directed to an alternate server, but the authentication session will have to be restarted from the Hiller & Zorn [Page 3]
INTERNET-DRAFT Diameter EAP Application March 2003 beginning. If a response is received with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [BASE], it is an indication that the Diameter server in the home realm does not support EAP. If possible, the access device MAY attempt to negotiate another authentication protocol, such as PAP or CHAP. An access device SHOULD be cautious when determining whether a less secure authentication protocol will be used, since this could be a result of a bidding down attack. 2.2. Alternative Uses Currently the conversation between the backend authentication server and the Diameter server is proprietary because of lack of standardization. In order to increase standardization and provide interoperability between Diameter vendors and backend security vendors, it is recommended that Diameter-encapsulated EAP be used for this conversation. This has the advantage of allowing the Diameter server to support EAP without the need for authentication-specific code within the Diameter server. Authentication-specific code can then reside on a back-end authentication server instead. In the case where Diameter-encapsulated EAP is used in a conversation between a Diameter server and a backend authentication server, the latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP- Success message without inclusion of the expected authorization AVPs required in a successful response. This means that the Diameter server MUST add these attributes prior to sending an Diameter-EAP- Answer/EAP-Payload/EAP-Success message to the access device. 3. Command-Codes This section defines new Command-Code [BASE] values that MUST be supported by all Diameter implementations conforming to this specification. The following Command Codes are defined in this section: Command-Name Abbrev. Code Reference -------------------------------------------------------- Diameter-EAP-Request DER 268 3.1 Diameter-EAP-Answer DEA 268 3.2 Hiller & Zorn [Page 4]
INTERNET-DRAFT Diameter EAP Application March 2003 3.1. Diameter-EAP-Request (DER) Command The Diameter-EAP-Request (DER) command, indicated by the Command-Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server and conveys an EAP- Response [RFC2284] from the EAP client. The Diameter-EAP-Request MUST contain one EAP-Payload AVP, which contains the actual EAP payload. An EAP-Payload AVP with no data MAY be sent to the Diameter server to initiate an EAP authentication session. The DER message MAY be the result of a multi-round authentication exchange, which occurs when the DEA is received with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH [BASE]. A subsequent DER message MUST include any State AVPs [NASREQ] that were present in the DEA. For re-authentication, it is recommended that the Identity request be skipped in order to reduce the number of authentication round trips. This is only possible when the user's identity is already known by the home Diameter server. 3.1.1. Message Format <Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } { EAP-Payload } [ NAS-Port ] [ NAS-Port-Id ] [ Destination-Host ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] [ Auth-Session-State ] [ Session-Timeout ] [ User-Name ] [ Service-Type ] [ Idle-Timeout ] [ NAS-IP-Address ] [ NAS-IPv6-Address ] [ NAS-Identifier ] [ NAS-Port-Type ] [ Port-Limit ] [ State ] [ Origin-State-Id ] [ NAS-Key-Binding ] Hiller & Zorn [Page 5]
INTERNET-DRAFT Diameter EAP Application March 2003 [ Callback-Number ] [ Called-Station-Id ] [ Calling-Station-Id ] [ Connect-Info ] * [ Framed-Compression ] [ Framed-Interface-Id ] * [ Framed-IPv6-Prefix ] [ Framed-IP-Address ] [ Framed-IP-Netmask ] [ Framed-MTU ] [ Framed-Protocol ] * [ Tunneling ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] 3.2. Diameter-EAP-Answer (DEA) Command The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code field set to 268 and the 'R' bit cleared in the Command Flags field, is sent by the Diameter server to the client for one of the following reasons: 1) The message is part of a multi-round authentication exchange, and the server is expecting a subsequent Diameter-EAP-Request. This is indicated by setting the Result-Code to DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State AVPs. 2) the EAP client has been successfully authenticated and authorized, in which case the message MUST include the Result-Code AVP indicating success, and SHOULD include an EAP-Payload of type EAP- Success. This event MUST cause the access device to provide service to the EAP client. 3) The EAP client has not been successfully authenticated and/or authorized, and the Result-Code AVP is set to indicate failure. This message SHOULD include an EAP-Payload, but this AVP is not used to determine whether service is to be provided. If the message from the Diameter client included a request for authorization, a successful response MUST include the authorization AVPs that are relevant to the service being provided. Hiller & Zorn [Page 6]
INTERNET-DRAFT Diameter EAP Application March 2003 3.2.1. Message Format <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Result-Code } { Origin-Host } { Origin-Realm } { Auth-Request-Type } [ Error-Reporting-Host ] [ EAP-Payload ] [ User-Name ] [ Service-Type ] * [ Configuration-Token ] [ Acct-Interim-Interval ] [ Idle-Timeout ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] [ Auth-Session-State ] [ Re-Auth-Request-Type ] [ Session-Timeout ] [ Termination-Action ] [ State ] [ Origin-State-Id ] * [ Filter-ID ] * [ NAS-Session-Key ] [ Callback-Id ] [ Callback-Number ] [ Framed-Appletalk-Link ] * [ Framed-Appletalk-Network ] [ Framed-Appletalk-Zone ] * [ Framed-Compression ] [ Framed-Interface-Id ] * [ Framed-IPv6-Prefix ] [ Framed-IPv6-Pool ] * [ Framed-IPv6-Route ] [ Framed-IP-Address ] [ Framed-IP-Netmask ] * [ Framed-Route ] [ Framed-Pool ] [ Framed-IPX-Network ] [ Framed-MTU ] [ Framed-Protocol ] [ Framed-Routing ] * [ NAS-Filter-Rule ] * [ Tunneling ] * [ Redirect-Host ] [ Redirect-Host-Usage ] Hiller & Zorn [Page 7]
INTERNET-DRAFT Diameter EAP Application March 2003 [ Redirect-Max-Cache-Time ] [ Port-Limit ] * [ Proxy-Info ] * [ AVP ] 4. Attribute-Value Pairs This section both defines new AVPs, unique to the EAP Diameter application and describes the usage of AVPs defined elsewhere if that usage in the EAP application is noteworthy. 4.1. New AVPs 4.1.1. EAP-Payload AVP The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used to encapsulate the actual EAP packet [RFC2284] that is being exchanged between the EAP client and the home Diameter server. 4.1.2. Accounting-EAP-Auth-Method AVP The Accounting-EAP-Auth-Method AVP (AVP Code 401) is of type Enumerated and uses the EAP Type name space defined in [EAPTYP]. 4.2. AVPs Defined in Other Documents 4.2.1. State AVP The State AVP MAY be sent by a Diameter Server to a NAS in a Diameter-EAP-Response command that also includes a Termination-Action AVP with the value of AA-REQUEST. If the NAS performs the Termination-Action by sending a new Diameter-EAP-Request command upon termination of the current service, it MUST return the State AVP unmodified in the new Diameter-EAP-Request command. The NAS MUST NOT interpret the State AVP locally. Usage of the State AVP is implementation dependent. 4.2.2. Configuration-Token AVP The Configuration-Token AVP [NASREQ] MAY be sent by a Diameter Server to a Diameter Proxy Agent or Translation Agent in an Diameter-EAP- Answer command to indicate a type of user profile to be used. It should not be sent to a Diameter client. Hiller & Zorn [Page 8]
INTERNET-DRAFT Diameter EAP Application March 2003 4.2.3. NAS-Port AVP The NAS-Port AVP [NASREQ] MAY be included in the Diameter-EAP-Request command. Either the NAS-Port AVP or the NAS-Port-Id AVP [NASREQ] SHOULD be present in the Diameter-EAP-Request command if the NAS differentiates among its ports. 4.2.4. NAS-Port-Id AVP The NAS-Port-Id AVP [NASREQ] MAY be included in the Diameter-EAP- Request command. Either the NAS-Port-Id AVP or the NAS-Port AVP [NASREQ] SHOULD be present in the Diameter-EAP-Request command if the NAS differentiates among its ports. 4.2.5. Termination-Action AVP The Termination-Action AVP [NASREQ] indicates what action the NAS should take when the specified service is completed. This AVP SHOULD only be present in authorization responses. The following values are supported as listed in [RADTYP]: DEFAULT 0 AA-REQUEST 1 If the value of the Termaination-Action AVP is equal to DEFAULT (0) then upon termination of the authorized service the NAS MUST terminate the current session. If the value of the Termaination-Action AVP is equal to AA-REQUEST (1) then upon termination of the authorized service the NAS MAY send a new Diameter-EAP-Request (DER) command. When the authorized service terminates, the NAS SHOULD NOT terminate the session or generate a Session-Termination-Request (STR) command. Instead, it SHOULD generate a new command which contains the same value of the Session-Id AVP it sent in the previous AAR or DER command. It SHOULD also include the State AVP from the previous Diameter-EAP-Answer (DEA) command if it contained one. An exception to this rule applies, however, if the authorized service terminates due to the expiry of the Session-Timeout AVP. In this case, the NAS MUST terminate the expired session and MAY generate a new DER command with a new Session-Id. Hiller & Zorn [Page 9]
INTERNET-DRAFT Diameter EAP Application March 2003 Note: The Termination-Action AVP is typically used for the login service (Service-Type = 1 or "Login") or by 802.1x access devices (e.g., NAS-Port-Type = 19 or "Wireless - IEEE 802.11"). When used for the login service, the service typically terminates when the login host clears the connection. The NAS may prompt the user for a new connection and issue a new DER. When used by 802.1x access devices, the service typically terminates due to the expiry of the Session-Timeout AVP. The access device may then reauthenticate the user with a new DER. The RECOMMENDED way to do this in Diameter is to use the Authorization-Lifetime AVP rather than the Termination-Action AVP. However, the Termination-Action AVP MAY be used when copied from a RADIUS Access-Accept packet to a Diameter-EAP-Answer command by a Translation Agent. 5. AVP Occurrence Tables The following tables use these symbols: 0 The AVP MUST NOT be present in the message 0+ Zero or more instances of the AVP MAY be present in the message 0-1 Zero or one instance of the AVP MAY be present in the message 1 One instance of the AVP MUST be present in the message Note that AVPs that can only be present within a Grouped AVP are not represented in these tables. Hiller & Zorn [Page 10]
INTERNET-DRAFT Diameter EAP Application March 2003 5.1. EAP Command AVP Table The following table lists the AVPs that may be present in the DER and DEA Commands, defined in this document; however, the AVPs listed are defined both here and in [NASREQ]. +---------------+ | Command-Code | |-------+-------+ Attribute Name | DER | DEA | ------------------------------------|-------+-------| Acct-Interim-Interval [BASE] | 0 | 0-1 | Auth-Application-Id [BASE] | 1 | 1 | Auth-Grace-Period [BASE] | 0-1 | 0-1 | Auth-Request-Type [BASE] | 1 | 1 | Auth-Session-State [BASE] | 0-1 | 0-1 | Authorization-Lifetime [BASE] | 0-1 | 0-1 | Callback-Id [NASREQ] | 0 | 0-1 | Callback-Number [NASREQ] | 0-1 | 0-1 | Called-Station-Id [NASREQ] | 0-1 | 0 | Calling-Station-Id [NASREQ | 0-1 | 0 | Connect-Info [NASREQ] | 0-1 | 0 | Configuration-Token [NASREQ] | 0 | 0+ | Destination-Host [BASE] | 0-1 | 0 | Destination-Realm [BASE] | 1 | 0 | EAP-Payload | 1 | 0-1 | Error-Message [BASE] | 0 | 0-1 | Error-Reporting-Host [BASE] | 0 | 0+ | Filter-Id [NASREQ] | 0 | 0+ | Framed-Appletalk-Link [NASREQ] | 0 | 0-1 | Framed-Appletalk-Network [NASREQ] | 0 | 0+ | Framed-Appletalk-Zone [NASREQ] | 0 | 0-1 | Framed-Compression [NASREQ] | 0+ | 0+ | Framed-Interface-Id [NASREQ] | 0-1 | 0-1 | Framed-IP-Address [NASREQ] | 0-1 | 0-1 | Framed-IP-Netmask [NASREQ] | 0-1 | 0-1 | Framed-IPv6-Prefix [NASREQ] | 0+ | 0+ | Framed-IPv6-Pool [NASREQ] | 0 | 0-1 | Framed-IPv6-Route [NASREQ] | 0 | 0+ | Framed-IPX-Network [NASREQ] | 0 | 0-1 | Framed-MTU [NASREQ] | 0-1 | 0-1 | Framed-Pool [NASREQ] | 0 | 0-1 | Framed-Protocol [NASREQ] | 0-1 | 0-1 | Framed-Route [NASREQ] | 0 | 0+ | Framed-Routing [NASREQ] | 0 | 0-1 | Idle-Timeout [NASREQ] | 0-1 | 0-1 | Hiller & Zorn [Page 11]
INTERNET-DRAFT Diameter EAP Application March 2003 +---------------+ | Command-Code | |-------+-------+ Attribute Name | DER | DEA | ------------------------------------|-------+-------| NAS-Filter-Rule [NASREQ] | 0 | 0+ | NAS-Identifier [NASREQ] | 0-1 | 0 | NAS-IP-Address [NASREQ] | 0-1 | 0 | NAS-IPv6-Address [NASREQ] | 0-1 | 0 | NAS-Key-Binding [NASREQ] | 0-1 | 0 | NAS-Port [NASREQ] | 0-1 | 0 | NAS-Port-Id [NASREQ] | 0-1 | 0 | NAS-Port-Type [NASREQ] | 0-1 | 0 | NAS-Session-Key [NASREQ] | 0 | 0+ | Origin-Host [BASE] | 1 | 1 | Origin-Realm [BASE] | 1 | 1 | Origin-State-Id [BASE] | 0-1 | 0-1 | Port-Limit [NASREQ] | 0-1 | 0-1 | Proxy-Info [BASE] | 0+ | 0+ | Redirect-Host [BASE] | 0 | 0+ | Redirect-Host-Usage [BASE] | 0 | 0-1 | Redirect-Max-Cache-Time [BASE] | 0 | 0-1 | Result-Code [BASE] | 0 | 1 | Re-Auth-Request-Type [BASE] | 0 | 0-1 | Route-Record [BASE] | 0+ | 0 | Service-Type [NASREQ] | 0-1 | 0-1 | Session-Id [BASE] | 1 | 1 | Session-Timeout [BASE] | 0-1 | 0-1 | State [NASREQ] | 0-1 | 0-1 | Termination-Action [NASREQ] | 0 | 0-1 | Tunneling [NASREQ] | 0+ | 0+ | User-Name [BASE] | 0-1 | 0-1 | 5.2. Accounting AVP Table The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages, defined in [BASE]. +-----------+ | Command | | Code | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Accounting-EAP-Auth-Method | 1 | 0-1 | Hiller & Zorn [Page 12]
INTERNET-DRAFT Diameter EAP Application March 2003 Normative References [RFC2284] Blunk, L., J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998 [EAPTYP] IANA Assigned Numbers Database, URL: <http://www.iana.org/assignments/ppp-numbers> [NASREQ] Calhoun, P., Bulley, W., Rubens, A., Haag, J., Zorn, G., D. Spence, "Diameter NASREQ Application", draft-ietf-aaa- nasreq-10.txt (work in progress), June 2002 [BASE] Calhoun, P., Arkko, J., Guttman, E., Zorn, G., J. Loughney, "Diameter Base Protocol", draft-ietf-aaa- diameter-11.txt (work in progress), June 2002 [RADTYP] IANA Assigned Numbers Database, URL: <http://www.iana.org/assignments/radius-types> Informative References [RFC1510] Kohl, J., C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1992 [RFC1938] Haller, N., C. Metz, "A One-Time Password System", RFC 1938, May 1996 [STD51] W. Simpson, Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994 [IEEE8021X] IEEE Standard for Local and metropolitan networks -- Port-Based Network Access Control, IEEE Std 802.1X-2001, June 2001 Security Considerations Open to offers... Acknowledgments Large portions of this document were cadged from [NASREQ]. Hiller & Zorn [Page 13]
INTERNET-DRAFT Diameter EAP Application March 2003 Authors' Addresses Tom Hiller Lucent Technologies 1960 Lucent Lane Naperville, IL 60566 USA Phone: +1 (630) 979-7673 Email: tom.hiller@lucent.com Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 USA Phone: +1 (425) 344-8113 Email: gwz@cisco.com Full Copyright Statement "Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Hiller & Zorn [Page 14]
INTERNET-DRAFT Diameter EAP Application March 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. Expiration Date This memo is filed as <draft-ietf-aaa-eap-01.txt> and expires September 2, 2003. Hiller & Zorn [Page 15]
