Subject: [eap] EAP Design Team -- This week's position papers

From: [email-masked] (Bernard Aboba)
Date: Wed, 25 Sep 2002 06:28:51 -0700 (PDT)

Issues on position paper b

By Yoshihiro Ohba ([email-masked])

Date: September 23, 2002

-------------------------------------------------
Issue 1: Need for detailed notational conventions
         for state diagrams.
-------------------------------------------------

I think more work on the notational conventions of the current EAP
State Machine is needed.  For example, there is an ambiguity about the
timing when the action defined in each state is executed.  There are
two possibilities:

a) The action defined in a state is executed immediately after
   the state machine enters the state.

b) The action defined in a state is executed immediately before
   the state machine leaves the state (and after testing
   branching conditions.)

It seems that the EAP state machine document assumes case a), but
it is not clear.

In addition, although a state machine has a sub-state machine, it is
not clear whether a sub-state machine's behavior depends on the
entrance point from which the sub-state machine is entered when there
are multiple entrance points.

Discussion:

Is it better to use the same conventions defined in section 8.5 "EAPOL
state machines" of IEEE 802.1X specification (EAPOL state machines
always uses case a), in which changes in boolean state variables are
used as state transition events?  Or is it better to use and improve the
current conventions?

----------------------------------
Issue 2: Optional Identity support
----------------------------------

The current EAP Authenticator State Machine is not sufficient
to support optional Identity exchange.

Suggestion:

1.  Define a variable "needID" which is initialized within initPolicy().

2.  Add a text tag "isSet(needID) to the arrow connecting
    "Unauthenticated" state and "Peer Identification" state.

3.  Add a text tag "! isSet(needID)" to the arrow connecting
    "Unauthenticated" state and "EAP Method Authenticator State Machine"
    state.

-----------------------------
Issue 3: NAK message handling
-----------------------------

In the current EAP Authenticator State Machine, a state transition
from "Unauthenticated" state to "EAP Method Authenticator State Machine"
occurs when the Authenticator receives a NAK message.

Since both NAK and Identity messages are Native EAP type, it is better
to have a distinct state for handling NAK reception events like the
one used for handling Identity message.

Suggestion:

1. Remove the transition arrow connected between "Unauthenticated"
   state and "EAP Method Authenticator State Machine".  Also remove
   the text tag "Rec(NAK)" associated with the arrow.

2. Add a new state "NakReceived" and connect it to other
   states as follows (only the related states and transitions
   are shown for simplicity):

 -------------------   Rec(NAK)         -------------------
| Unauthenticated   |----------------->|   NakReceived     |
|===================|                  |===================|
|authMethodSucc = 0 |<-----------------|  updatePolicy()   |
|authMethodFail = 0 |policySatisfied() |  idCount = 0      |
 -------------------                    -------------------
                           !policySatisfied()   |
                                                |
                                                V
                                        -------------------
                                       |      Failure      |
                                       |===================|
                                       |   Send(Failure)   |
                                        -------------------

 Figure 1.  A Part of EAP Authenticator State Machine

-----------------------------------------------------
Issue 4:  Support for multiple authentication methods
          in a single session
-----------------------------------------------------

In order to support multiple authentication methods in a single
session, it would be better to define policy parameters to support the
functionality.  Also, it would be better to define a primitive set of
policy parameters which is common to all EAP methods.  The policy
parameters handling for multiple authentication methods can be included
in the primitive policy set.  Additional policy parameters can be
defined in addition to the primitive policy set.  All policy
parameters including the primitive policy set are initialized when
initPolicy() is called and dynamically modified when updatePolicy() is
called.

Suggestion:

Define the following parameters for the primitive policy set:

EAPMultiAuthPolicy

  A list of AuthPolicyElement's, where each AuthPolicyElement
  consists of the following entries:

  - EAPMethodType

    Contains an EAP Method Type used for the current round of
    authentication.

  - SuccessPolicy

    Contains a pointer to an AuthPolicyElement to be used for the next
    round of authentication when the current authentication round
    succeeds.  If the value is null, the entire rounds of EAP
    authentication end with Success message.

  - FailurePolicy:
    Contains a pointer to an AuthPolicyElement to be used for the next
    round of authentication when the current authentication round
    fails.  If the is null, the entire rounds of EAP authentication
    end with Failure message.

