eap Mailing List: Re: EAP Id management

[Alan DeKok (aland]

Alper Yegin wrote:
> According to RFC 3748:
>
>       Since the Identifier space is unique to each session, 
>       authenticators are not restricted to only 256 simultaneous
>       authentication conversations.  Similarly, with re-authentication,
>       an EAP conversation might continue over a long period of time, and
>       is not limited to only 256 roundtrips.

  I think that statement isn't overly clear.

> This statement implies that the Identifier management extends beyond
> EAP-Success/Failure into subsequent EAP re-authentications.

  That would seem to be a valid interpretation of that sentence.
However, all AAA servers I'm aware of treat EAP sessions as finishing at
EAP-Success/Fail.

  That is, the *EAP* layer management treats re-authentication the same
as authentication.  The EAP Id's are tracked, but once an
EAP-Success/Fail is sent back, all information about "current" Id's is
discarded.

> If that’s
> true, Id of the first EAP packet after an EAP-Success (e.g., initiation
> of EAP re-auth) has to be different than the Id used with the
> EAP-Success. [Problem: EAP re-auth may take place with another
> authenticator in the case of mobility, and that authenticator would not
> know the last Id used with the previous authenticator.]

  Yes.

> But on the other hand, this text is not normative, and EAP State Machine
> RFC 4137 already ignores that by resetting currentId to "NONE" at the
> beginning of EAP authentication.

  Yes.

> So, which one is the right way, and which one did the implementations
> follow?

  The implementations I'm aware of all followed the method of RFC 4137:
Discard all information about Id's on Success/Fail.

  Alan DeKok.