Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 19 Aug 2005 10:25:24 -0700

> From: Charles Clancy [mailto:[email-masked]] 
> 
> 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. 

_______________________________________________
SECMECH mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/secmech

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Aug 2005 13:12:22 -0500

> methods to address some of the concerns Pasi had raised with respect to

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.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Aug 2005 13:14:23 -0500

> to develop framework bindings of one framework's mechanisms to the

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Aug 2005 16:53:25 +0300

>time and effort, of making EAP's or SASL/GSS-API's mechanisms available
Roundtrips are important, but I don't think anyone expects
everything to happen in the minimum number of round
trips, in ALL cases. That is, I think we need e.g. shared secret
mechanisms with a small number of roundtrips in EAP, and
we need some mechanisms that have a small number of
roundtrips. But we already have today TLS-based EAP
tunneling schemes, some of which are quite chatty.
So I think it would be fine to have some additional
roundtrips when you using something from another
framework.

(Nevertheless, I'm in favor of the bindings approach.)

--Jari