Re: [Emu] EMU Charter revision
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emu] EMU Charter revision



Hi Dan,

you are asking me which EAP methods support weak passwords?

If so, here are a few examples:
* TTLS
* PEAP
* EAP-PAX
* EAP-FAST
* EAP-IKEv2

Please note that I am not against doing the work; I would just like to 
understand what the main motivation is.

Ciao
Hannes

Dan Harkins wrote:
>   Hi Hannes,
>
>   What are these methods? And is their security completely based
> on an assumption that the one deploying this method is following
> some strict regime (e.g. no weak passwords)?
>
>   regards,
>
>   Dan.
>
> On Fri, February 22, 2008 6:34 am, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>   
>> Hi Bernard,
>>
>> a question your excitment regarding strong password based EAP method.
>>
>> Why do you think they are useful? There are other ways (and they are
>> deployed already) that can accomplish the same result without going
>> along the SRP & co track.
>> Is it because you expect performance improvements or because the
>> crypto-mechanisms look nicer?
>>
>> I cannot quite understand the motivation.
>>
>> Ciao
>> Hannes
>>
>> ________________________________
>>
>> 	Von: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] Im
>> Auftrag von ext Bernard Aboba
>> 	Gesendet: Donnerstag, 21. Februar 2008 21:54
>> 	An: emu at ietf.org
>> 	Betreff: Re: [Emu] EMU Charter revision
>>
>>
>> 	I also do NOT approve of the current charter revision, for
>> several reasons:
>>
>> 	a.  The Charter text contains statements that are no longer
>> true.  For example:
>>
>> 	"Most of these methods are proprietary methods and only a few
>> methods
>> 	are documented in RFCs."
>>
>> 	The following EAP methods are now documented in RFCs:
>>
>> 	EAP-TLS (RFC 2716)
>> 	EAP-SIM (RFC 4186)
>> 	EAP-AKA (RFC 4187)
>> 	EAP-PAX (RFC 4746)
>> 	EAP-SAKE (RFC 4763)
>> 	EAP-PSK (RFC 4764)
>> 	EAP-POTP (RFC 4793)
>> 	EAP-FAST (RFC 4851)
>> 	EAP-IKEv2 (RFC 5106)
>>
>>     

	

>> 	9 methods claiming to satify RFC 4017 critieria is more than a
>> "few".
>>
>> 	b. The Charter requires support for Channel Bindings without
>> doing the
>> 	preparatory work to define how Channel Bindings works.  Either
>> the
>> 	requirement should be removed, or a work item should be added to
>>
>> 	better define the approach to Channel Bindings.
>>
>> 	c. The text on tunnel methods does not provide enough guidance
>> to avoid
>> 	potentially fruitless arguments.  So far, the EMU WG has not
>> been able
>> 	to come to consensus on selection of one of the existing
>> tunneling
>> 	protocols, and efforts to design "yet another" tunneling
>> protocol
>> 	haven't gotten very far either.  I'd like to see more specific
>> 	language that would make it clear that work on improving
>> existing
>> 	tunneling protocols is within scope, and also that the EMU WG,
>> 	if it cannot come to consensus on a single protocol, can proceed
>> to
>> 	work on one or more protocols with significant support.
>>
>> 	d. Password-based methods.  While I can understand the desire to
>> limit the
>> 	number of charter items, I do agree with Dan that work on
>> weak-password
>> 	methods is important.  With some of the IPR obstacles likely to
>> fall by
>> 	the wayside in coming years, it is time for the IETF to re-visit
>> its policy
>> 	on inclusion of "zero knowledge" algorithms within standards
>> track documents.
>> 	Dan Harkins said:
>>
>> 	" Hi Joe,
>>
>>
>> 	  I do NOT approve of the current charter revision, specifically
>> the
>> 	change that says the password-based method can only be via the
>> 	tunneled method. I do approve of the inclusion of tunneled
>> methods
>> 	in the charter though and would be willing to contribute as a
>> 	reviewer.
>>
>> 	  regards,
>>
>> 	  Dan."
>> 	On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey)
>> wrote:
>> 	> The response to the charter revision has been underwhelming.
>> I am a bit
>> 	> concerned that we do not have enough participation to complete
>> the
>> 	> tunnel method work (most of the recent discussion has been
>> about other
>> 	> methods).
>> 	>
>> 	> I would like to get an idea of the number working group
>> members that
>> 	> approve of working on the tunnel method items and are able to
>> 	> participate in the development of requirements and
>> specifications as
>> 	> contributors and/or reviewers.
>> 	>
>> 	> Please respond to this message and state whether you approve
>> of the
>> 	> current charter revision and what capacity you would be
>> willing to
>> 	> contribute towards tunneled method development: contributor,
>> reviewer or
>> 	> not able to contribute.
>> 	>
>> 	> I have submitted an internet draft attempt at an outline of
>> requirements
>> 	> for tunneled methods
>> 	>
>> (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00.
>> 	> txt) that I hope can provided a starting point for discussions
>> on the
>> 	> list and in the Philadelphia meeting.
>> 	>
>> 	> Thanks,
>> 	>
>> 	> Joe
>>
>>
>> _______________________________________________
>> Emu mailing list
>> Emu at ietf.org
>> http://www.ietf.org/mailman/listinfo/emu
>>
>>     
>
>
> _______________________________________________
> Emu mailing list
> Emu at ietf.org
> http://www.ietf.org/mailman/listinfo/emu
>   

_______________________________________________
Emu mailing list
Emu at ietf.org
http://www.ietf.org/mailman/listinfo/emu



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.