Subject: [eap] state machine design team minutes

From: [email-masked] (Jari Arkko)
Date: Thu, 06 Mar 2003 18:56:31 +0200

Date:      Wednesday, March 5, 2003
Time:      07:00 - 08:30 AM PST

Present: Nick L. Petroni, Henrik Levkowetz, Jari Arkko, John
          Vollbrecht, Paul Congdon, Bernard Aboba

First set of minutes
Scribe: Jari Arkko

o  Agenda

    - Reconciliation of EAP State Machine docs and RFC 2284bis

o  Draft status

    A new state machine draft has been submitted. It is available from
    http://www.cs.umd.edu/~npetroni/EAP/ before it makes it to the I-D
    directories.

o  Pasi Eronen's question

    - Pasi Eronen has asked on the list whether a request for a new
      method is allowed before the previous method has completed.

    - John: Here we are performing an EAP method, and the authenticator
      believes the client has failed. The question is, do we allow
      that? What if the client believed it needed to continue?
      Reportedly SIM and AKA might be able to detect failure before
      the method has fully completed.

      This sounds dangerous from a security perspective.

    - Bernard: This issue is number 87 "Handling of EAP Type change" in
      the issue data base. Our specifications must be backwards
      compatible. Most current implementations would hang upon this.

      John: How is this different from a method that has variable
      number of messages? Methods must be able to say when they are
      done. Bernard: this is already the case.

    - John: The issue is what happens when authenticator fails, can he
      send Failure immediately. Unclear whether the state machine does
      this or not.  Bernard: RFC 2284bis and the state machine both say
      the failure must be accepted. (John wasn't sure about this.)

      Also, method switching is considered as a sequence. The
      specifications allows the functionality, but warns that it
      doesn't really work with existing clients. RFC 2284bis and the
      state machine are again in agreement.

    - Henrik: I think Pasi is saying that there might be a
      method-specific failure. Nick: The question is if the method
      should be able to fail gracefully. Bernard: No this is not
      required anywhere.

    - John: My problem is this: All of a sudden I am requested to do a
      completely different method from what I am executing right
      now. What am I supposed to do? Jari: You either support this or
      not. Bernard: You don't need to do anything special, the MUX just
      does not send anything to the first method any more. John: But
      there must be policy about this, I just killed the current
      method. Bernard: methods could install filters.

    - Summary: (1) Methods can change in the middle. (2) Support not
      likely in current implementations.  (3) RFC 2284bis and state
      machine are in sync. (4) Parallel methods are not supported.

o  Filtering

    - Are success and failure acceptance also governed by
      filters?

    - What is the benefit of the filter? John: Just denial-of-service
      protection.  Nick: I think filters are overly complex. Someone
      else: its simple, but it confuses the operation of the protocol.

      Nick: In the state machine, is it parseReceivedMessage() or policyAllow()
      who actually performs the filtering? parseReceivedMessage() does not do
      more than simple parsing. Jari: But policyAllow() only provides
      the capability to Nak, not to silently discard. One way to fix
      this is to return three values from the policyAllow() function.

      Bernard: PolicyAllow() shall not be a substitute for a good
      specification. John: But its not complicated. Just a question of
      whether to accept or nak a method.

      Bernard: What's in the nak? The current method?  But what would
      the authenticator do, silently discard that Nak if some attacker
      had sent the request?

      Bernard: In practice many methods do not allow Failure in the
      middle. Nick: so it would make sense to fix RFC 2284bis to align
      with this. Bernard: Its what john explained: "I just want this
      type until I'm done". Jari: Ok, then I don't worry about the
      complexity any more.

      Nick: What we need is a third procedure, not parseReceivedMessage() or
      policyAllow(). Bernard: Its like this: filter is either installed
      or not. If installed the code has to match the current method.

    - What are the changes in the peer state machine due to this?
      There's either a new variable (not_interruptable), or a new
      state. There was a discussion on which approach is better, but
      we did not produce a conclusion. Nick and John will talk about
      this offline and resolve it

      Paul: Be careful to not end up with two true exit conditions
      after the Dialog state.

    - Bernard: What does this imply about validity checks in general?
      How is a MIC failure handled? Nick: I can silently discard today,
      if you look at the state machine. John: It is allowed but most
      methods don't do it.

    - Paul: The filter concept needs to consider Notifications. It
      can't just look for frames of the current type and Failures.

o  Identity appearing at any time (issue 52: identity requery)

    - Bernard: I have another question: can identity be sent at any
      time, like a notification? John: I think we agreed that it
      shouldn't come in the middle. Bernard: Yes, but identity is
      different because we can't nak it like methods. Nick: What are
      the options, either you discard or answer?  Bernard: Yes.

    - Bernard: For methods, if you accept a method in the middle then
      its an abort for the current method. Here, its not
      aborting. John: But it is an abort, not treated like a
      notification. (Everyone agrees). Bernard: can someone post a
      response to issue 52? I think we got a response to 52, 80, and 87
      then.

    - Bernard: if you install a filter, then you'd throw identity
      requests away as well. But if we receive it, do we have to
      respond always? John: unclear now, but that's what we'd be
      saying. Bernard: I have to check what RFC 2284 said about
      this. John: We can always respond with an empty response.  Jari:
      What if filter is on, do we still respond like that? John: no,
      then we just throw away.

    - John: Is the identity a global variable that other methods should
      be able to read? Bernard: There's no communication between
      methods. But identity response is a global variable. It is
      available to any methods. John: Is there a reason to not allow
      other variables? Bernard: It would be implementation specific and
      would cause EAP to not interoperate well. The situation in EAP is
      already getting bad, because people are putting all kinds of
      strange things in it. John: But it would be useful to communicate
      things within a sequence. Bernard: If we start to go the
      authorization area, the IESG will shut us down! John: I suspect
      people will do this anyway. Jari: We can monitor method
      specifications as they appear in IETF, and request them to be
      changed if they break the EAP rules.

o  Administrative

    - Bernard: What i'd like to have for IETF #56 is a clear
      recommendation on what to do for each of the issues, and why. We
      have to discuss on the design team list what the text changes
      are, and what the recommendations are.

    - Jari: We will have the next design team meeting on Wednesday
      March 12th, and also in the IETF before the thursday meeting.

Second set of minutes
Scribe: Paul Congdon

o  Pasi's issue about Authenticator's requesting before previous completion

    1. Doesn't seem to be compatible with current implementations.  John V
       is asking a question of whether we want to support the ability to
       switch methods in the middle. Bernard feels strongly that we can't
       support this because it will hang current implementations.

    2. The current state machine proposal (according to Nick) will
       accept a failure message in addition to any EAP packet of the
       expected type. Everything else will be tossed (in theory), but
       what you want to do is NAK new requests.

    3. So according to Bernard, what Pasi is saying is already in the
       state machine and 2284bis. This would look like a sequence and
       would be dealt accordingly. In today's implementations, most
       won't respond to sequences and will hang. We are recommending
       that people respond with a NAK and the state machine supports
       this.

    4. John's interpretation of Pasi's proposal is that you should be
       able to start a new method and have it complete when the
       previous method hasn't completed correctly.  John wants to know
       if future implementations wanted to support this or not.

    5. Looking at the current Peer machines, it looks like this is
       handled in the parseReceivedMessage() routine.  If the method
       knows how to support seeing a new type, then it should work, but
       this isn't recommended.  The Policy.allow() results for the
       method determine what to do, either NAK, silently discard or
       continue on.

    6. The filter concept needs to consider Notifications.  It can't
       just look for frames of the current type and Failures.

    7. No support for parallel methods (issue #94).  This is outlawed.

    8. The exit conditions from Dialog need a little work to determine
       how the filter concept can be included.

    9. I'm not sure the Pasi resolution actually works (IMHO) because
       if we are going to allow a new request without terminating the
       previous one, the state machines don't really support this
       because you will have two methods running at the same time.  If
       there isn't a proper termination of the first method, the next
       method can't really start off.  Bernard asserts that we are
       saying that only requests of a particular type are delivered to
       methods of a particular type, but if the previous method is
       going to allow switching to a new method, it must terminate
       itself somehow, but it isn't clear where this is done to me.
       The method-state variable must also be set in Dialog and not
       just Method if it isn't going to terminate itself because a new
       method is started.  The policy.allow() function must also be
       changing method-state.  Not clear this is articulated well.

o Issue #52, #80, #87

    1. We are not going to allow identity requests in the middle at
       anytime.  They would be treated like sequences and methods
       themselves

    2. It is just like any other method, but it can't be NAKed for
       backward compatibility.  So, if the filter is on, then it will
       be discarded.  What if the filter isn't turned on?  Do you
       always have to respond to it?  You can't NAK, so you must
       ignore.