Hi, Before this discussion escalades any further, I would like to summarize the open issue(s) that need to be addressed to move the channel binding draft forward.
Channel binding is a work group item because there was a group consensus that the lying NAS and lying provider problem are real threats that need to be addressed. In other words, we decided that EAP needs to provide means to find out whether an authenticator (or intermediary entity) is sending false information to the peer and/or the EAP server. There is no need to further discuss the above, since we achieved group consensus on this a long time ago. draft-ietf-emu-chbind-03 (http://tools.ietf.org/html/draft-ietf-emu-chbind-03) was accepted as a WG item and addresses the above problem. Here's the open issue (as I see it from previous posts to the list): The draft also introduces an additional feature that can be achieved using channel bindings, namely checking whether an authenticator is authorized to provide the requested services. This feature was added at some time, because Bernard pointed out that it could be provided at not much extra cost. Channel binding itself already requires an integrity-protected exchange of data as well as a local database (only additional DB entries would be needed and the exchange of data that is relevant to authorization (and not to channel bindings)). I already mentioned in my reply to Klaas' review of draft-ietf-emu-chbind-02 (http://www.ietf.org/mail-archive/web/emu/current/msg01140.html) that I could remove this additional feature, if there is a group consensus to do so. So please let's concentrate on this issue and not rehash the whole channel binding discussion. Is this the only issue that people are having with the draft? If so, I'd be interested if 1) there is a group consensus to remove the authorization feature and 2) whether removing this feature solves all open issues with the draft. Thanks, Katrin > -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Stephen Hanna > Sent: Tuesday, August 11, 2009 4:00 PM > To: Glen Zorn; 'Alan DeKok' > Cc: emu@ietf.org > Subject: Re: [Emu] EAP and authorization > > This discussion started with the statement that channel bindings > are a form of authorization data. Our charter requires us to > support carrying channel bindings in the tunnel method. > Password change is another form of non-authentication data > that we need to support. Clearly there are several kinds of > non-authentication data that we must support carrying in EAP. > They are in our charter. I see no harm in also supporting > carrying NEA assessments in the tunnel method. > > The only bizarre engineering here is Glen's suggestion > that because the A in EAP stands for Authentication, it > should not be allowed to carry anything other than > authentication protocols. By that logic, RADIUS should > be prohibited from carrying VLAN assignments and anything > other than authentication information. After all, the A > in RADIUS also stands for authentication. And RADIUS > should be restricted to Dial In access since that's > what the D and I stand for! > > Glen, if you don't have any substantive arguments to > make, don't try to impress us with bluster. > > Thanks, > > Steve > > > -----Original Message----- > > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On > > Behalf Of Glen Zorn > > Sent: Tuesday, August 11, 2009 4:22 PM > > To: 'Alan DeKok' > > Cc: emu@ietf.org > > Subject: Re: [Emu] EAP and authorization > > > > Alan DeKok [mailto:al...@deployingradius.com] writes: > > > > > Glen Zorn wrote: > > > > Alan DeKok [mailto://al...@deployingradius.com] writes: > > > ... > > > >> Prior to authentication, EAP is the only > > communications protocol > > > >> between a supplicant and *anywhere* on the network. It > > is therefore > > > >> natural to overload it as a general purpose transport protocol. > > > > > > > > > > > > >> I believe that is what is happening: authorization > > parameters are > > > >> being exchanged in EAP. This should be made clearer in the > > > documents. > > > > > > > > Above you said ... by way of rationalizing > > > > > > "explaining" > > > > > > The two are very different. > > > > > > > the use of EAP "as a general purpose transport protocol". I could > > > have > > > > sworn that authorization _follows_ and is parameterized by > > > authentication. > > > > > > I agree. I haven't seen any proposal that contradicts this. > > > > > > > So, please tell me again why EAP should be (further) > > bastardized for > > > this purpose. > > > > > > People are proposing it because they find it useful. > > This isn't mean > > > it's a good idea, just that it's one that has real-world uses. > > > > > > My message about this topic was intended to foster discussion. > > > > Success! > > > > > If > > > there is strong objection to the idea, we can refuse to "bastardize" > > > EAP. If there is strong consensus that this is necessary, > > it's best to > > > make it explicit in the documents. > > > > More likely the creation of a new protocol, unless > > "convenience" (a word that is used often in the draft as > > (often the only) justification for bizarre additions to EAP) > > has taken precedence over engineering in this WG. > > > > > > > > Alan DeKok. > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
