Subject: [eap] EAP changes possibilities

From: [email-masked] (John Vollbrecht)
Date: Mon, 04 Mar 2002 18:28:22 -0500

EAP – Issues and Suggestions for EAPng

The following is for discussion as part of the EAP BOF.  I have included

suggestions for change to EAP and to best practices for Network Access
Devices that translate EAP messages from one carrier protocol to
another.

-----

EAP common use is in situations where a Client attaches to a Network
Access Device (NAD – also known as NAS, AP, Edge device, --) and
authenticates to an Authoriziation server (AS – e.g. RADIUS server,
Diameter Server, COPS PDP, ---).

Use in dial access with PPP and in wireless LANS with 802.1x is common,
and proposals for use with SIP, MobileIP, and even EAP over UDP are
proposed.  Transport of EAP over RADIUS, Diameter, COPS, SIP, UDP is in
production or proposed.

The standard picture is something like the following, with different
names for different players depending on the application.

  Client ----------------  NAD ------------------AS

1. Who’s talking to who

EAP is designed to be a Point to Point protocol.  By this I mean that it

has no addressing capability, and an EAP packet sent from Client to NAD
(e.g. over PPP) is forwarded to an AS (e.g. in a RADIUS packet).  The
NAD knows somehow which AS to forward the EAP message to, normally the
same place the access request is sent.

In practice, the NAD will initiate and send an EAP message to the Client

to get its identity.  This is needed in order to determine where an
access request should be sent.
This could be considered a separate EAP exchange from the later exchange

between the Client and AS.

The sequence of exchanges is as follows.

  Client ----------------  NAD ------------------ AS

           <- [identity]->

         <---------[authentication] ------------>

1.1 Suggestion for change in EAPng:

I would like to see EAPng have a way to indicate that an exchange is
local (between NAD and Client) or standard (between AS and Client).  One

possibility would be to define an additional set of EAP Codes for
local.   For example:

0 Request
1 Response
2 Success
3 Failure
101 Local Request
102 Local Response
103 Local Success
104 Local Failure

-----------------------------------------------------
2.   What exchanges happen in an Access Control Dialog

a) Client /NAD
              Initial Identity exchange
              Final Success/Failure of method

b) Client /AS
             EAP methods (may include key generation)

c) NAD /AS (not EAP)
             Initial Authorization Request
             Authorization result (may include Key transport from AS to
NAD)

2.1 Suggestions for change in  RFC 2869 (and for inclusion in other best
practices for handling AP in NADs.)

a) Do not include EAP Identity response in initial Authorization request
from NAD to AS
b) Do not send success or failure from AS.  Send Accept or Reject RADIUS
message (or equivalent). This message will also carry Key from AS to NAD
if necessary
c) NAD always creates Success or Failure EAP message locally, and sends
to Client..

---------------------------------------------------------
3. Mutual Authorization

A Client should be able to initiate an EAP exchange to the AS.  With PPP

it is possible for either the client or the server or both to require
the other to authenticate itself.  In 802.1x it is not clear (to me at
least) how the client can require the server to authenticate.  A number
of mutual authentication methods have been published which make this
less of a problem.  Still it seems reasonable to allow the client to
initiate an EAP method (in the simple case, just an Identity request for

example).

3.1 Suggestion

Allow the client to send an EAP request after receiving a “normal”
request from the AS.  The reason for waiting till it receives a request
is to be sure that there is a path to the AS for it to use.  The Request

from the Client to the AS MAY allow the Reply to be piggybacked with it
in the carrier protocol.  This would mean that a multiple EAP messages
might be carried in a RADIUS packet.  I am guessing the piggybacking
idea will be controversial, but I would like to consider it.

---------------------------------------------------------------
4. Sequential EAP methods

EAP provides a way for the AS and Client to authenticate each other and
possibly to do other authorization checks.  It is possible for the
server to do a sequence of methods (e.g. Identity followed by MD5).
What is difficult is for the AS that it is ok if the Client is ok.  This

is especially important if the Client is doing a parallel and
independent set of checking methods.

4.1 Ok with me if  its ok with you method

To deal with this  I suggest that a new method be developed in which the

response is an ACK or NAK, but which might be delayed while the other
end continues with additional methods.

-----------------------------------------------
I would lappreciate comments on these suggestions.  The actual changes
to the protocol would be small, but I think they would both clarify
useage and create the possibility of using EAP at access time for doing
things like negotiating QoS requirements for the Client.

-- John