Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Shumon Huque <shuque@isc.upenn.edu> Mon, 22 August 2005 04:42 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E749D-0008C8-SL; Mon, 22 Aug 2005 00:42:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E749B-0008C3-GC for secmech@megatron.ietf.org; Mon, 22 Aug 2005 00:42:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07446 for <secmech@ietf.org>; Mon, 22 Aug 2005 00:42:54 -0400 (EDT)
Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E74jf-0002at-DB for secmech@ietf.org; Mon, 22 Aug 2005 01:20:40 -0400
Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 4E0BE443B; Mon, 22 Aug 2005 00:42:55 -0400 (EDT)
Date: Mon, 22 Aug 2005 00:42:55 -0400
From: Shumon Huque <shuque@isc.upenn.edu>
To: Charles Clancy <clancy@cs.umd.edu>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050822044255.GC27685@isc.upenn.edu>
References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <Pine.GSO.4.60.0508191330380.16954@ismene> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43074F76.8000604@cs.umd.edu>
User-Agent: Mutt/1.4.2.1i
Organization: University of Pennsylvania
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: secmech@ietf.org, Nicolas Williams <Nicolas.Williams@sun.com>
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org

On Sat, Aug 20, 2005 at 11:42:46AM -0400, Charles Clancy wrote:
> Shumon Huque wrote:
> 
> >Regarding dictionary attack, is it the case that we won't standardize 
> >an EAP method that is vulnerable to it? Or is the objection motivated
> >by the fact that EAP is expected to be commonly used for wireless
> >LAN authentication? I hope it isn't the latter, because it is almost
> >as easy to eavesdrop on wired ethernets with ARP spoofing for example.
> 
> EAP methods vulnerable to dictionary attacks cannot be used with WLAN. 
> See RFC 4017.  I don't think people are against standardizing a kerberos 
> method, as long as people know it should be run in a tunnel -- much like 
> EAP-MSCHAPv2.

I've read RFC 4017. My discomfort comes from the observation that
it is at best incomplete to point this out only for wireless LANs, 
since many of these vulnerabilities are applicable to other link 
layers too. If I use an EAP method that supports Kerberos on a 
wired ethernet for example, the dictionary attack threat still
exists. I do not find the differential magnitude of the threat a 
very convincing argument. It makes more sense to design security 
mechanisms with the uniform assumption that the network is always 
hostile.

This puts us in a position of having to say (whether we're using
EAP or not): "use Kerberos normally, except when running over 
link layers X, Y and Z, in which case you should run it only in 
a protected, cryptographically bound tunnel". If we need to address 
the dictionary attack problem, I think we should discuss how to 
do so in the Kerberos protocol directly. Perhaps that discussion 
belongs in another group though ..

I'm also not a fan of automatically assuming that a tunnel is the 
right solution for many problems. If we are tunnelling in TLS for 
example, I now have additional issues to deal with. Such as how to 
query up-to-date certificate revocation status, and whether my 
users are properly validating the certificates etc.

---
Shumon Huque				3401 Walnut Street, Suite 221A,
Network Engineering			Philadelphia, PA 19104-6228, USA.
Information Systems & Computing		(215)898-2477, (215)898-9348 (Fax)
University of Pennsylvania / MAGPI.	E-mail: shuque -at- isc.upenn.edu

_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech