Subject: Re: [Emu] EMU Charter revision

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 3 Mar 2008 21:23:07 -0800

Hi Bernard,

Comments inline below: 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bernard Aboba
> Sent: Thursday, February 21, 2008 11:54 AM
> To: [email-masked]
> Subject: 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". 
> 
[Joe] In addition there is at least one more, EAP-TTLS that is in the
process.  We can revise the section of the charter.  Do you have any
suggested text?

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

[Joe] There is time set on the agenda in Philadelphia to discuss 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.  
> 

[Joe] OK, do you have some recommended text in this area.  I'm not sure
how one would write this into the charter.  I think this will need some
discussion.  

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

[Joe] This will be a topic for discussion as well.  We can see what the
level of interest is.   

> 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-eaptunn
> el-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
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 3 Mar 2008 21:41:05 -0800

I agree with Bernard on all points.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
	Sent: Friday, February 22, 2008 2:54 AM
	To: [email-masked]
	Subject: Re: [Emu] EMU Charter revision

	
methods 
	are 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
about other
members that
specifications as
	> contribute towards tunneled method development: contributor,
reviewer or
	> not able to contribute.
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