Subject: [SECMECH] Method work

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 22 Aug 2005 17:54:45 -0700

I would like to identify which mechanism types there is interest in
working on.  Below is a list of various authentication methods that
people have expressed interest in having support for in EAP and other
frameworks.    It may not be the case that we need a separate mechanism
for each of these.  I'd like to know who has interest in contributing
and reviewing (please indicate either or both) specifications for each
of these mechanism types.  

1. X.509 Certificate credentials - (possible revision of EAP-TLS
(RFC2716)) - applicable to EAP, possibly applicable to GSS and SASL.
Desired by IEEE 802.11 for EAP.

2. Shared Secret - pre-shared secret method.  Applicable to EAP and GSS,
possibly SASL. Desired by IEEE 802.11 for EAP.  

3. Password based -  essentially a shared secret mechanism that provides
resistance to dictionary attacks. It should support various backend
databases of password that use different storage techniques and perhaps
support for one time tokens as well.  Could use something related to EKE
or a tunneling approach.  Applicable to EAP, GSS, and SASL. Desired by
IEEE 802.11 for EAP. 

4. Tunneling - a tunneling method is useful to protect weaker
authentication mechanisms.  Tunneling methods are also used to exchange
other types of authentication data.  Applicability EAP and GSS possibly
SASL. 

5. Kerberos - Something that provide for initial authentication and a
strategy for resisting dictionary attacks.  Applicable to EAP, possibly
GSS. 

Thanks,

Joe

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

---

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

>Desired by IEEE 802.11 for EAP.
I think we should rev EAP-TLS at the minimum, just to
make a PS out of it and fix some bugs & provide additional
information where necessary.

We probably need to resist the urge to add a lot of
stuff to EAP-TLS in such a revision. Though I'm kind of
interested in adding channel bindings. But I'm not
sure if that's doable in a backwards compatible way,
without either a major change in EAP-TLS or an
extension in TLS.

>possibly SASL. Desired by IEEE 802.11 for EAP.  
Yes, this is perhaps my top priority item. My current thinking
of what we need here is a simple-to-implement method that
is really shared secret, not password based, and something
that would provide a reasonable candidate for people
to implement in their products and reference as a mandatory-to-
implement for some link layer.

One question is what the value of EAP-TLS + TLS PSK would
be in this context. To me this would satisfy the implementation
simplicity requirement; most products should be able to take
TLS in rather easily. However, there are also other reasons
for developing new EAP methods (channel bindings is one
reason), so we'd have to look at how to arrange for those
other reasons.

>or a tunneling approach.  Applicable to EAP, GSS, and SASL. Desired by
This would also be very useful. Personally I'm a bit more
on thin ice here when it comes to the specific methods and
whether there are any potential IPR issues etc. But I know
this would be very much needed from a customer perspective.

>other types of authentication data.  Applicability EAP and GSS possibly
This is perhaps the widest class of currently used EAP methods,
all proprietary and/or exist only in drafty draft state.

One issue here is whether we'd be able to find consensus, or
would the folks who have their own tunnel methods be fighting
for "their" approach?

Another issue is to what extent having a good solution for
#3 would lessen the need for #4.

>strategy for resisting dictionary attacks.  Applicable to EAP, possibly
I don't currently see a big customer demand for this. But
I could be viewing at the wrong "market segment".

Other: enrollment, perhaps a la what Rohan Mahy wanted
to do in the last EAP WG meeting.

--Jari

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 26 Aug 2005 00:08:58 -0500

> I could be viewing at the wrong "market segment".

It seems to me that that organizations with large Kerberos V deployments
should find it useful to be able to use Kerberos V for user
authentication in EAP applications (wifi, VPN, say).

Or do/would organizations with large Kerberos V deployments find this
feature unappealing for some reason that escapes me?  Perhaps because
they might want EAP to authenticate a device more than a user?  Or
perhaps because they want hardware tokens?  But nothing [technically]
stops one from using hw tokens to store high-quality long-term Kerberos
V secret keys, and then there's PKINIT.

Or maybe such organizations are good at user enrollment wherever they
can't use Kerberos and so don't have a strong need for it in EAP
applications -- they might like it, but they get by without it.

But anyways, a GUAM IAKERB mechanism with GSS-API and EAP framework
bindings would definitely be useful in GSS contexts; so if we undertake
GUAM then the matter of whether EAP-IAKERB is useful seems less relevant
(unless it turns out that a GSS IAKERB mechanism is significantly
without GUAM and EAP in the picture).

> to do in the last EAP WG meeting.

Enrollment seems like it would be useful in network access technologies.

But for business reasons enrollment needs to be very, er, free form,
involving HTML and friends.

Nico
--