AW: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
t.otto@sharevolution.de Mon, 22 August 2005 11:08 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1E7AA9-0001RE-VF; Mon, 22 Aug 2005 07:08:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1E7AA9-0001R9-50
for secmech@megatron.ietf.org; Mon, 22 Aug 2005 07:08:21 -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 HAA06777
for <secmech@ietf.org>; Mon, 22 Aug 2005 07:08:17 -0400 (EDT)
From: t.otto@sharevolution.de
Received: from moutng.kundenserver.de ([212.227.126.176])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Akf-0004hp-Bw
for secmech@ietf.org; Mon, 22 Aug 2005 07:46:07 -0400
Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de)
by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
id 1E7A9x-000734-00; Mon, 22 Aug 2005 13:08:09 +0200
Received: from [172.23.4.154] (helo=pustefix154.kundenserver.de)
by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1)
id 1E7A9x-0003gt-00; Mon, 22 Aug 2005 13:08:09 +0200
Message-Id: <5057734.1124708889160.JavaMail.servlet@kundenserver>
To: <shuque@isc.upenn.edu>
Subject: AW: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Binford: 6100 (more power)
X-Mailer: Webmail
X-Originating-From: 6270027
X-Routing: DE
X-Message-Id: <6270027$1124708889160172.23.4.15416082936@pustefix154.kundenserver.de--1224873406>
X-Received: from pustefix154.kundenserver.de by 192.35.17.24 with HTTP id
6270027 for [shuque@isc.upenn.edu]; Mon, 22 Aug 2005 13:08:09 CEST
Date: Mon, 22 Aug 2005 13:08:09 +0200
X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.4.154
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
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 Sat, Aug 20, 2005 at 12:58:41AM -0500, Nicolas Williams wrote: >> On Fri, Aug 19, 2005 at 11:10:35PM -0400, Shumon Huque wrote: >> > 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). >> >> Did you attend the SACRED WG meeting at IETF 63? > >No, but I just read a summary of their session. The credential >mobility stuff isn't really relevant to (non PKINIT) Kerberos >sites. So I assume you are referring to the IPR issues with those >protocols. It sounds like there might be some hope though! > >> > 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. >> >> Indeed. That would be an example of framework bindings of a security >> mechanisms, as opposed to EAP-GSS, which would be a bridge. > >Agreed. > >Some folks at Penn are interested in working on an EAP-Kerberos >method. Is there anyone else interested in this? Hi Shumon, I`ve also thought about a new EAP method which makes use of Kerberos. When designing a new EAP method, it must extend current available set of EAP methods by a new mechanism. Some weeks ago, I`ve asked publicly in the Kerberos Mailing List what the folks expect from a EAP-Kerberos method. See http://mailman.mit.edu/pipermail/kerberos/2005-July/008131.html Some opinions can be found there. There already exists a Kerberos extension to TLS, RFC 2712 (Oct.99), which can be run in EAP-TLS, so the question is: * Is there need for EAP-Kerberos at all? * So before all, we should investigate in how far EAP-Kerberos improves the TLS-based solution. For instance, the mandatory resistance to dictionary attacks. Thomas Wu has given in his Kerberos paper a hint how to mitigate this, however, even if there is a strong-password protocol without IPR claims, strong password methods suffer in general from heavy computation and thus the EAP method would have worse performance. Any comments are welcome Thomas _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech
- AW: Re: [SECMECH] Framework Bindings Vs. Mechanis… t.otto
- Re: Re: [SECMECH] Framework Bindings Vs. Mechanis… Shumon Huque
- AW: Re: [SECMECH] Framework Bindings Vs. Mechanis… t.otto
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Jari Arkko
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Shumon Huque
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Jari Arkko