IETF Logo Mail Archive

Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 17 August 2005 22:27 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5WNx-00035l-Ho; Wed, 17 Aug 2005 18:27:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5WNu-00035M-FR for secmech@megatron.ietf.org; Wed, 17 Aug 2005 18:27:46 -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 SAA08011 for <secmech@ietf.org>; Wed, 17 Aug 2005 18:27:41 -0400 (EDT)
Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5WxT-0000Il-6D for secmech@ietf.org; Wed, 17 Aug 2005 19:04:33 -0400
Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7HMReTW023914 for <secmech@ietf.org>; Wed, 17 Aug 2005 16:27:40 -0600 (MDT)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7HMRdLI013620 for <secmech@ietf.org>; Wed, 17 Aug 2005 16:27:40 -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 j7HMRXjW001868; Wed, 17 Aug 2005 17:27:33 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7HMRW54001867; Wed, 17 Aug 2005 17:27:32 -0500 (CDT)
Date: Wed, 17 Aug 2005 17:27:32 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Charles Clancy <clancy@cs.umd.edu>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050817222731.GN29416@binky.Central.Sun.COM>
References: <7210B31550AC934A8637D6619739CE6905B61990@e2k-sea-xch2.sea-alpha.cisco.com> <Pine.GSO.4.60.0508171418010.13012@ismene>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.60.0508171418010.13012@ismene>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
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 Wed, Aug 17, 2005 at 06:14:07PM -0400, Charles Clancy wrote:
> Mechanism Bridges sounds like a hack to me.
> 
> IMHO, Framework Bindings sounds like the way to go.  It gives you more 
> control over which mechanisms are used in which frameworks.  Each 
> framework has a different threat model, and not all mechanisms from one 
> framework may be good in another.  For example, using basic krb5 in 
> 802.11i-EAP is a bad idea because of dictionary attacks.

Sure, but you could always do krb5-over-TLS-with-cryptographic-bindings.

In any case, the addition of a round-trip in the case of any EAP->* or
*->EAP bridges is a serious problem in itself...

Nico
-- 

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

v2.23.0 | Report a Bug | By Email