CurrentAuthPolicy:

  Contains a pointer to the AuthPolicyElement used for the current
  authentication round.  The pointer is updated to the value contained
  in either SuccessPolicy or FailurePolicy of the current
  authentication round, depending on the result of the current
  authentication round.  An optimization is possible when a NAK is
  received with non-null Type-Data.  In that case, the
  CurrentAuthPolicy is updated by traversing the FailurePolicy side of
  each AuthPolicyElement until the pointer points to an
  AuthPolicyElement that has an EAPMethodType listed in the Type-Data
  of the NAK message.

Note:

  The following variables can also be included in the primitive policy
  set.

  idCountMax

    This variable is already defined in the EAP state machine document.

  needID

    A flag to indicate whether Identity exchange is needed or not (see
    Issue 1).

------------------------------------------------------
Issue 5:  Pass-Through EAP Authenticator State Machine
------------------------------------------------------

It would be useful to define a special EAP Method Authenticator State
Machine used for pass-through mode Authenticator.  By defining this,
the same state machine definition can be used for Authenticator and
authentication server, except that authentication server will not use
the "Pass-Through" Method Authenticator State Machine.

The "Pass-Through" Method Authenticator State Machine is defined as
follows:

Variables:

  initialize

    A variable that is set to TRUE when this state machine is created.

  enterMethod

    A variable that is assumed to be set to TRUE by the Authenticator
    State Machine when this state machine needs to be entered.

  rxAuthReply

    A variable that is set to TRUE when an authentication reply
    message is received from the backend authentication server.

  rxAuthAccept

    A variable that is set to TRUE when an authentication accept
    message from the backend authentication server.

  rxAuthReject

    A variable that is set to TRUE when an authentication reject
    message is received from the backend authentication server.

  rxEAPResponse

    A variable that is set to TRUE when an EAP Response message on
    this EAP method is received from the Peer.

  error

    A variable that is set to TRUE when an errornous event occurs,
    e.g., failure to send/receive message, etc.  (Timeout event is
    excluded based on the convention described in the Introduction
    section of the state machine draft.)

Procedures:

  txAuthRequest

    send an authentication request message to the backend
    authentication server.

  txEAPRequest

    send an EAP Request message on this EAP method to the Peer.

States:

  INITIALIZED

    This state is entered when this state machine is created
    or the method-specific authentication ends.

  AUTH_REQUEST_SENT

    This state is entered when the Authenticator sent an
    authentication request to the backend authentication server and
    is waiting a response from the authentication server.

  EAP_REQUEST_SENT

    This state is entered when the Authenticator sent an
    EAP Request message on this authentication method
    to the Peer and is waiting an EAP Response message
    from the authentication server.

  SUCCESS

    This state is entered when the Authenticator receives
    an authentication accept message from the backend authentication
    server.

  FAILURE

    This state is entered when the Authenticator receives
    an authentication reject message from the backend authentication
    server.

                             |
                             | initialize
                             v
                     ---------------------
    UCT             |  INITIALIZED        |   UCT
  +---------------->|=====================|<------------+
  |                 |                     |             |
  |                  ---------------------              |
  |                          |                          |
  |                          | enterMethod              |
  |                          v                          |
  |                  --------------------  rxAuthReject |
  | rxAuthAccept    | AUTH_REQUEST_SENT  | || error     |
  |      +----------|====================|-------+      |
  |      |          | txAuthRequest      |       |      |
  |      |           --------------------        |      |
  |      |                  ^ |                  |      |
  |      |                  | |rxAuthReply       |      |
  |      v                  | |                  v      |
 ----------------------     | |         ---------------------
|     SUCCESS          |    | |        |      FAILURE        |
|======================|    | |        |=====================|
| authMethodSucc = 1   |    | |        | authMethodFail = 1  |
 ----------------------     | |         ---------------------
                            | |                  ^
              rxEAPResponse | v                  |
                -------------------------        |
               |  EAP_REQUEST_SENT       |       |
               |=========================|-------+
               |     txEAPRequest        | error
                -------------------------

   Figure 2.  Pass-Through Method Authenticator State Machine

Note:

  This diagram uses the notation conventions follows the ones used for
  the EAPOL state machines.

       A comparison of the proposed EAP state machines with RFC 2284bis
                  -- An EAP Design Group Position Paper --

Authors:
  Bryan D. Payne ([email-masked])
  Nick L. Petroni, Jr. ([email-masked])

Date:
  22 September 2002

