Subject: [eap] 10/30/02 EAP Design Team Conference call minutes

From: [email-masked] (Bernard Aboba)
Date: Wed, 30 Oct 2002 19:24:42 -0800 (PST)

EAP Design Team meeting, Wednesday October 30th, 2002.
Minutes taker: Jari Arkko

o Agenda

   Discussion of unresolved EAP issues:
   http://www.drizzle.com/~aboba/EAP/eapissues.html

   Discussion of cryptographic binding problems:
   http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt
   http://www.saunalahti.fi/~asokan/research/mitm.html

   Latest RFC 2284bis draft:
   http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt

o Issue 2: Alternative indications

   - Should these be kept or not?

   - Are protected success and failure a form of alternative
     indications

   - Can the 802.1X messages be considered alternative indications

   - Proposal: rate of loss is low enough, not a problem. Bernard: But
     PANA folks are expecting to run this on GPRS!

   - Question: what is the right thing to do from a security point of
     view? Bob: we should require a success. Jari: depends on whether
     the indication is protected. Bernard proposes that if a protected
     indication is available, no alternative indications should be
     listened.

   - Is link up and down an alternative indication? Bernard thinks its
     a different issue. In PPP, you would get back to LCP.

   - EAPOL logoff, is it an indication or not? What if there's link
     layer security? Will it help?

   - Bernard: We probably need to listen to these alternative forms of
     failure indiciation. THis will open a DoS attack. Jari: The
     question is if this makes the situation any worse, there may be
     other equivalent attacks already.

   - Bernard: I don't like the argument but I can't argue much about
     it. Let's look at EAPOL logoff as an example. Attacker sends
     unencrypted EAPOL logoff messages to a multicast address. The
     access point will have to relay those to all devices on the
     wireless media, or even to the wired media. Debate whether peer
     swill act on this? Bernard: it doesn't matter, we can get mac
     addresses and send unicast messages.

   - Proposal (Bernard): Lots of ways to do these DoS attacks. Doesn't
     seem possible to ignore these indiciations.

   - Bob: we will see link ups and downs all the time anyway, we need
     to ignore them in case the link comes back online soon. Bernard:
     Agree.

   - Bernard: This is like IPsec and ICMP; most implementations don't
     believe ICMP but rather wait for an IKE timeout.

   - Jari: the action depends on link layer, e.g. l2tp vs. physical
     link. Bob: this should go to the link layer specific specs.

   - DECISION Bernard & Jari: if an authenticated indication exists,
     should not believe alternative indiciations (unless have to, like
     the link really went away). In the absense of authenticated
     indication, alternative failure indications may be accepted if the
     lower layer specs say so. Success indication should not be
     believed.

   - Jari: I'm still unsure about this. What if I have successfully and
     mutually authenticated the other side? Why would I not believe an
     alternative success indication. Jari promises to write something
     about this later.

o Issue 7: How to run multiple methods one after another

   - Bob: What would a non-supported peer do if it get another method
     and was expecting success or failure?  Bernard: This ties to the
     last issue. If it gets a packet it can't make any assumption about
     the state. In Windows, authentication will time out. In a later
     version with support, how would you know if the peer supports
     sequences or not?  Invent a new method to signal that you support
     them or have it written in the specification that the methods
     always support sequencing.  Or negotiate? Bernard doesn't want to
     add a roundtrip for negotiation.

   - Bernard: We also need to discuss whether the end points have to be
     the same all the time.

   - Questions: 1) How to do sequences? 2) how to prevent mitm attacks?

   - Question: Could we add a continuation flag to the header in a
     backwards compatible way?  (Bernards go look at the header.)

   - Question: Can we send a NAK? Bob: In the Windows version it just
     sits there and can't even Nak after having executed a method.  So
     we can't rely on Nak. The same applies to a new Command. So
     the end result is in any case a timeout. The good news is that
     all the latency is at the end.

   - Yoshihiro says that if this results in a failure it is not a
     problem. This is because if the authenticator wanted to do
     multiple methods, the authentication will fail anyway.

   - Bernard: Can we change the identity request to specify
     if the peer can do multiple methods? Or we could have
     this as a part of the user data base.

   - DECISION (Jari): Its better to take the timeout at the
     end for the people who will fail, than spend negotiation
     time for everyone at the beginning.

o Issue 10: Lack of authenticated success and failure indications

   - Bob: Security people want to have one point where success or
     failure is indicated.

   - Bernard: Can we require authenticated indications in some
     situations, such as for sequences or tunnels? Probably we can't
     mandate it for existing clients and the basic EAP situation.

   - Bernard: Can't have authentication until keys are generated. Bob:
     We can always do a Chap-like request-response which authenticates
     an indication.

     We could have an acknowledge-accept approach, and have it
     mandatory for some new places where EAP is used, such as
     GPRS or PANA EAP-over-IP.

   - Jari: One idea is that if someone supports sequences,
     they could use a protected success -method as the last
     one in the sequence.

   - Question: Is it sufficient to protect tunneled
     indiciations, or do we really have to support
     also secure indications in sequences? (No opinion)

   - DECISION: We can't put this in situations where
     there are no sequences or tunnels. The rest of
     the discussion has to be taken in IETF #55.

o Issue 13: Identifier usage not specified?

   - Can we specify it to start from 0? It appears
     more important to specify how it increases and
     how ordering / duplicates are detected.

   - Seems like the existing text is quite appropriate.
     Does not mandate too much, but specifies enough.

   - DECISION: Existing text is OK for #13 & #18.

o Issue 23: Contents of identity request payload

   - The problem is if we have enough information in Identity Request
     to be able to answer?  In most cases we have some lower layer
     information, such as the dialled phone number that tells you which
     identity to use. Do we need something like this in the Identity
     Request message?

   - Bernard: Should the authenticator tell its NAI?  Jari: Isn't this
     a chicken and egg problem, how can the authenticator know what to
     tell before it knows from which roaming ISP this user is from?
     Bernard: There's methods out-of-band to EAP for knowing e.g. that
     we clicked the AOL icon so we are looking to give AOL identity.

   - Bob: I'm working on an extension to give a list of NAIs in the
     identity request (or in the response). The request contents are
     treated just as an advertisement. Bernard: This sounds good.

o Next meeting

   - We will have a meeting next week (the last meeting
     before IEEE and IETF)