Subject: [eap] Comments on draft-puthenkulam-eap-binding-01.txt

From: [email-masked] (Puthenkulam, Jose P)
Date: Fri, 13 Dec 2002 11:16:52 -0800

Hi Bernard,

These are all good comments. And its really positive to have an open
discussion on the list
to get more input from others in the working group. The current plan is to
have a revised draft
submitted in early Jan taking into account some of these additional areas
which the draft
didn't address as we were racing to make the IETF#55 deadline :)

best regards,
jose
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Jose Puthenkulam
   Senior Software Engineer
   Emerging Platforms Lab
   Intel R & D
   Intel Corporation
   2111 NE 25th Avenue, JF2-58
   Hillsboro, OR 97124
   Tel: (503) 264 6121
   Fax: (503) 264 8154
   Email: [email-masked]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, December 12, 2002 4:24 PM
To: [email-masked]
Subject: [eap] Comments on draft-puthenkulam-eap-binding-01.txt

This draft describes aspects of MiTM attacks that can be mounted against
compound EAP methods. At IETF 55, there was consensus that this was a
problem that needed more work. The first step in that direction is to
complete the problem statement. This is the core of what this draft is
trying to do, I think.

However, in reading through it, I think it doesn't do a very good job in
several aspects:

a. Motivation for compound methods. One obvious solution to the problem of
compound method security is to say "don't use compound methods, use strong
simple methods instead." So some justification for the use of compound
methods needs to be included in the draft.

b. Discussing vulnerabilities of EAP method sequences. Are the same
attacks launchable against sequences? In what scenarios? The discussion is
mostly focussed on tunneling.

c. Discussing the circumstances in which the attack can occur. For
example, can the attack occur when the tunnel authentication is mutual? If
there is no credential reuse? What role can policy play?

d. Discussing the *incremental* vulnerabilities created by compound
methods. This is very important in understand what problems are *created*
by compound methods, and which problems are inherent in the scenarios
being discussed. For example, when dealing with "legacy" methods (e.g.
methods which do one-way auth and don't derive keys) and wired networks
(e.g. PPP and IEEE 802) there is an inherent vulnerability to hijacking.
Therefore the scenario is inherently insecure from the start -- and so the
question is not whether security is present (it isn't) -- but how compound
methods make the situation *worse*.

e. Discussing the requirements for a solution. What would a "solution" to
the "problem" being defined look like? What should we expect from a
"solution"? For example, would a solution prevent offline attacks against
weak tunneled methods? Would it apply to all EAP methods, or just some
subset? If it only applies to a subset, why does this subset benefit from
tunneling?

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap