Re: EAP Id management
Alan DeKok <aland <at> deployingradius.com>
2009-05-27 10:29:02 GMT
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
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
> 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.]
> 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.
> So, which one is the right way, and which one did the implementations
The implementations I'm aware of all followed the method of RFC 4137:
Discard all information about Id's on Success/Fail.
To unsubscribe or modify your subscription options, please visit: