Subject: Re: [Emu] EMU charter revision,

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Apr 2008 12:50:01 -0700

In re-reading this charter, I still don't think we're quite there:
 
a.  Why is there still a charter item for EAP-TLS?  This work hasbeen completed, no? 
 
b. Attempting to extend EAP-TLS to support tunneling or channel bindings 
is not appropriate. EAP-TLS already widely deployed, with large investments 
in conformance tests.  Given the number of existing TLS-based tunneling protocols, such a work item would serve no useful purpose.  Let's focus on adding
channel binding support to tunnel methods. 
 
c. To some extent, I agree with Dan and Yoav with respect to the need for password-based methods.  Had such methods been availableearlier, it's questionable whether TLS tunneling would have takenoff to the extent that it has.  Also, I think that such methods, if specified
in the IETF, would be likely to be widely deployed.  However, on the other
hand I think that this is really an issue for the entire security area, not
just for EMU.  So I'd suggest that this issue be brought up in SAAG. 
 
=====================================================================Below is a revision to the EMU charter that is intended to reflect thediscussions in the Philadelphia meeting.  Please respond to the list ifyou approve of the charter or if you have any comments on the charter.I would like to have responses by 4/24.
 
Thanks,
Joe

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 30 Apr 2008 10:32:41 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bernard Aboba
> Sent: Tuesday, April 29, 2008 12:50 PM
> To: [email-masked]
> Subject: Re: [Emu] EMU charter revision,
> 
> a.  Why is there still a charter item for EAP-TLS?  This work 
> has been completed, no? 
>  
[Joe] Yes it has. I originally argued to keep it in the charter for
historical reasons, but now it seems to make more sense to remove it. 

> b. Attempting to extend EAP-TLS to support tunneling or 
> channel bindings is not appropriate. EAP-TLS already widely 
> deployed, with large investments in conformance tests.  Given 
> the number of existing TLS-based tunneling protocols, such a 
> work item would serve no useful purpose.  Let's focus on 
> adding channel binding support to tunnel methods. 
>
[Joe] Jari had asked to keep this open to TLS.  I think he was
suggesting it could be done as a TLS extension and would not require
tunneling.  I agree that we do not want to extend EAP-TLS to do
tunneling. 

How about:

"- Enable a TLS-based EAP method to support channel bindings. This item
will not generate a new method, rather it will focus on supporting EAP 
channel bindings within the tunnel method.  The possiblity of adding
channel bindings to EAP-TLS through a TLS extension or other standard
TLS mechanism may also be investigated. " 
  
> c. To some extent, I agree with Dan and Yoav with respect to 
> the need for password-based methods.  Had such methods been 
> available earlier, it's questionable whether TLS tunneling 
> would have taken off to the extent that it has.  Also, I 
> think that such methods, if specified in the IETF, would be 
> likely to be widely deployed.  However, on the other hand I 
> think that this is really an issue for the entire security 
> area, not just for EMU.  So I'd suggest that this issue be 
> brought up in SAAG. 
>  
[Joe] I agree.  

> =====================================================================
> Below is a revision to the EMU charter that is intended to 
> reflect the discussions in the Philadelphia meeting.  Please 
> respond to the list if you approve of the charter or if you 
> have any comments on the charter.
> I would like to have responses by 4/24.
>  
> Thanks,
> Joe
>  
>  
> 
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 30 Apr 2008 16:53:47 -0700

How about:

[BA] I think we only want one mechanism for support of channel bindings
in TLS-based methods.  So it's ok to investigate a TLS extension vs.
other mechanisms for supporting channel bindings, but I'd suggest we
only want to choose one path.  So my suggestion would be to modify
the text as follows:

- Enable a TLS-based EAP method to support channel bindings.  This item
will not generate a new method, rather it will focus on adding support for
EAP channel bindings.  Potential mechanisms for addition of support for
channel bindings will be investigated, including tunneling of channel
binding parameters, or a TLS extension or other standard TLS mechanism."

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 30 Apr 2008 17:57:17 -0700

I was offline when I sent the charter update. I'm not sure there has to
be only one mechanism, but I think it would be a desirable outcome.  I
like your text and will include it. 

Thanks,

Joe 

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, April 30, 2008 4:54 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Emu] EMU charter revision,
> 
> [Joe] Jari had asked to keep this open to TLS.  I think he 
> was suggesting it could be done as a TLS extension and would 
> not require tunneling.  I agree that we do not want to extend 
> EAP-TLS to do tunneling. 
> 
> How about:
> 
> "- Enable a TLS-based EAP method to support channel bindings. 
> This item will not generate a new method, rather it will 
> focus on supporting EAP channel bindings within the tunnel 
> method.  The possiblity of adding channel bindings to EAP-TLS 
> through a TLS extension or other standard TLS mechanism may 
> also be investigated. " 
> 
> [BA] I think we only want one mechanism for support of 
> channel bindings in TLS-based methods.  So it's ok to 
> investigate a TLS extension vs.
> other mechanisms for supporting channel bindings, but I'd 
> suggest we only want to choose one path.  So my suggestion 
> would be to modify the text as follows:
> 
> - Enable a TLS-based EAP method to support channel bindings.  
> This item will not generate a new method, rather it will 
> focus on adding support for EAP channel bindings.  Potential 
> mechanisms for addition of support for channel bindings will 
> be investigated, including tunneling of channel

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 30 Apr 2008 21:33:45 -0400

I like Bernard's text better. 

> Sent: Wednesday, April 30, 2008 7:54 PM