Subject: [eap] minutes from eap sm dt conference call, may 28th

From: [email-masked] (Jari Arkko)
Date: Tue, 03 Jun 2003 15:52:58 +0300

Notes from the EAP State Machine Design Team conference call

Date:       Wednesday, 5/28/2003
Time:       8 AM PDT

Attendees: Nick Petroni, Jari Arkko, Bernard Aboba, John Vollbrecht,
            Paul Congdon, Glen Zorn

Scribe: Nick Petroni, Jari Arkko

O Agenda:

   (A) Open EAP issues found at http://www.drizzle.com/~aboba/EAP/eapissues.html

   (B) 802.1aa convergence
       http://www.ieee802.org/1/files/private/aa-drafts/d6/802-1aa-d6.pdf
       (userid: p8021 password: go_wildcats)

o DISCUSSION ABOUT 802.1AA, 802.11I, AND EAP
   ==========================================

   (A) MUTUAL/BI-DIRECTIONAL AUTHENTICATION

   Paul- What do we need to talk about on the .1aa draft?

   Bernard- What do you have to do if you have two bridges who want to
   open up ports to one another?  Bernard thinks that the conclusion is
   mutual authentication implies that both links can come up and you
   can do spanning tree between them both. D6 suggests auth in both
   directions.

   Paul- there is a difference between mutual auth and bi-directional.

   Bernard- D6 says must do in both directions, but doesn't seem
   necessary.

   John- I don't think we intended to specify that bi-directional
   authentication is needed.

   DECISION: All parties agree is you don't need bi-directional, and
   that the D6 needs to be clarified. Bernard's summary: no need to do
   it to get these links up.

   Question about controlled port on peer side: was that in d5? No,
   started to go down that path but it requires a more symmetric model
   (Paul). Put back in a variable on the supplicant, but don't gain a
   controlled port. It does not fully work, the specification handwaves
   this.

   Bernard- People like linksec conclude can't do spanning tree, but
   there is actually a link that is up.

   Paul- port auth state on supplicant doesn't control link up/down so
   spanning tree would need to know to look at that variable instead of
   just linkup/down.

   Bernard- Jesse believes EAP can't work in peer to peer, but it
   appears to us 802.11i is broken, it may not understand EAP. 11i says
   bi-directional, not mutual. 11i seems broken in this regard.

   DECISION: Clarify that this is not necessary in 2284bis.

   (B) LINK UP

   Point made about link up and how it does not always occur when EAP
   finishes (e.g. 802.11i not until after 4-way handshake). Also, link
   up implies multiple things, such as movement detection, sending dhcp
   packets.

   Discussion on disjoint between 11i, 11f, etc for when the processes
   start. IAPP starts but secure association is not yet up. another
   problem, 11i has 2 association protocols. You can take people of the
   network by sending the unprotected association messages. Problem goes
   away if only the 4-way handshake is dealt with.

   (C) PLAN FOR PROCEEDING

   Paul- We still don't have annex f, which is intended to be EAP state
   machine.

   DECISION: Start putting state machine into .1aa, simultaneously
   clean up discrepancies, then we are down to the last nits. John
   will have a new state machine draft by next ietf. Try to get it
   before the ballot is run. Bernard says state machine can become a WG
   item by ietf 57.

