AW: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges Mon, 22 August 2005 11:08 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E7AA9-0001RE-VF; Mon, 22 Aug 2005 07:08:21 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E7AA9-0001R9-50 for; Mon, 22 Aug 2005 07:08:21 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id HAA06777 for <>; Mon, 22 Aug 2005 07:08:17 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1E7Akf-0004hp-Bw for; Mon, 22 Aug 2005 07:46:07 -0400
Received: from [] ( by with esmtp (Exim 3.35 #1) id 1E7A9x-000734-00; Mon, 22 Aug 2005 13:08:09 +0200
Received: from [] ( by 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: <>
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$>
X-Received: from by with HTTP id 6270027 for []; Mon, 22 Aug 2005 13:08:09 CEST
Date: Mon, 22 Aug 2005 13:08:09 +0200
X-Provags-ID: ident:@
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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

SECMECH mailing list