Re: [SECMECH] Method work

[Jari Arkko <[e-mail]>]

Salowey, Joe wrote:

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

>2. Shared Secret - pre-shared secret method.  Applicable to EAP and GSS,
>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.

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

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

>5. Kerberos - Something that provide for initial authentication and a
>strategy for resisting dictionary attacks.  Applicable to EAP, possibly
>GSS. 
>  
>
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

>Thanks,
>
>Joe
>
>_______________________________________________
>SECMECH mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/secmech
>
>
>  
>


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