Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Charles Clancy <clancy@cs.umd.edu> Wed, 17 August 2005 22:20 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5WH1-0001kk-95; Wed, 17 Aug 2005 18:20:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5WGz-0001hX-19 for secmech@megatron.ietf.org; Wed, 17 Aug 2005 18:20:37 -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 SAA07213 for <secmech@ietf.org>; Wed, 17 Aug 2005 18:20:34 -0400 (EDT)
Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5WqY-0008UV-Vx for secmech@ietf.org; Wed, 17 Aug 2005 18:57:26 -0400
Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7HMJIfD009154; Wed, 17 Aug 2005 18:19:18 -0400 (EDT)
Date: Wed, 17 Aug 2005 18:14:07 -0400 (EDT)
From: Charles Clancy <clancy@cs.umd.edu>
X-X-Sender: clancy@ismene
To: "Salowey, Joe" <jsalowey@cisco.com>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <7210B31550AC934A8637D6619739CE6905B61990@e2k-sea-xch2.sea-alpha.cisco.com>
Message-ID: <Pine.GSO.4.60.0508171418010.13012@ismene>
References: <7210B31550AC934A8637D6619739CE6905B61990@e2k-sea-xch2.sea-alpha.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
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

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.

[ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]


On Tue, 16 Aug 2005, Salowey, Joe wrote:

> At the secmch BOF Nico introduced the following two approaches towards
> achieve generally usable authentication mechanisms: Framework Binding
> and Mechanism bridges.  I'd like to see if there is understanding of the
> two approaches and a consensus on how to approach the problem.
>
> Framework Bindings - the framework bindings approach requires that when
> a mechanism is specified it is specified as a mechanism in the
> frameworks of GSS-API, SASL and EAP.  The specification would have to
> define functionality to meet a superset of all the requirements for each
> framework and then define how the mechanism integrates with (or is bound
> to) each framework.
>
> Mechanism Bridges - in the mechanism bridges approach a specialized
> mechanisms is used to map all mechanisms in one framework into another
> framework.  A example of this exists in SASL where there is a mechanism
> defined that makes available all GSS-API mechanisms available in the
> SASL framework.  It should be possible to create a bridge mechanism that
> makes GSS-API mechanisms into EAP mechanisms and vice versa at least for
> a subset of mechanisms.  The bridge mechanism itself may provide some
> functionality that is not available in a particular framework.  For
> example an EAP to GSS bridge mechanism may provide a generic security
> layer that uses the EAP master session key (MSK) to establish a security
> context and provide a security layer between the GSS initiator and GSS
> acceptor.
>
> The answer may lie somewhere between these two approaches.  Comments?
>
> Joe
>
> _______________________________________________
> SECMECH mailing list
> SECMECH@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/secmech
>

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