Subject: [eap] state machine design team minutes, feb 12th, 2003

From: [email-masked] (Jari Arkko)
Date: Sun, 16 Feb 2003 10:06:15 +0200

EAP State Machine Design Team conference call minutes

Date:       Wednesday, February 12, 2003
Time:       8-9 AM PST
Scribe:	    Jari Arkko

o Participants: Jari Arkko, Bob Moskowitz, Nick Petroni, Chuk Yang
   Seng, John Vollbrecht, Bernard Aboba, Paul Congdon (maybe more)

o Agenda

   - Discussion of EAP Issues
     http://www.drizzle.com/~aboba/EAP/eapissues.html

   - 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

o Issue 74 -- Concern on an invalid MIC

   This issue relates to the handling of duplicates, particularly by
   passthrough authenticators when the method supports a per-message
   MIC.

   John: Normally you have a MIC as a part of a method. You could
   specify perhaps it at an eap level, but not clear how to do it.

   Nick: The way I read it, is that if you have a fragment, the
   passthrough sends the wrong packet to the AAA and the real packet
   will be throgh away.

   Bob: This is very hard, we shouldn't open even the discussion.
   Bernard: It is an EAP state machine issue, not MIC specific. its
   really about duplicate elimination.

   John: One possibility is to allow MICs. The mechanics were that in a
   passthrough you would forward responses to the backend. When it
   sends the next request you would start waiting for new messages.
   Bernard: That's the way things work now.  the identifier doesn't
   change until a new request arrives. All this means that you don't
   silently discard until you get a new request.

   Bernard: You don't send all the messages to AAA at once, because it
   is illegal in RFC 2869. In all cases if the mic fails you will send
   a reject. John: We need a message that says "I got it but its not
   good". Bernard: In RADIUS, we can't send new Access-Requests until a
   response is received. In RFC 2869bis, instead of sending a new
   request, the AAA server sends an EAP-Start as a response. Then the
   NAS continues to expect more messages from the peer. Jari: This
   makes sense to me. Nick (?): I'm not sure. (After some
   clarifications we finally agree: 1. We must hold on to messages and
   2. One message at a time to AAA.)

   Question: Is the MIC per fragment or per "message" that makes sense
   to the method? Jari: MIC has to be per fragment. Otherwise you can
   get to a situation where you have to accept a fragement, but will
   detect later that there's been a bad fragment. At this point, it is
   no longer possible to reject the fragment.

   Bernard: Existing methods such as EAP TLS work, because MIC failure
   is fatal. but allows the construction of methods that do.

   John: We should not talk too much about MICs in the documents.
   Bernard: Yes. Need to restructure the documents and take the MIC
   text somewhere else.

   Paul: I wonder if it should be a new message and not
   EAP-Start. John: I agree. Bernard: It has to be EAP-Start.

   John: Yoshi's argument on the list: If there's a DoS attack, you
   should just start over again.

   Jari: There's a difference in building in MICs vs. fixing the state
   machine so that it works the same way for passthrough and regular
   authenticators.

   Bernard: We need to do this to clarify the specification.  John: I
   fear state machine fix is not easy. Bernard: Your state machine does
   this now!

   Paul: Isn't this the only way to fix DoS attacks?  John: This may
   make attacks different or worse, not completely fixable. Bernard: Its the
   same issue as in TLS vs. IPsec; TLS is vulnerable to MitMs and as a result	
   the peers may have to start all over again.

   John: The the SIM example: the choices are stopping or handling all
   packets. Not sure about which uses more resources, cpu, memory etc.
   Bernard: The same issue is in 802.11i CCMP vs. TKIP protection.

   Bernard: If you look at protocols and literature, the agreement is
   that silent discard is the right thing to do. All new protocols do
   that. John: I'm not sure its worth it. Jari: I'm not sure either,
   but I'd like to get back to my earlier argument about other reasons
   e.g. make the behaviour over passthroughs and integrated NAS-AAA the
   same -- we don't have to decide about MICs right now. But I'd like
   to have a protocol that behaves the same way in all cases,
   regardless of the usefulness of the MICs in potential future
   methods. Bernard: I agree.

   Bernard: Take the EAP SIM as an example. It would be possible to
   protect messages with a MIC in there. Jari: I don't think we do it
   right now. Bernard: And there's a few messages in the beginning that
   can't yet be protected before the keys are in place.

   Paul: We need to reset timers when you get EAP-Start. Jari: Why?
   Paul: Because when the access-request is sent, the timers are
   stopped. Jari: Ok.

   Bernard: There's an additional reason to do what we are suggesting
   here.  We may need to do this because not all EAP transports use a
   CRC -- so even a bad packet could get to an authenticator and cause
   the whole process to restart.

   Bernard: Here's what I think we have now concluded:
      - RFC 2869bis will have 4 week IETF last call.
      - We will take all MIC discussion out of the docuemnts.
      - RFC 2284bis will not to discuss this issue at all.
      - RFC 2869bis will expect new message identity only
        after receiving a new request from AAA.
      - We will ask Bill Arbaugh's opinion on the DoS issue.

   Bernard: The only question in my mind is if a method would actually
   use this? Someone: I would think the per-fragment issue would make
   things hard anyway. John: DoS not defendable anyway.

   Bernard: EAP, RADIUS have been found to be the most vulnerable in
   future WLAN networks, not 802.11i!

   Bob: There's interesting attacks on EAP. For instance, override
   messages against eap servers. John: We should document these
   issues. Bernard: We should have an appendix in RFC 2284bis that
   talks about these issues and warns implementors.

   Question: Is the new duplicate detection scheme for passthroughs
   mandatory? And for who? Bernard: Its optional for the AP. John: No,
   it needs to be mandatory. Bernard: Ok.

   Question: What is the backwards compatibility? (No answer)

   John: There's a problem in that when this retry process is going on
   with the AAA server and NAS, you tie up the client too, because the
   client hasn't got a failure back yet.

   Jari: Bernard said this kind of functionality already in 802.1aa.
   John: No problem with that.

   Nick: The only question is what to do with the new request, should
   it be retransmitted or not? (Unclear to participants if something
   needs to be done or not). John: No problem with EAP start that I
   know of.

o Status of the state machine drafts

   Jari: What is the status of the state machine drafts?

   Nick: We are reluctant to put anything forward until all issues
   resolved. Jari: Everything included that we have agreed? Nick:
   Probably, not sure. John: DoS issues unclear also in the state
   machine. Nick: Also, not all agreements are clear. Paul (?): Can we
   articulate the unclear points and the assumptions? Nick: I will post
   this together with John.