• Aucun résultat trouvé

The following two diagrams show the state machine for a complete authenticator. The first diagram is identical to the stand-alone state machine, shown in Figure 4, with the exception that the SELECT_ACTION state has an added transition to PASSTHROUGH. The second diagram also keeps most of the logic, except the four method states, and it shows how the state machine works once it goes to pass-through mode.

The first diagram is largely a reproduction of that found above, with the added hooks for a transition to PASSTHROUGH mode.

(see the .pdf version for missing diagram or refer to Appendix A.4 if reading the .txt version) Figure 6: EAP Full Authenticator State Machine (Part 1) The second diagram describes the functionality necessary for an authenticator operating in pass-through mode. This section of the diagram is the counterpart of the backend diagram above.

(see the .pdf version for missing diagram or refer to Appendix A.4 if reading the .txt version) Figure 7: EAP Full Authenticator State Machine (Part 2)

7.1. Interface between Full Authenticator State Machine and Lower Layers

The full authenticator is unique in that it interfaces to multiple lower layers in order to support pass-through mode. The interface to the primary EAP transport layer is the same as described in Section 5. The following describes the interface to the second lower layer, which represents an interface to AAA. Note that there is not

necessarily a direct interaction between the EAP layer and the AAA layer, as in the case of [1X-2004].

7.1.1. Variables (AAA Interface to Full Authenticator) aaaEapReq (boolean)

Set to TRUE in lower layer, FALSE in authenticator state machine.

Indicates that a new EAP request is available from the AAA server.

aaaEapNoReq (boolean)

Set to TRUE in lower layer, FALSE in authenticator state machine.

Indicates that the most recent response has been processed, but that there is no new request to send.

aaaSuccess (boolean)

Set to TRUE in lower layer. Indicates that the AAA backend authenticator has reached the SUCCESS state.

aaaFail (boolean)

Set to TRUE in lower layer. Indicates that the AAA backend authenticator has reached the FAILURE state.

aaaEapReqData (EAP packet)

Set in the lower layer when aaaEapReq, aaaSuccess, or aaaFail is set to TRUE. The actual EAP request to be sent (or success/

failure).

aaaEapKeyData (EAP key)

Set in lower layer when keying material becomes available from the AAA server. Note that this document does not define the structure of the type "EAP key". We expect that it will be defined in

[Keying].

aaaEapKeyAvailable (boolean)

Set to TRUE in the lower layer if keying material is available.

The actual key is stored in aaaEapKeyData.

aaaMethodTimeout (integer)

Method-provided hint for suitable retransmission timeout, or NONE.

(Note that this hint is for the EAP retransmissions done by the pass-through authenticator, not for retransmissions of AAA packets.)

7.1.2. Variables (full authenticator to AAA interface) aaaEapResp (boolean)

Set to TRUE in authenticator state machine, FALSE in the lower layer. Indicates that an EAP response is available for processing by the AAA server.

aaaEapRespData (EAP packet)

Set in authenticator state machine when eapResp is set to TRUE.

The EAP packet to be processed.

aaaIdentity (EAP packet)

Set in authenticator state machine when an IDENTITY response is received. Makes that identity available to AAA lower layer.

aaaTimeout (boolean)

Set in AAA_IDLE if, after a configurable amount of time, there is no response from the AAA layer. The AAA layer in the NAS is itself alive and OK, but for some reason it has not received a valid Access-Accept/Reject indication from the backend.

7.1.3. Constants Same as Section 5.

7.2. Interface between Full Authenticator State Machine and Methods Same as stand-alone authenticator (Section 5.2).

7.3. Full Authenticator State Machine Local Variables

Many of the variables of the full authenticator have already been defined in Section 5. This section contains definitions for those not existent in the stand-alone version, as well as those that are defined differently.

7.3.1. Short-Term (Not Maintained between Packets) decision (enumeration)

Set in SELECT_ACTION state. Temporarily stores the policy decision to succeed, fail, continue with a local method, or continue in pass-through mode.

7.4. EAP Full Authenticator Procedures

All the procedures defined in Section 5 exist in the full version.

In addition, the following procedures are defined.

getId()

Determines the identifier value chosen by the AAA server for the current EAP request. The return value is an integer.

7.5. EAP Full Authenticator States

All the states defined in Section 5 exist in the full version. In addition, the following states are defined.

INITIALIZE_PASSTHROUGH

Initializes variables when the pass-through portion of the state machine is activated.

IDLE2

The state machine waits for a response from the primary lower layer, which transports EAP traffic from the peer.

IDLE

The state machine spends most of its time here, waiting for something to happen.

RECEIVED2

This state is entered when an EAP packet is received and the

authenticator is in PASSTHROUGH mode. The packet header is parsed here.

AAA_REQUEST

The incoming EAP packet is parsed for sending to the AAA server.

AAA_IDLE

Idle state that tells the AAA layer that it has a response and then waits for a new request, a no-request signal, or

success/failure.

AAA_RESPONSE

State in which the request from the AAA interface is processed into an EAP request.

SEND_REQUEST2

This state signals the lower layer that a request packet is ready to be sent.

DISCARD2

This state signals the lower layer that the response was

discarded, and that no new request packet will be sent at this time.

RETRANSMIT2

Retransmits the previous request packet.

SUCCESS2

A final state indicating success.

FAILURE2

A final state indicating failure.

TIMEOUT_FAILURE2

A final state indicating failure because no response has been received. Because no response was received, no new message

(including failure) should be sent to the peer. Note that this is different from the FAILURE2 state, in which a message indicating failure is sent to the peer.

8. Implementation Considerations

Documents relatifs