Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Charles Clancy <clancy@cs.umd.edu> Sat, 20 August 2005 15:42 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6VUf-0002TE-5J; Sat, 20 Aug 2005 11:42:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6VUc-0002Ss-V3 for secmech@megatron.ietf.org; Sat, 20 Aug 2005 11:42:47 -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 LAA26613 for <secmech@ietf.org>; Sat, 20 Aug 2005 11:42:44 -0400 (EDT)
Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6W4n-0007dy-Da for secmech@ietf.org; Sat, 20 Aug 2005 12:20:10 -0400
Received: from [192.168.0.2] (pcp04510339pcs.gambrl01.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc12) with ESMTP id <2005082015423501400qds9oe>; Sat, 20 Aug 2005 15:42:36 +0000
Message-ID: <43074F76.8000604@cs.umd.edu>
Date: Sat, 20 Aug 2005 11:42:46 -0400
From: Charles Clancy <clancy@cs.umd.edu>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Shumon Huque <shuque@isc.upenn.edu>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
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>
In-Reply-To: <20050820031035.GA5352@isc.upenn.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
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

Shumon Huque wrote:

> So for a standardized EAP method that supports Kerberos 
> authentication, we are awaiting the following:
> 
> 	- an updated GSS-API (for the pseudo random function)
> 	- an updated EAP-GSS mechanism that uses it
> 	- an updated IAKERB (for the AS and TGS exchanges)

A standardized tunneling method would be nice too.

Or, a generic Kerberos method secured with some KDC certificate, with 
bindings to EAP.

> And potentially running inside TLS to address the dictionary attack
> vulnerability of the AS exchange.

Right.

> I am very concerned that Kerberos sites are being pushed to deploy
> network access authentication today, and there is no suitable option 
> in sight for the forseeable future.

There are plenty of provisioning options.  For example, EAP-PAX could be 
bootstrapped by a kerberos password.  I've heard that MIT bootstraps PKI 
creds using a kerberos password -- those could be used for EAP-TLS.

Though, I agree no easy, out-of-the-box solution exists.

> 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 think the Kerberos community needs to work on standardizing password 
> based pre-authentication mechanisms invulnerable to dictionary attack 
> (perhaps EKE, AEKE, SPEKE, SRP etc). 

There are many intellectual property problems with these protocols. 
There are more complex protocols that don't suffer from the IP problems 
(http://eprint.iacr.org/2001/031.pdf) but they're more theoretical than 
practical.  Everything else requires a server-side certificate.

> At one time, some of us were talking about an EAP method that
> transported Kerberos messages directly. It seems to me that putting
> some effort into completing that work would be immediately useful
> to Kerberos sites that need to deploy 802.1X or 802.11i soon.

I've heard the same thing from other people as well.  Just make sure it 
runs in a tunneling method, or these directly transported kerberos 
messages are protected... DTLS maybe?

I think this is exactly the sort of thing SECMECH should be working on.

[ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

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