[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4072

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/