Re: [SECMECH] Method work

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 26 August 2005 05:09 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8WSh-0002vb-MP; Fri, 26 Aug 2005 01:09:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8WSf-0002vU-HQ for secmech@megatron.ietf.org; Fri, 26 Aug 2005 01:09:05 -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 BAA13951 for <secmech@ietf.org>; Fri, 26 Aug 2005 01:09:04 -0400 (EDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8WTJ-00087R-9w for secmech@ietf.org; Fri, 26 Aug 2005 01:09:47 -0400
Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7Q5912B010927 for <secmech@ietf.org>; Thu, 25 Aug 2005 22:09:01 -0700 (PDT)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7Q590fc016041 for <secmech@ietf.org>; Thu, 25 Aug 2005 23:09:01 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7Q590ca017265; Fri, 26 Aug 2005 00:09:00 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7Q58whV017264; Fri, 26 Aug 2005 00:08:58 -0500 (CDT)
Date: Fri, 26 Aug 2005 00:08:58 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [SECMECH] Method work
Message-ID: <20050826050857.GJ15718@binky.Central.Sun.COM>
References: <7210B31550AC934A8637D6619739CE6905C06A6B@e2k-sea-xch2.sea-alpha.cisco.com> <430DC8B3.9010309@piuha.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <430DC8B3.9010309@piuha.net>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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 Thu, Aug 25, 2005 at 04:33:39PM +0300, Jari Arkko wrote:
> Salowey, Joe wrote:
> >5. Kerberos - Something that provide for initial authentication and a
> >strategy for resisting dictionary attacks.  Applicable to EAP, possibly
> >GSS. 
> > 
> >
> I don't currently see a big customer demand for this. But
> I could be viewing at the wrong "market segment".

It seems to me that that organizations with large Kerberos V deployments
should find it useful to be able to use Kerberos V for user
authentication in EAP applications (wifi, VPN, say).

Or do/would organizations with large Kerberos V deployments find this
feature unappealing for some reason that escapes me?  Perhaps because
they might want EAP to authenticate a device more than a user?  Or
perhaps because they want hardware tokens?  But nothing [technically]
stops one from using hw tokens to store high-quality long-term Kerberos
V secret keys, and then there's PKINIT.

Or maybe such organizations are good at user enrollment wherever they
can't use Kerberos and so don't have a strong need for it in EAP
applications -- they might like it, but they get by without it.

But anyways, a GUAM IAKERB mechanism with GSS-API and EAP framework
bindings would definitely be useful in GSS contexts; so if we undertake
GUAM then the matter of whether EAP-IAKERB is useful seems less relevant
(unless it turns out that a GSS IAKERB mechanism is significantly
without GUAM and EAP in the picture).

> Other: enrollment, perhaps a la what Rohan Mahy wanted
> to do in the last EAP WG meeting.

Enrollment seems like it would be useful in network access technologies.

But for business reasons enrollment needs to be very, er, free form,
involving HTML and friends.

Nico
-- 

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