Subject: AW: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

From: [email-masked]
Date: Mon, 22 Aug 2005 13:08:09 +0200

>
>On Sat, Aug 20, 2005 at 12:58:41AM -0500, Nicolas Williams wrote:
>> On Fri, Aug 19, 2005 at 11:10:35PM -0400, Shumon Huque wrote:
>> > I think the Kerberos community needs to work on standardizing password 
>> > based pre-authentication mechanisms invulnerable to dictionary attack 
>> > (perhaps EKE, AEKE, SPEKE, SRP etc). Hardware pre-authentication
>> > mitigates the threat somewhat. But PKINIT isn't really an option for 
>> > the many sites that don't plan to authenticate users with public key 
>> > credentials (or deploy PKI).
>> 
>> Did you attend the SACRED WG meeting at IETF 63?
>
>No, but I just read a summary of their session. The credential
>mobility stuff isn't really relevant to (non PKINIT) Kerberos
>sites. So I assume you are referring to the IPR issues with those
>protocols. It sounds like there might be some hope though!
>
>> > At one time, some of us were talking about an EAP method that
>> > transported Kerberos messages directly. It seems to me that putting
>> > some effort into completing that work would be immediately useful
>> > to Kerberos sites that need to deploy 802.1X or 802.11i soon.
>> 
>> Indeed.  That would be an example of framework bindings of a security
>> mechanisms, as opposed to EAP-GSS, which would be a bridge.
>
>Agreed.
>
>Some folks at Penn are interested in working on an EAP-Kerberos 
>method. Is there anyone else interested in this?

Hi Shumon, 

I`ve also thought about a new EAP method which makes use of Kerberos.
When designing a new EAP method, it must extend current available set
of EAP methods by a new mechanism.

Some weeks ago, I`ve asked publicly in the Kerberos Mailing List what
the folks expect from a EAP-Kerberos method. See http://mailman.mit.edu/pipermail/kerberos/2005-July/008131.html
Some opinions can be found there.

There already exists a Kerberos extension to TLS, RFC 2712 (Oct.99),
which can be run in EAP-TLS, so the question is: 

* Is there need for EAP-Kerberos at all? * 

So before all, we should investigate in how far EAP-Kerberos improves
the TLS-based solution. 

For instance, the mandatory resistance to dictionary attacks. Thomas Wu
has given in his Kerberos paper a hint how to mitigate this, however,
even if there is a strong-password protocol without IPR claims,
strong password methods suffer in general from heavy computation and thus
the EAP method would have worse performance.

Any comments are welcome
Thomas

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

---

From: Shumon Huque <[email-masked]>
Date: Mon, 22 Aug 2005 07:41:12 -0400

> * Is there need for EAP-Kerberos at all? * 

RFC 2712 doesn't provide for initial and service ticket 
acquisition. So, at the very least an EAP method that
allows you to do that needs to be developed.

> the EAP method would have worse performance.

That's true. But as long as performance is good enough, it
might be okay. It's probably certainly an issue for handheld
devices needing to use it.

--Shumon.

---

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

>allows you to do that needs to be developed.
Do you need a fix to EAP, or do you a fix to kerberos-in-TLS?
The latter might be applicable in a number of other scenarios,
too...

--Jari

---

From: Shumon Huque <[email-masked]>
Date: Thu, 25 Aug 2005 11:26:09 -0400

> The latter might be applicable in a number of other scenarios,

Most application protocols that support Kerberos authentication 
today assume that ticket acquisition is performed out of band.
The Kerberos ciphersuite specification for TLS takes the same
architectural approach. Although, I realize that TLS itself isn't
an application, but a framework. Hence perhaps it should support 
a way to do ticket acquisition. Any thoughts?

With EAP for network access authentication, the ticket acquisition
step itself needs to be supported via an EAP method. I don't have 
any strong opinions about whether there should be a separate ticket 
acquistion method, or whether it should be part of an integrated 
Kerberos method that does ticket acquisition and authentication. 
But the latter seems simpler.

One other possibility is for TLS to support GSS-API and then
an IAKERB GSS-API mechnism could provide ticket acquisition
support. I think Nico may have mentioned this already. Again,
this requires updated versions of both those protocols (in
addition to TLS) to be usable in EAP, and hence we could be 
waiting a while :-)

--Shumon.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 25 Aug 2005 10:53:00 -0500

> The latter might be applicable in a number of other scenarios,

Fixing RFC2712 so it actually works with Kerberos V extensions (by not
unnecessarily making up its own Authenticator and AP exchange messages)
is eminently doable.

Fixing RFC2712 to provide IAKERB-like features is another story -- TLS
has a fixed number of round-trips!  (If you'll remember, I mentioned the
possibility for "GSS ciphersuites for TLS" at the BoF and mentioned this
problem as something that would have to be fixed in TLS).

Nico
--

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Aug 2005 19:05:46 +0300

>problem as something that would have to be fixed in TLS).
Ok. I'm starting to remember this now...

--Jari