[SECMECH] Framework Bindings Vs. Mechanism Bridges

"Salowey, Joe" <jsalowey@cisco.com> Tue, 16 August 2005 22:46 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AC9-0008Vq-SX; Tue, 16 Aug 2005 18:46:09 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AC8-0008V3-Cu for secmech@megatron.ietf.org; Tue, 16 Aug 2005 18:46:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17960 for <secmech@ietf.org>; Tue, 16 Aug 2005 18:46:03 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5AlV-00016Q-HY for secmech@ietf.org; Tue, 16 Aug 2005 19:22:42 -0400
Received: from sj-core-2.cisco.com ( by sj-iport-5.cisco.com with ESMTP; 16 Aug 2005 15:45:55 -0700
X-IronPort-AV: i="3.96,114,1122879600"; d="scan'208"; a="205266882:sNHT29828880"
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com []) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7GMjoQM009585 for <secmech@ietf.org>; Tue, 16 Aug 2005 15:45:51 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Aug 2005 15:50:39 -0700
Message-ID: <7210B31550AC934A8637D6619739CE6905B61990@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: Framework Bindings Vs. Mechanism Bridges
Thread-Index: AcWitEDgIeymX/peSBuJ+XPDMXNMBQ==
From: "Salowey, Joe" <jsalowey@cisco.com>
To: <secmech@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: quoted-printable
Subject: [SECMECH] Framework Bindings Vs. Mechanism Bridges
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

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

The answer may lie somewhere between these two approaches.  Comments? 


SECMECH mailing list