Yoshi, I disagree. I think channel binding can and should be be provided by EAP methods.
An approach that can be used to add channel binding to any EAP method that supports mutual authentication and key establishment is outlined in: http://tools.ietf.org/id/draft-clancy-emu-aaapay-00.txt and http://tools.ietf.org/id/draft-clancy-emu-chbind-00.txt Yes, some additional system requirements that must be ensured outside of EAP seem to be necessary. But I believe that would be always the case, no matter would protocol you would use to provide channel binding. The drafts will be presented at the meeting in Philadelphia. Katrin On Sun, Feb 24, 2008 at 3:23 PM, Yoshihiro Ohba <[EMAIL PROTECTED]> wrote: > I have an opinion about Channel Binding. Based on discussion to > create RFC 4962 and draft-ietf-hokey-key-mgt, I came to believe that > EAP method is not the right tool to solve the Channel Binding problem > even if RFC 3748 has Channel Binding in its list of security claims on > EAP method. This is because EAP methods are based on two-party > keying, while the Channel Binding problem essentially came from > separation of EAP authenticator and EAP server. I think Channel > Binding is best solved using a three-party key distribution protocol > e.g., by re-designing EAP to be a 3-party protocol, but that is not > what EMU WG is supposed to do, either. > > Said that I suggest removing Channel Binding support from the EMU > charter. > > Yoshihiro Ohba > > > On Thu, Feb 21, 2008 at 11:54:06AM -0800, Bernard Aboba wrote: > > > > 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@ietf.org > > http://www.ietf.org/mailman/listinfo/emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > http://www.ietf.org/mailman/listinfo/emu > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
