Subject: [eap] Notes from the 5/14/03 EAP Design Conference call (fwd)

From: [email-masked] (Bernard Aboba)
Date: Wed, 14 May 2003 10:36:45 -0700 (PDT)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 14, 2003 9:24 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Bernard Aboba

(I hope I didn't forget too many people from the participant list,
or too much issues from these notes :-)

EAP Conference call May 14, 2003
--------------------------------

At least: Glen, Nick, Bernard, Yoshihiro, Henrik, Pasi

Wow, what an echo! ...echo! ...echo..

Issues 121 and 131
------------------

While nobody currently implements lower layer indications, they
could be useful in some circumstances to avoid long timeouts.
However, we want to avoid the situation where the peer enables
the link but the authenticator does not.

Thus, I think the agreement was roughly:
- The peer may process lower layer success indications if
  it would be willing to accept an EAP Success packet at that point.
- If the peer has not received a method-specific success
  message OR a lower layer success indication, if it times out
  when waiting for Success, it does not enable the link
  (even if it has authenticated the authenticator).
- We need some text describing the limitations of lower
  layer indications. E.g. depending on the link layer,
  they may get lost; and they should not have naturally
  occuring "false positives".

These lower layer indications could be less well protected than
EAP Success, but it seems that an attacker who spoofs a lower
layer indication can't actually achieve anything, because at
that point the peer is anyway satisfied (e.g. has authenticated
the authenticator, if using a mutually authenticating method).
And if the environment contains active attackers, we are
presumably deriving keys anyway.

In 802.*, EAPOL-Key message is sort-of lower layer success
indication (since the server would not send it unless it had
succeeded). Certainly after the four-way handshake is concluded,
you know that you received access.

We also discussed if Finished message in EAP-TLS is a
method-specific success message. Each method can define
whatever it wants, but in this case it probably is: since
the peer's last response does not contain anything useful,
the authenticator can make its decision before sending Finished
(and if the decision is no, send Alert).

Issue 125
---------

TCP retransmission timers may not be appropriate for our
purpose (RADIUS server load is probably more important
than network congestion in our case). What should
the default be? How about random jitter? Will be
discussed in the mailing list.

This might also be a RADIUS problem. Glen will send some
comments to IESG, since 2869bis is in last call?

State machine
-------------

State machine should be ready for Vienna.

Best regards,
Pasi