eap Mailing List: Re: [Issue 247] Comments on EAP state machine v4

[Florent Bersani (florent.bersani]

A few ad-hoc thoughts in-line ;-)

Nick Petroni wrote:

> hope that others chime in with their opinions as
> well.
So do I ;-)

> I would caution that AAA != RADIUS. There are other possibilities.
>  
I agree

> I agree the AP must
> parse some amount of the response, possibly even all of it since it did
> send  the initial request. However, If you look at the AAA-EAP draft
> http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt
> you will see on pages 4 and 5 some discussion of this topic. My guess is
> it is *this* text that was the motivation for the passing of the entire
> packet.
>
> A quick highlight of the text:
>
>   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 (see the
>   diagram below).  This alternative reduces the number of Diameter
>   message round trips.  When the EAP-Request/Identity message is issued
>   by the access device, it SHOULD interpret the EAP-Response/Identity
>   packet returned by the authenticating peer, and copy its value to a
>   User-Name AVP in Diameter-EAP-Request.  This is useful in roaming
>   environments, since the Destination-Realm is needed 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).
>
>   User                             NAS                           Server
>    |                                |                                |
>    |        (initiate EAP)          |                                |
>    |<------------------------------>|                                |
>    |                                |                                |
>    |          EAP Request(Identity) |                                |
>    |<-------------------------------|                                |
>    |                                |                                |
>    | EAP Response(Identity)         |                                |
>    |------------------------------->|                                |
>    |                                | Diameter-EAP-Request           |
>    |                                | EAP-Payload(EAP Response)      |
>    |                                |------------------------------->|
>    :                                :                                :
>    :                        ...continues...                          :
>
>  
I believe that your text backs my point: since the authenticator already 
sends the whole EAP packet to the AS in aaaEapRespData, I do not yet see 
the point in passing the whole EAP packet to aaaIdentity (and not only 
the identity). The behavior I described with RADIUS is the one quoted in 
your text with DIAMETER.

However, as "the one who does more can do less", there is no critical 
technical reason to prevent aaaIdentity from being the whole packet and 
not only the identity field. This issue is *editorial* and I won't fight 
for it.

It's just that
1) to the average reader I am, when I read the actions of the 
AAA_REQUEST state in figure 7, namely aaaIdentity = eapRespData ; 
aaaEapRespData = eapRespData, I find it weird to instantiate two 
variables that take the same value
2) from an interface perspective, if you set aaaIdentity to a whole EAP 
packet, then the AAA layer has to parse the EAP packet to recover the 
identity wherehas if you set it aaaIdentity to identity, the AAA layer 
has no parsing to do, just encapsulation. I find the latter cleaner.

BTW, I haven't yet read the draft you pointed me to. So I'll read it 
this WE and come back with perhaps more educated thoughts.