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

[Nick Petroni (npetroni]

> [3] Support for protected result indications.  When an EAP method
> supporting mutual authentiation and protected result indication is
> in use,  the EAP peer and server will typically be aware of each other's
> access decision, as well as their own.  For example, the EAP server will
> indicate to the peer whether the peer has successfully authenticated to
> it, and the peer will indicate to the EAP server whether the server has
> successfully authenticated to the peer. As a result, the EAP peer and
> server can determine whether an authentication is required in the
> opposite direction.  However, where the authenticator operates as a
> pass-through, it will not be aware whether the peer has
> accepted the access offered to it by the EAP server unless this
> information is provided to it via the AAA protocol.  As a result, two
> authentications, one in each direction, may still need to occur."

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?