RE: [SECMECH] Method work

["Salowey, Joe" <[e-mail]>]

 

> -----Original Message-----
> From: Jari Arkko [mailto:[e-mail]] 
> Sent: Thursday, August 25, 2005 6:34 AM
> To: Salowey, Joe
> Cc: [e-mail]
> Subject: Re: [SECMECH] Method work
> 
> 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.
> 

[Joe] I agree with this and I think it can be done independent of GUAM
work pretty easily.  I would like to get channel bindings in, but I
agree this may be a little tricky. 

> >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.
> 
[Joe] If EAP-TLS with TLS-PSK could satisfy at least the short term
needs that would be great.  I think it could be possible that a PSK
mechanism could be more generally useful that just 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.
> >  
> >
> 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.
> 

[Joe] I think mechanisms of these types should be made applicable to all
frameworks. 

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

[Joe] Yes I think a good solution to 3 may mitigate the need for 4.
Currently there are uses for tunneled methods beyond legacy
authentication.  These do tend to be proprietary, but perhaps in the
future there will be opportunity for convergence. 

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

[Joe] I think it depends on your view.  It certainly seems like there is
interest in this. 

> Other: enrollment, perhaps a la what Rohan Mahy wanted to do 
> in the last EAP WG meeting.
> 
[Joe] Enrollment would be good,  I feel like that might be more than I
would want to chew off immediately.  


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