 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
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 has been 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 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. ===================================================================== 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 |
_______________________________________________ Emu mailing list Emu at ietf.org https://www.ietf.org/mailman/listinfo/emu