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.