eap Mailing List: Re: Proposed resolution of Issue 204 (for RFC 2284bis)

[Bernard Aboba (aboba]

> based on this text, a proposed change to the state machine doc would
> (roughly) look something like this:
>
> In Figure 5 "EAP Backend Authenticator State Machine", change the
> METHOD_RESPONSE state to read
>
>   m.process(aaaEapRespData)
>   if (m.isDone()) {
>      Policy.update(<...>)
>      aaaEapKeyData = m.getKey()
>      aaaEapPeerDecision = m.getPeerDecision()
>      methodState = END
>   } else
>     methodState = CONTINUE
>
> aaaEapPeerDecision would take values UNKNOWN, KNOWN_ACCEPT and
> KNOWN_REJECT and be exported to the lower layer.
>
> thoughts? any other required changes?

I think this is correct.  The lower layer can then use this variable to
decide whether to initiate EAP authentication in the other direction.

On the peer side, there is also a need to make a decision (as Joe noted).
However there I think that existing interfaces may be adequate because the
peer knows whether it has been granted access and is willing to accept it;
the only question is whether its policy requires an authentication in the
other direction too.  That doesn't seem like a decision that requires
additional interfaces to the lower layer.