References:
  EAP State Machine Draft
  http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt

  RFC 2284bis
  http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-06.txt

                  ----------------------------------------

INTRODUCTION

This paper outlines inconsistencies between the EAP state machine draft and
the most recent revision of the EAP RFC.  Suggestions are made for
correcting any issues that are presented.  In addition to inconsistencies,
some typographic corrections and clarifications for the state machine draft
are presented at the end of this paper.

INCONSISTENCIES

Below is a listing of the current known inconsistencies between the state
machine draft and the EAP RFC:

Issue #1:  The authenticator state machine is too restrictive in how an ID
  request may be used.  Specifically, the state machines require each ID
  request to be followed by an Auth request, while the EAP RFC does not
  make this restriction.

Resolution #1:  The authenticator state machine should be updated to
  transition from the Peer Identification state to the Unauthenticated
  state, instead of directly sending an Auth request.

Issue #2:  The authenticator state machine does not provide any
  compatibility with RFC 2869bis.  Specifically, there is no transition
  from the authenticator's unauthenticated state directly to the success
  and failure states due to receipt of a message from the back-end server.

Resolution #2:  We do not propose a resolution for this issue at this time
  due to the complexity of the issues invovled.  However, we would like to
  leave this idea open to discussion.

Issue #3:  The peer and authenticator state machines do not depict the
  re-authentication scenario.  Instead, the state machines have a "dead
  end" at the authenticated states.

Resolution #3:  Create a state transition from authenticated to
  initialization in both the peer and authenticator state machines.
  Indicate that this transition is to be used for re-authentication.

Issue #4:  The state machine draft provides incorrect information
  regarding retransmission of messages (see Introduction, paragraph 4)

Resolution #4:  Reword the discussion of retransmissions to indicate that
  the peer will never retransmit messages.  In addition, note that the
  authenticator is allowed to retransmit up to a pre-specified number of
  times.  Finally, note that both the peer and authenticator must return
  to the initialization state after "timing out" in any other state.  Note
  that the definition of a time out is not provided in the EAP RFC.
  Therefore, this is implementation dependent, but should be a predefined
  amount of time with no activity.

  Note that this is independent of the situation where the authenticator
  is permitted to retransmit messages after receiving invalid ID replies.
  Also, note that the authenticator must never retransmit a success or
  failure message, per the RFC.

CLARIFICATIONS & TYPOGRAPHICAL CORRECTIONS

Below is a listing of topics that are viewed as correct in the current
state machine draft, but that require additional clarification in the
text of the draft to alleviate confusion or require a simple typographical
correction.

Clarification #1:  The state machines implicitly support the concept of a
  silent discard of the SUCCESS message.  This is because the peer will not
  transition into an authenticated state unless its policy is satisfied and
  because messages that arrive at the peer, but are not handled by the
  current state must be dropped (see Introduction, paragraph 2).

  While this support is present, it should be made more explicit due to the
  importance of the concept.

Clarification #2:  In the peer state machine diagram, the lower arrow
  between the Peer Identification and the Unauthenticated states is
  pointing in the wrong direction.

Clarification #3:  The definition of the authMethodSuccess variable in
  the peer state machine should be made more clear.

PROTOCOL LIMITATIONS

In the course of reviewing the state machine work, we were reminded of a
protocol issue with EAP that should be understood by all.  Unfortunately,
this is not something that can be resolved by the state machine, so we only
present it here for completeness.

The idea of doing a silent discard of success messages on the peer results
in a bit of a problem.  For example, let's say that the authenticator sends
a success message, but the peer isn't ready to declare success.  The
authenticator will consider itself to be done, while the peer will have
discarded the success message.  Now what happens?  The peer has no power
(per the protocol) to send a request message...it must instead just wait
for the authenticator to send one.  So the peer has no way of indicating
that it is unhappy with the situation.

There is a variable (authMethodSuccess) in the peer state machine to
address this, but it is not an actual solution.  It simply allows the peer to
re-init if it isn't happy with the result of the auth method.  However,
since there is no way for the peer to tell the authenticator that it is
unhappy, this could still leave the authenticator and the peer believing
that the protocol has had different outcomes. This problem is touched on in
EAP issue 10 ([1]).

Currently, we do not see any resolution to this problem.  However, people
should be aware that it exists.

SUMMARY

We have made several recommendations for corrections and clarifications
to the state machine draft.  We now encourage peer review of this work
and are open to comments.

REFERENCES
  [1]   http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2010