One document matched: draft-ietf-aaa-eap-01.txt
Differences from draft-ietf-aaa-eap-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-21 17:50:24 |