Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Shumon Huque <shuque@isc.upenn.edu> Sat, 20 August 2005 03:10 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Jkp-0001Yi-3A; Fri, 19 Aug 2005 23:10:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Jkn-0001Yd-NC for secmech@megatron.ietf.org; Fri, 19 Aug 2005 23:10:41 -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 XAA19522 for <secmech@ietf.org>; Fri, 19 Aug 2005 23:10:38 -0400 (EDT)
Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6KKr-0000bU-Br for secmech@ietf.org; Fri, 19 Aug 2005 23:47:58 -0400
Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id EF55443F3; Fri, 19 Aug 2005 23:10:35 -0400 (EDT)
Date: Fri, 19 Aug 2005 23:10:35 -0400
From: Shumon Huque <shuque@isc.upenn.edu>
To: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050820031035.GA5352@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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20050819210308.GI6659@binky.Central.Sun.COM>
User-Agent: Mutt/1.4.2.1i
Organization: University of Pennsylvania
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: secmech@ietf.org
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 Fri, Aug 19, 2005 at 04:03:08PM -0500, Nicolas Williams wrote:
> On Fri, Aug 19, 2005 at 02:52:22PM -0400, Charles Clancy wrote:
> > 
> > Whatever happened to EAP-GSS?
> 
> Dunno, but as I recall some of the KITTEN WG work is, in part, aimed at
> making EAP-GSS possible, specifically the GSS_Pseudo_random() extension.
> 
> > http://www.drizzle.com/~aboba/IEEE/draft-aboba-pppext-eapgss-12.txt
> > 
> > "krb5->GSS-API->EAP-GSS->EAP-TTLS->EAP" would work.  Of course, the length 
> > of that string should be a motivator for bindings over bridges.
> 
> Yes, but replace 'krb5' with 'IAKERB' or soemthing like it.
> 

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)

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

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.

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.

Kerberos has always assumed that the network is completely insecure
and the general defense against offline dictionary attack is strong
passwords. I agree that perhaps this isn't enough anymore. But then, 
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). Hardware pre-authentication
mitigates the threat somewhat. But PKINIT isn't really an option for 
the many sites that don't plan to authenticate users with public key 
credentials (or deploy PKI).

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.

---
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