Subject: [eap] EAP Id management

From: "Alper Yegin" <[email-masked]>
Date: Wed, 27 May 2009 10:47:39 +0300

I hope this ML is active and people can provide feedback.

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.

This statement implies that the Identifier management extends beyond
EAP-Success/Failure into subsequent EAP re-authentications. 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
follow?

I already asked few people, and need feedback from others as well.

Thanks in advance.

Alper

 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 May 2009 12:29:02 +0200

>       is not limited to only 256 roundtrips.

  I think that statement isn't overly clear.

> 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

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

  Alan DeKok.