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

[Nick Petroni (npetroni]

Florent,

Thanks for the quick reply. I will reply in a sort of ad-hoc fashion to
some of these issues and hope that others chime in with their opinions as
well.

Best Regards,
nick

> >I am not a AAA expert, but I think this may have something to do with
> >parsing the actual packet at the AAA server instead of at the AP. Is this
> >not correct?
> >
> Neither am I a AAA expert, but I assume this is the hook provided to
> comply to RFC 3579, section 2.1, page 7:
I would caution that AAA != RADIUS. There are other possibilities.

> I believe that your interpretation ("parsing the actual packet at the
> AAA server instead of at the AP. Is this not correct?") is therefore
> IMHO not correct (indeed, in addition to the RFC 3579 possible
> interpretation quoted above, an AP=authenticator MUST parse the EAP
> packets per RFC 3748 and the state machine document - e.g. figure 6 -
> the AP=authenticator checks for instance the identifier of the response
> it gets...). Others?
You are correct, I wrote hastily and imprecisely. 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...                          :