Subject: [eap] Minutes of eap design team meeting, october 9th, 2002 (fwd)

From: [email-masked] (Bernard Aboba)
Date: Fri, 11 Oct 2002 13:34:21 -0700 (PDT)

Minutes of the EAP state machine Design Team conference call
Jari Arkko, Scribe

Date: October 9th, 2002, 18:00-19:00 EET

1. Agenda

    - Report on 802.1aa (Bob Moskowitz)
    - University of Maryland position paper
    - Bernard's position paper
    - Jari's position paper

2. Report on 802.1aa

    Bob was the only one present in the 802.1aa meeting, but
    he wasn't present in the conference call.

3. Jari's position paper

    This position paper studied whether the proposed EAP state
    machine has (message, state) pairs for which no actions have
    been defined. Several such pairs were found. Some of these
    pair are missing on purpose, while others are either mistakes
    or underspecification. The paper classified the issues around
    the following main problems:

    - When can Failure come?
    - When can NAK come?
    - When can Identity Reques come?
    - When can Notification come?
    - Should 2nd, 3rd, ... internal method requests be modelled in the
      main state machine?
    - Should we treat protocol errors in the
      state machine or not?

  o Failure:
    - The issue is whether peer should accept Failure only after
      a method execution, or also in the unauthenticated state
      before any methods.
    - DECISION: Peer should accept Failure in unauthenticated state.
    - There was a discussion of whether such failures can be based
      on the NAI given in an Identity Response. There are security
      issues around exposing valid / invalid user names. It was
      unclear whether ther are similar issues in exposing domains
      for which the authenticator is unable to perform authentication.
    - DECISION: We should document the security considerations
      about this, but not prevent / mandate any specific behaviour.
    - Bernard: Filters may prevent failure messages if the method
      is protected and wants a protected failure report. Methods
      may install such filters.

  o NAK:
    - We decided to talk about this in more general manner
      in the context of protocol errors.

  o Identity request:
    - The issue is whether Identity Request can be nakked,
      whether Identity Request can be repeated, whether it
      can come during the execution of a method or only in between.
    - Also, can a method ask for an identity request to be sent?
    - Can a method get the information from an identity response?
    - John asked whether the state machine goes through the unauthenticated
      state as it moves from one method to another. The answer is yes.
    - Bernard said that we should avoid having to give policy for
      EAP nodes; this is usually a sign of a lack of specification.
      Sequences of methods, different combinations can create problems
      and lots of Nakking if policies dictate too much.
    - Is identity a method? Can you nak identity? RFC says no, and some
      implementations are known to not be able to process such Naks.
    - Bernard: RFC set Identity Requests to be optional, but 802.1x made
      it mandatory. This is a conflict. What if both sides don't want it?
    - Bernard: Perhaps we should request 802.1x to make it optional also.
      This may not be easily adopted by 802.1aa, however. One issue is that
      they would like to have a solution from the IETF that works without
      configuration.
    - Jari: There is a danger that if we don't allow Naks, we will soon
      develop a convention where an empty NAI implies that the identity
      does not exist or we don't want to give it.
    - DECISION: Identity request/response can only appear between methods
    - DECISION: Our preference is that identity requests be optional. (And
      we are leaning towards making Nak disallowed.)
    - DECISION: Work on the text on the list.
    - DECISION: Talk with 802.1aa about the situation.

  o Notification:
   - DECISION: Discussion elsewhere appears to lead to allowing
     Notification in all states.
   - DECISION: Can not be Nakked.

  o 2nd, 3rd messages
    - John: Multiplexor model will make this clearer
    - Can we execute methods in parallel, 1st message
      from 1st method, 1st message from 2nd method, ...
      2nd message from the 1st method, 2nd message from
      the 2nd method, ...?
    - DECISION: No. Methods must be done one at a time.
    - There must be a concept of activating and deactivating
      a method.
    - Bernard: Acceptance locks you to the method
    - Jari: Do we need to model this in state machine?
    - John: yes

  o Protocol errors:
    - The issue is whether the state machine should say
      something about what to do when invalid EAP messages
      arrive. This may be necessary for recovery etc. purposes.
    - Bernard: There's certainly errors in individual methods.
    - Not all protocol errors need the same treatment
    - Bernard: Its a reasonable question to ask what to do in a protocol
      ertor situation, if the spec says somethign is that
    - Should silent discard be used?
    - We should avoid making Denial-of-Service attacks too easy
    - John would like to have positive confirmation of a failure
      rather than stubbornly trying and timing out later
    - Servers could send a Notification
    - There is a usability tradeoff: failure report quickly vs better
      Denial-of-Service resistance
    - John: Could we send a Nak with a message?
    - Bernard: Implementation backwards compatibility prevents NAK changes
    - Is there a need for a new message?
    - Jari: We have the following options to deal with
      unexpected protocol messages:
        1) Silent discard and wait for proper message; this often
           leads to a timeout if the discarded message really was
           from the authenticator.
        2) Immediately abort everthing and exit from EAP.
           This provides a quick indiciation to the user,
           but is very fragile wrt Denial-of-Service attacks.
        3) Provide a new abort message with support for authenticating
           that the other side really sent the offending message.
           It is unclear how complicated this is.
        4) A new notification message could be design for peer=>authenticator
           direction. This would allow implementations to report problems,
           without making the protocol very vulnerable to Denial-of-Service.
    - DECISION: We need separate discussion on errors.
    - Jari: I will write something about it.

4. Concluding remarks
    - Other two position papers will be dealt with later.
    - John: We've made a lot of progress lately in the issues.
      The main remaining issues are policy issues and dealing
      with protocol errors.
    - Jari: We will continue with the conference calls, but probably
      need also to do e-mail reviews of the position papers.