Subject: [AAA-WG]: Issue 88: Proposed Text for EAP Support Issues

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 10:52:05 -0700

All,

I hadn't really noticed how bad this section needed some rev'ing up :(
I believe that I have address all of the concerns in this issue in
the following text:

4.0  Extensible Authentication Protocol Support

   The Extensible Authentication Protocol (EAP), described in [25],
   provides a standard mechanism for support of extensible
   authentication methods. Through the use of EAP, support for a number
   of authentication schemes may be added, including smart and token
   cards, Kerberos, Public Key, One Time Passwords, and others.

   This section describes the Command-Codes values and AVPs that are
   required for an EAP payload 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.

   The EAP conversation between the authenticating peer and the access
   device begins with the negotiation of EAP within a link layer, such
   as PPP or 802.1x. Once EAP has been negotiated, 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 payload [25], 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
   identify itself. Upon receipt of the EAP client's EAP-Response [25],
   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 successful Diameter-EAP-Answer MUST
   also include the appropriate authorization AVPs required for the
   service requested (see sections 2.0, 6.0 and 7.0).

   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 [2] 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
   beginning.

   If a response is received with the Result-Code set to
   DIAMETER_COMMAND_UNSUPPORTED [2], it is an indication that the
   Diameter server in the home domain 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.

[...]

4.2.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 [25] 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. A subsequent DER message MUST
   include any State AVPs 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.

   Message Format

      <Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
                                 < Session-Id >
                                 { Auth-Application-Id }
                                 { Origin-Host }
                                 { Origin-Realm }
                                 { Destination-Realm }
                                 { Service-Type }
                                 { EAP-Payload }
                                 [ Destination-Host ]
                                 [ Authorization-Lifetime ]
                                 [ Session-Timeout ]
                                 [ User-Name ]
                                 [ Idle-Timeout ]
                                 [ NAS-IP-Address ]
                                 [ NAS-Identifier ]
                                 [ State ]
                                 [ Origin-State-Id ]
                                 [ NAS-Key-Binding ]
                               * [ AVP ]
                               * [ Proxy-Info ]
                               * [ Route-Record ]

4.2.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 MAY 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.

   Message Format

      <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
                                < Session-Id >
                                { Auth-Application-Id }
                                { Result-Code }
                                { Origin-Host }
                                { Origin-Realm }
                                { Destination-Host }
                                { Service-Type }
                                [ Error-Reporting-Host ]
                                [ EAP-Payload ]
                                [ User-Name ]
                                [ Idle-Timeout ]
                                [ Authorization-Lifetime ]
                                [ Session-Timeout ]
                                [ Origin-State-Id ]
                              * [ NAS-Session-Key ]
                              * [ AVP ]
                              * [ Proxy-Info ]
                              * [ Route-Record ]

4.3  EAP-Payload AVP

   The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used
   to encapsulate the actual EAP payload [25] that is being exchanged
   between the EAP client and the home Diameter server.

---

From: Jacques Caron <[email-masked]>
Date: Fri, 22 Jun 2001 11:23:56 +0200

Hi,

Just two stupid questions...

I hadn't noticed that EAP actually used different command-codes from 
regular AAA/AAR. In that case, maybe it should be an altogether different 
application?

Another thing that came to mind while I was reading the Diameter Mobile IP 
draft this week-end, is there any (existent/planned) interaction between 
Mobile IP and EAP?

Jacques.

>    between the EAP client and the home Diameter server.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 22 Jun 2001 11:49:27 -0700

> regular AAA/AAR. In that case, maybe it should be an altogether different 

Although I do agree, the only issue I have is that both auth schemes end up
using the same authorization avps, so there'd be a whole lot of duplication :(

> draft this week-end, is there any (existent/planned) interaction between 

no.

PatC

---

From: Jacques Caron <[email-masked]>
Date: Sat, 23 Jun 2001 12:03:37 +0200

>using the same authorization avps, so there'd be a whole lot of duplication :(

Nothing prevents two applications from sharing the same AVPs (quite the 
contrary actually). Note that I didn't say two drafts, just two 
applications (for capabilities advertisement purposes).

> > draft this week-end, is there any (existent/planned) interaction between

Interesting...

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 25 Jun 2001 05:43:05 -0700

> >using the same authorization avps, so there'd be a whole lot of duplication :(

ah, I see. So 802.1x wouldn't have to support PAP/CHAP, and still conform to
*part of* the spec.

> > > draft this week-end, is there any (existent/planned) interaction between

mip has it's own auth scheme, and it doesn't fit the EAP model at all.

PatC

---

From: Jacques Caron <[email-masked]>
Date: Mon, 25 Jun 2001 15:12:23 +0200

>ah, I see. So 802.1x wouldn't have to support PAP/CHAP, and still conform to

Or, alternatively, a Radius-to-Diameter gateway serving Radius NASes that 
do not support EAP... Or a Diameter-to-Radius gateway in front of a Radius 
server that doesn't support EAP either.

BTW, wouldn't it be possible to only have EAP in Diameter, and require 
clients to do EAP/PAP or EAP/CHAP conversion (the former being a problem 
since there is no clear-text auth in EAP, of course)? Not sure it would 
bring anything, just a bit of simplification for pure Diameter 
implementations maybe, PAP/CHAP being then considered just EAP methods like 
any others...

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 25 Jun 2001 06:35:45 -0700

> implementations maybe, PAP/CHAP being then considered just EAP methods like 

as you state, there is no PAP subtype for EAP. However, having the NAS
initiate EAP, and simply carry CHAP within it does have the advantage of
allowing the home server to authenticate the user, without the replay
problems found in today's non-EAP networks. However, this breaks with
traditional RADIUS servers, most of which don't support EAP :(

so interoperability becomes an issue.

PatC