Subject: [eap] design team minutes, jan 8th

From: [email-masked] (Jari Arkko)
Date: Wed, 22 Jan 2003 23:30:57 +0200

Date:       Wednesday, January 8, 2003 and thereafter
Time:       8 AM PST

Present: Bob Moskowitz, Jari Arkko, Bernard Aboba, Nick Petroni, Paul
Congdon, James Carlson, Yoshihiro Ohba, Glen Zorn

Agenda

o Discussion of EAP issues

   - See http://www.drizzle.com/~aboba/EAP/eapissues.html

   - Issue 60: Ordering guarantees

     James Carlson: The point is that unless we want to make incompatible
     change, then we are stuck with the assumption of ordering.

     Bernard: If its a slow link, the old response could still be
     coming. James: Yes, and it could be much worse if running over UDP
     over the Internet.

     Bernard: The question is if EAP takes care of some of these problems
     by itself.

     James: Here's the scenario: ID 1 is sent once, a timeout occurs,
     ID 1 is sent another time. However, receiver gets first of these
     messages and replies. Authenticator takes the response as the one
     for the first and sends the next message with ID 2. Now, the
     second and third messages swap places on the way to the peer. Peer
     thinks it has seen three messages, when in reality one was a
     duplicate.

     Bernard: This is a really good point, if you go back in the
     sequence space then you will be screw up the sequence space.

     Bob: Can radius reorder? Bernard: No, it will not, and it will not
     save the situation either.

     John: Why do we need ordering?

     Bernard: There is a requirement for 2869bis though: Authenticator
     must not send duplicates to the authentication server. No need since
     ppp side ordering is enough if the nas is killing duplicates?

     John: I'm still not convinced.

     Bernard: This works because the authenticator is keeping state and
     knows where it is. Whereas the peer does not know about the state,
     and can get confused.

     Bernard: There's a number of ways we can handle this. The original
     way is to require the identifiers to be unique. However, this limits
     the use of EAP to 256 messages. Also, we could limit the way
     identifiers are generated by the authenticator. However, RFC 2284
     has already been implemented and not all implementations might
     follow such limits.

     Bernard: This has happened in real life, we've seen it on a GPRS
     simulator. It has also happened in real-life 802.1x networks.

     DECISION: We have to put the ordering requirement in the
     draft. Bernard opens another issue for the rest of this problem,
     such as duplicate elimination before shipping the EAP messages over
     RADIUS.

     Bernard: Does the 802.1x access point handle the duplicate
     elimitation above? Paul: No.

     It would be really helpful if we could clearly articulate which role
     is responsible for which activity: ordering, duplicate elimination
     vs. link layer, access point, etc.

     Bernard: We don't need to think about this in DIAMETER, because it
     has an ordered transport. Jari: DIAMETER is not ordered end-to-end,
     only hop-by-hop. Bernard: T bit will fix this. Jari: I wouldn't be
     too sure about that.

   - Issue 59 Failed authentication and EAP Failure

     Nick raised this. Bernard thinks the proposed text is OK, but Nick
     has to make sure this gets to the state machine as well.

   - Issue 57 & 58 posted by Jesse are OK, and there's agreed
     text on the web site.

   - Issue 54: Can you have a NAK with no types? The current text is
     vague. It does say must have one octet in one place.

     The suggestion is to use the value of one when you have no
     alternative. This would initiate an Identity exchange. DECISION: It
     would be better to use an illegal value of 0.

     Bernard: Is it OK to have more than one value? RFC 2284 pretends
     that there can only be one octet. The understanding is that
     implementations would not blow up, and would only ignore the
     remaining bytes. James: There may be implementations that do a
     silent discard, but I expect a reasonable processing of even bad
     NAKs from good implementations.

   - Issue 51: How to allow for turning around the EAP authentication
     roles.

     Bernard: Does the 802.1x allow EAP runs in both directions. Paul:
     Yes, but these are independent.

     Bernard: We're keeping the peer to peer language in the draft
     because it is essential for some environments where EAP is used.

   - Issue 50: Media requirements. Bernard: We can live with duplication,
     (even if not ordering). John: I agree.

     Bernard: The media must have checksums or there may become problems
     for some methods. John: I'd prefer to say its better to have
     checksums. Bernard: I think that's what our intention is. But we
     really do need the checksums or otherwise there will be problems.
     John: I'm not sure this belongs to the EAP protocol description.
     Bernard: The IESG wanted us to define the transport requirements for
     later evaluation of new protocols that intend to use EAP.  So we
     need to do it.

   - Issue 23: Contents of the identity request payload.

     Glen: I'd reject this. Bob: I agree.

   - Issue 41: Paul Funk suggests a NAKking of extended types.
     We'll handle this on the list.

   - Issue 52: James Carlson suggests that identities be handled at any
     time.

     Bernard: The question is if you can switch method at any time. The
     background is that based on an analysis of the existing state
     machine there are potential attacks when the state machine provides
     too much freedom.

     What's the benefit of allowing identities? James: If the method gets
     confused, it can use this to get out of the method. Bernard: Why
     not require a method-specific message for this? James: Then we
     are setting requirements for all methods.

     John: Most implementations can accept some requirements on their
     methods.

     Jari: Are you trying to use Identity as an Abort? James: The
     original RFC 2284 gives all control to the authenticator. Changing
     this would be a break from 2284. Glen: Avoidance of DoS is perhaps
     one reason. James: I don't believe DoS avoidance can be done this
     way.

     James: Its an implementation issue on the client side what to
     do. If I get into trouble, I can still disconnect.

     James: The problem is that the protocol as originally defined does
     not include the restrictions you are suggesting.

     John: They do not change anything and they do not hurt, but
     are useful.

     Bernard: Why don't we take this one to the list, we don't
     have an agreement on this.

o Discussion of EAP state machine document (John Vollbrecht and Nick
   Petroni's Powerpoint slide set containing the new state machine)

   - John: I think we a model with three layers (methods, eap mux, link
     layer) is useful, even if James might not fully agree. Someone:
     Again, it would be clear if the roles of the different layers could
     be clearly articulated.

   - Paul: 802.1aa is coming to a ballot, and is in some sense
     fixed. But it doesn't mean that if a serious problem is found we
     wouldn't change it.

   - Bernard: The 3GPP is giving up a lot requirements to IETF on
     EAP. A meeting is coming up between IETF and 3GPP on 26-27th of
     January in San Francisco. The EAP WG probably needs to keep its
     deadlines for all work items, including the keying draft which is
     not in great shape.

   - Bernard: Issue 62 shows that the protected success/failure
     indication text is not very good. It would be helpful if people
     could take a look at the text and suggest improvements.