Subject: [eap] Minutes of the 12/11/02 ESTEEM Conference call

From: [email-masked] (Bernard Aboba)
Date: Wed, 11 Dec 2002 08:58:44 -0800 (PST)

Date:      Wednesday, December 11, 2002
Time:      8 AM PDT
Present:   Bernard Aboba, Jari Arkko, Bob Moskowitz, John Vollbrecht,
	   Paul Congdon, Glen Zorn, ?
Scribe:    Jari Arkko

1. Preliminary discussion

   This was the first meeting after IETF 55.

   Based on looking at the state machine drafts, they look good but not
   all design team decisions are yet adopted in them. The two drafts
   are being merged into one and some more issues are resolved in them
   at the same time.

   IEEE 802.1aa ballot may affect state machine. We encourage people to
   read the document and comment.

2. Discussion of EAP issues

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

    - 43: Security properties

       Jari: Worry about requireing proofs. Bernard: Yes, it may not be
       desireable. DECISION: We should encourage people to include
       references to proofs and other analysis, but not require
       proofs. Jari to write alternative text.

       Bernard: Is the text on dictionary attack sufficient? Glen: Does
       not sound too good yet. Bernard: Even liveness doesn't prove
       resistance. Glen: Last part makes sense. Jari: I would just put
       in that the spec must describe whether you are vulnerable to
       dictionary attacks. Glen: There is a difference between dictionary
       attack to a weak password vs. a method. DECISION: The following
       text can be used: Assuming
       there is a weak password in the secret, does the method allow a
       an attack better than brute force? John: There is a further
       distinction between off-line and on-line attacks. DECISION:
       Let's not describe different variants of dictionary attacks,
       instead reference text books on the subject.

       Key strength determination: How do we count key strength, do we
       count cleartext nonces during EAP TLS negotiation to the
       entropy?  There is some counter-intuitive input on this subject
       from known cryptographers. It is unclear if adding a PRF
       function will create additional entropy or not. DECISION:
       Bernard will ask the cfrg IRTF group what a good definition of
       key strength is, but we will not give a full definition in the
       specification.

   - 2 Alternative indications

       Bernard has new text on the issue site. Question: If after
       receiving a protected success indication within a method, do you
       accept unprotected failure after the method has completed?
       Bernard: The current text prevents you only from spoofing a
       success. If the method has not completed, you will throw both
       failure and success indications away. How all this is handled
       must be described in the state machines.

       Also, within a tunnel are the state machines separate or joined?
       Bernard: We should think them as a single state
       machine. Bernard: There are two issues here: whether the methods
       are completed or not, and whether the methods have sent their
       success/failure indications to the other side.

       DECISION: If the method hasn't told the EAP mux layer that its
       done, the failure/success indications will be thrown
       away. Bernard: A method will just tell the mux when it is
       done. It may not know exactly about its success, but it
       indicates that it has completed succesfully. If a method says
       success (e.g. within PEAP) and after that an unprotected failure
       comes, what then? Jari: It is enough with the current text and
       protecting the success. Protecting the failure may not make
       sense as there are other DoS attacks in any case, e.g., on the
       methods.

       Bernard: Is the primitive for completion just for my own
       success, or do we indicate also the other side's success? If we
       indicate the peer's success, then we could avoid spoofed
       failures. Jari: However, if we are running a sequence of
       methods, then it is no longer clear when a failure can be
       accepted. One possible semantics is that the protected
       indication applies only to what follows the protected method
       immediately -- but not what happens after the method. However,
       an attacker who can inject messages can always cause DoS by
       sending random messages, sending only the first message of a
       method etc.

       DECISION: We will provide an indication from a method for both our
       own completion as well as the peer's completion.

   - 25: Spoofing and duplicate detection

       This attack is like attacking TLS TCP, but easier since the
       sequence number space is smaller in EAP.

       Is there a difference in EAP methods as to how they want to
       receive their messages, either letting the Mux handle the
       sequencing or doing it by themselves using some kind of
       integrity protection to avoid these attacks. This is analogous
       to the TLS over TCP vs. IKE situation.

       Should we have a primitive from the method to the mux which
       says 'take me back to the previous sequence number'? This is
       also related to retransmission of broken packets. DECISION:
       We should have a primitive for tossing out messages that
       fail integrity protection.

       There's also a timing issue: What if the real message arrives
       during the integrity verification? DECISION: The state machine
       must act in a lock-step; the EAP mux will not handle any new
       messages before the method processing has indicates that the
       previous message has been either processed or thrown away.

   - 41: NAK of extended types

      This is has proven to be complicated if you mix regular and
      extended types. Bernard proposes that we only allow one kind of
      types in NAK.DECISION: We will allow NAK of 1 or more regular
      types OR a NAK of one vendor.

---

From: [email-masked] (Paul Funk)
Date: Wed, 11 Dec 2002 19:40:57 -0500

At 08:58 AM 12/11/02 -0800, Bernard Aboba wrote:
...
>      types OR a NAK of one vendor.

I don't think this is the right decision. This creates two classes of EAP 
protocol, one which supports negotiation and one which doesn't. It is a 
recipe for confusion, and vendors will be forced to create their own 
mechanisms as workarounds. Also, if there is any reality to the fear of a 
stampede for types under 255, this decision could set it off.

Remember, too, that one of the "vendors" is type 0, which provides an 
extension space for IETF protocols. Do we really want to say that 
IETF protocols over 255 aren't easily negotiated?

As requested during the Atlanta meeting, I sent in a proposal which I 
believe solves the problem. There hasn't been discussion of it on the 
list; I don't know if it was discussed in the conference call. I don't 
consider it complicated; in fact, I think it clarifies the relation between 
one-octet types and types in the extended 8-octet space. It preserves 
all the functionality of EAP negotiation for all types. 

"Type space extension" is part of the charter of this group, and 
arguably its most important mission. The type space can be extended 
seamlessly while respecting legacy implementations. I don't see why 
we'd want to stop half-way to a full solution.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 11 Dec 2002 16:01:05 -0800 (PST)

> list

Can you resend it? I don't recall seeing it come through.