o OPEN ISSUES
   ===========

   (A) ISSUE 138 (MISCELLANEOUS -03 ISSUES)

   Brought up on the list, think it's closed...

   (B) Issue 139 (RESPONSE TO DUPLICATE REQUESTS)

   Issue Summary: 2284 says discard new requests while waiting for user
   input on the previous copy of the same request, but Nick asks why
   not just respond.

   Bernard and Jari came to same conclusion independently. Question is
   why is it there in the first place, answer is about avoiding
   unrepeatable user input or generating new values for some
   cryptographic tokens such as nonces. Issue is that we have not
   defined the semantics of how or when to process these requests.

   Jari- State machine is OK in this respect today. Might be useful
   to clarify text in the state machine draft that the full actions
   list is executed atomically, not just individual procedures.

   DECISION: No reason to silently discard assuming you are actually
   just retransmitting and just process each packet in the order they
   come in (no going back to user)... Text to be written. Let's bat
   around on the list for complete text. (scribe's note: and it has
   been discussed now, and closed.)

   (C) ISSUE 141 (MINOR NITS)

   Issue summary: Pasi proposes some reformulation of text, as well as
   removing keyword language from the terms section.

   Bernard- MSK deletion is Ok, no longer needed.

   Jari- Some keyword language should perhaps be rather moved
   to the normative sections than simply being deleted. Would like
   to keep the cryptographic separation text, too.

   Bernard- SASLPREP dependency is worrying. Only one example and it's
   not done yet, maybe this is actually a dependency? This could delay
   2284bis if IESG insists on treating this as a dependency.

   DECISION: Some things in this issue are Ok, the rest has
   to be discussed on the list (scribe's note: and it has been
   discussed now, and closed.)

   (D) 134 (EAP TRANSPORT ISSUES)

   Bernard- I haven't come up with text yet.  Restrict conversation to
   EAP retransmission problems. Not that there is MAC backoff, not like
   nothing would be  happening without EAP. Does it  make sense to have
   EAP backoff also? How do these interact?

   There are questions about where timer is (what protocol layer),
   whether it should be dynamic, what the parameters for the timers
   are, what specification changes we need, and about 802.1X
   retransmissions:

   - Protocol layer:

     John- This is also about end-to-end vs. hop-by-hop
     retransmissions. Who retransmits? Bernard- The EAP authenticator?
     John- But its always the link layer who actually sends
     it. Bernard- No, both may do it. Therefore the timescales should
     be different. Jari- Are there non-retransmitting link layers?
     Bernard- Yes, 802.11 for instance. Jari- Its very different for
     the two cases. Bernard- The MAC layer transmission is very
     different from apps layer ack. You don't see an eap response in
     the 1 ms that you see the link layer ack.

   - 802.1X retransmissions:

     Discussion- it appears there are three layers of retransmit in 1x-
     .11, 1x, and EAP. This is not what should be happening. It appears
     separation of 1x and EAP has started a bug. Bernard- Now that they
     are separated, 802.1x retransmission makes no more sense. Paul-
     but they are still there. Jari- three layer retransmissions. Paul-
     The time scales are ms, s, longer than s. Bernard- But the
     timescales are the same in radius, in the order of s. Seems like
     the 8021x/eap separation is causing a bug. Paul- this needs a big
     change to the 802.1x document. DECISION (Bernard)- Move the
     retransmission behaviour to the EAP part.

   - Dynamic vs. static timers:

     Bernard- The question is if the timer should be dynamic vs. fixed
     Currently 802.11i has a fixed timer

     Jari- Question: Is the estimation per session or per
     node/interface? Bernard- That's the question. Is it medium to
     medium? Is it per access point? Or does it vary per sessions? The
     reality is that some stations are much slower. CPU on the host has
     the same effect. Jari- Wireless distance may lead to lower rate;
     same equipment pair has a different RTT depending on distance.

     Jari- Where does that leave us? Bernard- Do dynamic estimation but
     lower RTO MIN to 300 but do it on a per-session basis.

     John: why not just do static? Bernard- We've seen this with
     radius, people will pick wrong values.  Jari- I think dynamic
     estimation makes sense. you can still have people specify
     rtoinitial with a specific value in a specific situation.

     John- Looks good, but I'm still not convinced that we need to make
     it dynamic. Jari- Look at tcp. Bernard- What would make sense in
     your case is per-media initial values. John- If you are going to
     configure defaults, why not configre the static timers. Jari-
     Because it works most of the cases, and with static people would
     get the timers wrong in a large fraction of cases.

     Bernard- The real problem is radius timers. John- Agree, that has
     to fixed. Glen- There are interacting timers on eap and radius. If
     eap timer is too short, this will cause a radius storm. Bernard-
     if its the same EAP id field value, this does not result in a
     radius storm.

   - Parameters for the timers:

     Jari- Second granularity/minimum sounds very high for fast
     movements.

     Discussion between bernard and glen- two different parameters number
     of retries and how to retry.

     Glen- TCP has different goals. Needs to get data through any
     case. Here, we don't care after some amount of time.

   - Specification changes:

     So what about the state machine? what needs to change? Multiple
     ways for timer to be set- radius message or some defaults. what
     should that be? originally was 6 seconds. Decided to change, but
     to what? Dynamic retransmission estimation is the default. what
     are the correct values, etc?

o OTHER ISSUES
   ============

   (A) EAP TLV

   Glen- I was under the impression that EAP TLV would go to the main
   document. So I'm wondering if that's going to happen.

   Jari- Is there a reason why this can't be a separate document?

   Glen- No reason, it already is in a separate document. Thinks we
   agreed that protected success/failures are to be included in
   2284bis.

   Bernard- We agreed to talk about the issues in them, not necessarily
   include them. Problem is that since sequences are not
   supported. Thus TLV would be either method specific or require
   tunnels.

   Jari- There is interest in tlv, but need to do it as another
   document.

   Bernard- Agree, 2284bis and keying framework need to produced before
   doing anything else.

   DECISION: Blocked form doing anything until 2284bis and re-keying
   are done. Just get them done and then look at other things such as
   TLV in future works.

   (B) KEYING FRAMEWORK

   Will keying framework become WG item when it fills Russ Houseley's
   requirements?

   Must describe AAA, 802.11i, etc. interactions. Basically asking for
   a security proof. Not clear how far we are from meeting these. Might
   need a discussion on what is needed and why. There is a bunch of
   stuff that is there and now. With redirect in AAA we can make new
   claims, the problem seems easier without the need for end-to-end
   security.

   Bernard will go through it to make sure what needs to be there is or
   rewrite.