Alan DeKok [mailto:[email protected]] writes:
> Glen Zorn wrote: > >> A technical review of EAP-FAST as it applies to the charter work > >> items > >> is relevant. > > > > Thanks for the clarification. However, it's hard for me to > understand how > > the architectural choices of EAP-FAST could be irrelevant to the > charter > > work items. > > They are not irrelevant. See below. > > >> This WG is also a reasonable place to discuss the status > >> of the current EAP-FAST document. However, re-designing EAP-FAST is > >> not > >> on the charter of this WG. > > > > OK, great. Just out of curiosity, though, would you mind explaining > the > > criteria upon which these policies are based since EAP-FAST is not > > specifically mentioned anywhere in the charter? > > The charter requires us to extend an existing TLS-based tunneled > method. I can't see that in the charter. This is what it says (in part): - Enable TLS-based EAP methods to support channel bindings. This item will not generate a new method; rather, it will focus on adding support for EAP channel bindings to the tunneled method (described below), and if possible, other TLS-based EAP methods. Potential mechanisms for adding channel binding support will be investigated, including tunneling of channel binding parameters, or a TLS extension, or other standard TLS mechanism - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. It will also support channel bindings (as described above) in order to meet RFC 4962 requirements. Note that while it does say that the enabling of support for channel bindings will not generate a new method it says nothing of the sort about the tunneled method itself, > Hence the tunneled requirements draft. > > Both EAP-TTLS and EAP-FAST have been proposed as choices for the > tunneled method. Although their promoters have (apparently quite effectively ;-) positioned the question as a choice between EAP-TTLS & EAP-FAST, I can find nothing in the charter that actually requires us to take that path. > One or the other may have particular architectural > choices that prevents it from satisfying the tunneled requirements. In > that case, those architectural choices would be relevant. > > Architectural choices that are "unusual", but which also do not > impact > the methods ability to satisfy the tunnel requirements are out of scope > of the charter. They can be discussed here with respect to the EAP- > FAST > documents && the current IESG review, but they should have no impact on > the choice of tunneled method. > > Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
