Subject: [eap] state machine design team minutes, march 26th

From: [email-masked] (Jari Arkko)
Date: Thu, 03 Apr 2003 17:46:14 +0300

Minutes of the EAP State Machine Design Team
Date: Wednesday, March 26, 2003
Time: 8 AM PST

Present: Nick Petroni, Paul Congdon, Henrik Levkowetz, Jari Arkko, Bob
Moskowitz, John Vollbrecht, Bernard Aboba, Joe Salowey, Yoshihiro
Ohba.

1. Summary of Agreements

    (a) There are two levels of "strictness". One level is where the
        method disallows everything else except notifications while its
        still running. This level is called "strict". The other level
        is where the method disallows everything else, including
        notifications. This level is called "stricter".

    (b) All methods MUST be "strict" in RFC 2284bis.

    (c) Methods MAY be "stricter". This should be defined in
        the method specification.

    (d) Peers MUST NOT allow authenticators to switch to a new method
        in the middle. Need to ask the mailing list whether this rule
        creates any interoperability problems.

    (e) Methods MAY silently discard messages.

    (f) AAA server authenticators MUST check for Type field, and
        silently discard messages with the incorrect value in it.

    (g) Passthrough authenticators MUST check for Code, Identifier, and
        Length fields, and silently discard messages with the incorrect
        value in them.

    (h) Possible Type field check in passthrough authenticators is TBD,
        but one proposal is to say that they shall not look at this
        field.

2. Detailed Discussion

    o Strict mode

      The possible actions related to the use of the strict mode are
      silently discarding messages or nakking them. John Vollbrecht
      recommends that we do a silent discard.

      Joe Salowey wants that if we know thart a certain existing
      methods behaves in a specific way in this regard, we should
      document it. Bernard Aboba responds thatr we should distinguish
      what people are doing now (what the draft documents) and what
      people might do in the future.

      Bernard Aboba also notes that the strict interpretation was the
      consensus in the WG meeting in San Francisco. the question is
      whether it is the state machine or the method.

      John Vollbrecht: some of it could be done by method, some by mux.
      Jari Arkko: It is not a question of who does it. It is a question
      of whether to do it always or just sometimes.  Joe Salowey:
      That's right.

      Bernard Aboba: PEAP has a very strict mode, does not even accept
      notifications.  John Vollbrecht: But are notifications delivered
      to methods?  Bernard: No, the method just asks the mux to install
      a filter that prevents notifications from being processed.

      John: It could also ask to allow everything, just this method, or
      not even notifs. Bernard Aboba: Another way to would be to say:
      SHOULD be strict except for Notificationss. Methods could be even
      stricter and not allow notifications at all, or possibly not
      allow identity requery.

      John Vollbrecht: Are there two states for methods? Jari Arkko: I
      think its more like a variable. Bernard: Methods can set a
      variable that makes it stricter, dumping id requeries and
      notifs. Its simpler. John Vollbrecht: You still have to know you
      are within the method state, that is the hard part.

      Jari Arkko: Strict is a SHOULD, stricter is a MAY. John
      Vollbrecth: i think we prohibited identity requeries. Bernard
      Aboba: That is ok with me. John Vollbrecht: The only thing you
      can do within a method is notification. Bernard: Ok, that makes
      sense.

      John Vollbrecht: I think we agree that all methods are strict (a
      SHOULD) and only thing that can come within this is
      notification. Some methods MAY prevent even this.

      John Vollbrecht: The next question is: do we allow authenticators
      to switch a method. I think its a non-question, if everything is
      strict. Bernard Aboba: I think it becomes a MUST NOT.

      Jari Arkko: But how come we have SHOULD for strict and MUST NOT
      for switch? Bernard Aboba: Maybe it should be a SHOULD for
      both. Jari Arkko: What is the reason that we can't say MUST and
      MUST NOT? John Vollbrecht: There may be implementations that do
      this. joe: the question is if there are implementations.

      Jari Arkko: I don't understand why we need switching. Please tell
      me.  Joe Salowey: For instance, we could find out in the middle
      of ms-chap-v1 that we can't do it. John Vollbrecht: That would
      make things very unclear for doing silent discard. My suggestion
      is to decide now and use either SHOULD NOT or MUST NOT.

      Jari Arkko: Why isn't this a MUST NOT? Bernard Aboba: It can not
      be, because implementations are not all strict now.

      John Vollbrecht asks Joe Salowey: Are you doing some work on
      compound methods? Joe Salowey: Yes I am, but its lower
      priority. John Vollbrecht: It could be very useful. Jari Arkko:
      Lets describe the compound problem first, then look at solutions
      later.

      Conclusion: MUST for strict, MUST NOT for switch, ask list
      whether we can be this tough or if a SHOULD NOT is needed
      instead.  Maybe this is not much an interoperability issue.

   o Can authenticator silently discard bad messages or should it fail?

     John Vollbrecht observes that there are the following cases:

     - Generic validity checks SHOULD/MUST cause silent discard. But it
       is not clear if passthrough can make all the checks.

     - Method specific validity checks.

     Bernard Aboba: In 802.1x, we check the EAP header for the first
     three fields (code, identifier, and length), but not the Type
     field. I think we should view passthrough ap as an IP router that
     only looks at the first three fields. John Vollbrecht: I'm not
     sure about this. Bernard Aboba: Well, its one way of explaining
     how things work.

     John Vollbrecht: I don't think we should limit the passthrough to
     avoid this check. Bernard Aboba: there are advantages to limiting
     what the passthrough does. Henrik Levkowetz: It wouldn't have
     worked for the method 254 (extended Nak) case.

     John Vollbrecht: But its more efficient to do it in the AP. No
     RADIUS traffic, less DoS attacks. Jari Arkko: There are three
     issues: There's a tradeoff between extensibility versus
     efficiency. Additionally, some folks believe that we need a
     layering model to make our specifications clear.

     John Vollbrecht: The state machine should allow validity checks.
     Jari Arkko: Agreed, and actually I think we must do this check. If
     it is unclear where it should be done, it could be left undone as
     everyone assumes someone else checked for it. At the very least,
     we need to require that the the check is done on the server. Could
     do it on the passthrough as well, as an optimization (but that
     would imply limitations to extensibility).

     John Vollbrech: The real question is whether methods are allowed
     to silently discard messages. We should take passthrough issues
     out of 2284bis and move them to 2869bis.

     Jari Arkko: I think we should avoid policy that specifies whether
     the checks are done. Instead, they should be required in the
     method specifications.  John Vollbrecht: I agree for the
     authenticator state machine.

     Jari Arkko: The next question is what the passthrough should
     do. John Vollbrecht: That is less clear. These are separate
     issues.

     Yoshihiro Ohba: I'm doing a state machine for passthrough
     authenticator.  John Vollbrecht: It is very useful to do a version
     of the auth state machine for this.  Paul Congdon: Not only very
     useful, we need to incorporate one to the 802.1x annex in early
     May!

   o Sequences

     John Vollbrecht: Should method sequences be allowed? Clearly, some
     sequences are allowed. For the 2284bis, we agreed in IETF #56 that
     we don't do general sequences except under tunnels. Jari Arkko:
     That's right.