Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 19 August 2005 18:14 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6BNw-0005r1-65; Fri, 19 Aug 2005 14:14:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6BNt-0005qk-RZ for secmech@megatron.ietf.org; Fri, 19 Aug 2005 14:14:29 -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 OAA20123 for <secmech@ietf.org>; Fri, 19 Aug 2005 14:14:28 -0400 (EDT)
Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Bxt-0001hC-Tw for secmech@ietf.org; Fri, 19 Aug 2005 14:51:42 -0400
Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7JIESWR008412 for <secmech@ietf.org>; Fri, 19 Aug 2005 12:14:28 -0600 (MDT)
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 j7JIERfe027222 for <secmech@ietf.org>; Fri, 19 Aug 2005 12:14:28 -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 j7JIENAG007304; Fri, 19 Aug 2005 13:14:23 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7JIENwI007303; Fri, 19 Aug 2005 13:14:23 -0500 (CDT)
Date: Fri, 19 Aug 2005 13:14:23 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: "Salowey, Joe" <jsalowey@cisco.com>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050819181423.GA6658@binky.Central.Sun.COM>
References: <7210B31550AC934A8637D6619739CE6905C06505@e2k-sea-xch2.sea-alpha.cisco.com> <20050819181222.GG6659@binky.Central.Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050819181222.GG6659@binky.Central.Sun.COM>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
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 01:12:22PM -0500, Nicolas Williams wrote:
> On Fri, Aug 19, 2005 at 10:25:24AM -0700, Salowey, Joe wrote:
> > > From: Charles Clancy [mailto:clancy@cs.umd.edu] 
> > > 
> > > 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.
> > > 
> > [Joe] I tend to agree, however I think that bridge mechanisms or
> > something similar can be useful tools for pulling things together.  One
> > example is a "generic" security layer that could use EAP keying
> > material.  Another may be a GSS-API mehcnaism that can make use of EAP
> > methods to address some of the concerns Pasi had raised with respect to
> > AAA integration. 
> 
> I too tend to agree.  Bridges are clearly feasible, as SASL support for
> GSS-API mechanisms demonstrates.  But bridges between EAP and any
> client-initiated frameworks will generally cost a round-trip, so for EAP
> vs. pretty much any other security framework it will be more appealing
> to develop framework bindings of one framework's mechanisms to the
> other.

I forgot to mention the counter-argument, namely that, in the short-term
at least, a round-trip is a small price to pay for lowering the cost, in
time and effort, of making EAP's or SASL/GSS-API's mechanisms available
to the other.

Nico
-- 

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