Subject: [SECMECH] Framework Bindings Vs. Mechanism Bridges

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 16 Aug 2005 15:50:39 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/secmech

---

From: Charles Clancy <[email-masked]>
Date: Wed, 17 Aug 2005 18:14:07 -0400 (EDT)

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 ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Aug 2005 17:27:32 -0500

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