Subject: [eap] EAP Design Team Minutes 12/18/02

From: [email-masked] (Bernard Aboba)
Date: Wed, 18 Dec 2002 09:51:49 -0800 (PST)

EAP Design Team Minutes 12/18/02
Scribe: Paul Congdon

802.1aa discussion

[1]  In Paul's ballot comments for 802.1aa/D4.1 he brought up some
     issues between the interface of 802.1X and the EAP layer.  There
     have been many new checks put into the EAP layer and subsequent EAP
     Methods that may cause silent discards or state changes the 802.1X
     layer may need to know about.  The current 802.1aa draft always
     assumes it sends a response to every request, so this doesn't
     support silent discards.  The two machines need to be looked at
     side-by-side to assure a proper interface exists for the expected
     behavior.

[2]  It was agreed to prepare a reconciliation between the two layers
     and present at the 802.1aa interim meeting in Vancouver (1/6 -
     1/10).  Paul to send mail to Tony to request a specific time for
     the AA meeting.  John and Bernard to suggest times when they could
     possibly attend the 802.1aa meeting to schedule this particular
     aspect.

[3]  Discussing the interface between media layers and EAP layers.  It
     should be simple handshakes and should avoid putting media into
     particular modes or states if possible.  Something that simply
     acknowledges the receipt of EAP frames from the media layer.

     EAP state machine discussions

[1]  We need to consider EAP DoS attacks that can come from the wired
     side as well now that pre-auth is part of 802.11i. With Pre-
     authentication, an attacker can authenticate to an AP, and then
     attack another AP within the same ESS. This means that EAP attacks
     do not have to be local, as would a DoS attack on an 802.11 cipher
     such as TKIP.

[2]  In the proposed state machine if any method in a sequence fails,
     the authentication fails.

[3]  There is a question about what happens on the peer when it
     perceives the authentication to have failed. For example, say the
     authenticator failed to authenticate to the peer, or it send a
     protected failure indication to the peer. Does the peer have to
     wait until receipt of an EAP-Failure? Or can it transition to
     another state immediately? What if the Authenticator thinks that
     the method is still ongoing and keeps retransmitting? How does the
     Peer terminate the conversation?  There is a need for the peer to
     be able to signal termination of the authentication.  A way to know
     that the peer has "hung up", so to speak. This is media specific,
     since not all media may have this ability. For example, with PPP,
     an LCP-Terminate can be sent; in IEEE 802.11, you can send a
     Dissociate or De-authenticate. But what do you do on an Ethernet?
     Lower carrier?

[4]  Some methods may support protected success/failure indications. In
     such a method, the authenticator will tell the peer that
     authentication has failed, and perhaps the Peer can respond,
     ACK'ing that assessment. In this case, assuming the exchange is
     completed, then both sides are in synch as to the outcome.

[5]  Retransmissions need to be checked by the EAP layer and tossed if
     necessary.  How will you know the frame is truly a retransmission?
     John: All the bits must be checked to know this and the EAP layer
     isn't currently doing that.  You can't just check the identifier.
     Bernard: Do you really want to require a comparison between a
     received frame and previously received frames for that identifier?
     Wouldn't this be creating a significant amount of work that would
     make a DoS attack easier? Remember, the underlying media is assumed
     to have a CRC check -- both PPP and IEEE 802 have this. If the CRC
     check fails, then the EAP packet isn't even processed by the EAP
     layer, it is discarded.

[6]  One possible approach here is for the EAP layer to queue packets
     for the method and then pass queued Requests up to the method, one
     at a time. If the EAP method replies with a Response, the EAP layer
     should empty the queue since there should not be any additional
     packets in flight. If the Authenticator retransmit timer is off, it
     may have retransmitted earlier before receiving a Response, but
     that is not of concern to the Peer - clearing those packets from
     the queue has no ill effects.  The Peer sends its Response; if a
     retransmission comes in after that, it can respond again; if not,
     it can handle the next Request. Clearing the queue is a DoS attack
     optimization.

[7]  If the EAP method didn't like the request it got (presumably
     because it failed an integrity check) it would tell the EAP layer
     "packet not accepted" and then the EAP layer will hand the next
     packet in the queue to the EAP method. Alternatively, the method
     could abort because it doesn't know how to handle integrity check
     failures (EAP TLS).

[9]  This implies that the EAP layer only does some basic checks: given
     the state of the method, is the Peer accepting packets other than
     Requests? Is the Type field acceptable? Is the length of the packet
     appropriate? There is no duplicate checking per se - the EAP layer
     just maintains a queue that is cleared after a Response is sent.
     This seems consistent with the behavior desired by Token Card
     methods. It could take a while for a person to enter in a Response
     - and if there is a retransmission during that time, you don't want
     to prompt the user again. You let them type in their Response, send
     it, clear the queue and then see if a retransmission occurs after
     that.

[10] Some methods may not be able to survive an integrity check failure.
     For example, Yoshi pointed out that TLS cannot survive a MAC
     failure, so that presumably EAP TLS cannot survive this either.
     Bernard agreed to check on this.

[11] Notification is handled differently than other methods. A
     Notification Request can be sent at any time, a Response is sent
     automatically by the EAP layer, and there is no state change
     resulting from this (other than perhaps Identifier state).  John V
     was under the impression that Notification Request cannot occur in
     the middle of the method, but this was agreed upon in a previous
     Design Team meeting.  In the ESTEEM draft we found the previous
     discussion that indicates the Notification Requests can be sent at
     any time and can't be NAK'd.  We will stick to this decision, and
     John agreed to update the state machine document to reflect this.
     On the peer side it is fairly easy to just respond to the Notify,
     but on the authenticator, you must process the Notification Request
     like any other packet, wait for a response and retransmit as
     necessary, etc.

[12] John would like to re-visit this issue before making the changes.
     Could we meet on the 27th in the early afternoon or the 30th (the
     following Monday).  Paul will get a phone line for the 30th to
     close this issue unless Bernard can secure the Microsoft line.