Subject: [eap] state machine design team conf call minutes, jan 29th

From: [email-masked] (Jari Arkko)
Date: Tue, 28 Jan 2003 11:07:37 +0200

EAP State Machine Design Team Conference Call Minutes

Date:       Wednesday, January 29, 2003
Time:       8 AM PST

Participants: John Vollbrech, Bernard Aboba, Nick Petroni, Chuk Yang
Seng, Bob Moskowitz, Jari Arkko

Agenda

o  Discussion of EAP state machine document
    http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.txt
    http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.ps

    - John has been talking to Jim Burns on synchronizing the IETF and
      IEEE state machines for the authenticator, and John intends to go
      to the 802.11 meeting in Seattle if there's enough interest from
      their side to work on this issue.

      Bernard: It is unclear who on the IEEE side is the main state
      machine expert, and who cares most of the issue. John: Jessie
      Walker has been that person in the past at least.

    - John: Pre-auth in WLANs requires state machine changes. Bernard:
      Not really at the EAP layer. It just provides indication to the
      link layer about a change in its state machine. 802.11i is complex
      in the sense that authentication might occur before or after
      association. Unfortunately, there is no state machine to describe
      pre-authentication. Bernard's clarifications to the 802.11i state
      machine regarding this were not taken to the current
      specification. This does not affect EAP state machine however, as
      the signals to the 802.11i are the same.

      Bernard: Pre-auth changes the 802.11i state machine. Even before
      associating with a nearby access point, you move from the
      unauthenticated state to the authenticated state.

      Bob: No, this is not true. This is just authentication frames, not
      movements in the authentication state machine. Besides, 802.11i
      does not have a state machine, it only has some text about this.
      We are changing the moving state in terms of the 802.11i.
      Bernard: When you arrive at the AP, are you in state 1 or state2 ?
      Bob: State 1. Bernard: Maybe I'm wrong but the draft doesn't state
      this. Bob: Yes, its unclear.

      Jari: What happens if you are in state 1 after move? Bernard: Then
      you have to still do 802.11 open auth. Then you do EAPOL-Start,
      and the response will be the final 4-way handshake not the EAP
      run. Jari: what happens if the sides don't agree whether preauth
      has happend.  Bernard: The answer is that we need a state
      machine. Bob: If the station rebooted and lost the keys, the
      result would be a timeout since the expected 4-way handshake would
      not come.

      Bob: I'm going to go back and take a look at this. Bernard: There
      remains a lot of work to make this clear. John: Are we allowed to
      discuss this in Seattle? Bob: There are so many comments that only
      comments will be discussed during the main meeting. It is
      important to pick the comments that indicate the need for the
      state machine. John will contact Dorothy in order to ensure that
      there's enough people willing to work on these issues.

    - Bob: With the state machines, the methods have to take on new
      tasks they didn't have before. Bernard: That's not right. Bob:
      Announcing that a key is available is one such thing. Bernard:
      Yes. But it isn't clear that the switch sends the "key available"
      event forward immediately after the method has informed it about
      it?  Bob: We need a section about guidelines for method
      implementers in the document. John: Yes.

      Bernard: If the EAP method provides keys, at some point, is that the
      required signal? Or is there something additional required to push the
      key in use? The problem is that in some cases the keys should be used
      immediately, and in other cases they should be used later. Bob: This
      is a method issue. We need to describe what information the method
      is expected to provide to the switch.

      Is this breaking methods? Bernard: This is an implementation
      issue, does not change what goes over the wire. Bob: But we are
      formalizing things more now with explicit variables in the state
      machine etc. Bernard: RFC 2284 was vague. As we are making 2284
      bis a better document, we may in some cases make some behaviour
      unallowed.

o Open issues

    - Bernard: Paul Funk and Bernard have talked about issue #41.  Paul
      is saying that if you send an extended method, you should respond with
      an extended Nak. Bob:

    - Bill Arbaugh will provide an opinion on the other two.

o Other issues

    - John: We are getting to a situation where methods are link-layer
      dependent. Bernard: No, link layers such as 802.11i just set a set
      of requirements such as mutual authentication and key generation.

    - A 3GPP - IETF conference was held this week in San Francisco.  The
      main question 3GPP had for the EAP WG was how many documents the
      WG has to finish before methods can be written. The intention
      is to try to get it down to a small number. The intention is to
      move normative requirements for methods from the keying framework
      to 2284bis document.

      3GPP will also need the DIAMETER EAP, key wrap, DIAMETER NASREQ,
      EAP SIM, and EAP AKA documents as references in their
      specifications. Additionally, the keying framework document is
      likely necessary for the security review when we are publishing
      e.g. the DIAMETER EAP and key wrap (CMS) documents.

      John: We also need guidelines on what the method implementations
      must do, the small things such as what you do when you receive a
      malformed message. Bernard: We have language in the latest 2284
      bis that says what to do in this case. EAP TLS doesn't do this,
      however.

    - RFC 2284 bis will get a new editor. A note on this will be posted
      to the list this week.