Subject: [eap] open issues list in the sm-02 document

From: [email-masked] (Jari Arkko)
Date: Wed, 14 May 2003 15:50:21 +0300

>    o  2284bis: "If a peer receives a duplicate Request before it has
>       sent a Response, but after it has determined the initial Request
>       to be valid (i.e. it is waiting for user input), it MUST silently
>       discard the duplicate Request. " Issue: Seems like the peer should
>       be able to send as many responses as it gets requests for the same
>       id.  It may not send a response for prior id after it has sent a
>       response to current id.  This is how the state machine works, and
>       hopefully the wording in 2284bis will be modified to match.

I agree.

>    o  What to do if we get a timeout, Policy.isSatisfied() is TRUE, but
>       methodState is not CON_ACC? Issue:  can peer go into authenticated
>       state without getting a Success -either internal to the method
>       (Con_ACC) or and EAP Success?

IMHO, no. (But perhaps you have discussed this as a part of the Success
thread; I didn't check.)

>    o  What to do if we get an altAccept, Policy.isSatisfied() is TRUE,
>       but methodState is not CON_ACC? Issue: same as above

As above.

>    o  Do we need a new variable to signal the lower layer that keying
>       material is available (in eapKey), or is it enough that the lower
>       layer checks if eapKey!=NONE after getting eapSuccess?

I think it may be more readable to just use one variable.

--Jari