Hi Steve, I don't think what you're talking about falls into the definition of "channel binding", at least not the one I have, and I wouldn't be surprised if others (like maybe people on the IESG) agree. And I agree with Dave, and Glen, that this isn't authentication either.
"channel bindings" are supposed to solve the lying NAS problem* which is an issue of authentication (is this guy really who he claims to be?). What you want to do is use the EAP tunnel to transfer other kinds of data to do NEA posture checking. And, yes, we should determine whether it is permissible for EMU to work on such a thing. What we shouldn't do is say that it's really part of "authentication" or it's part of "channel binding" and just proceed. Dan. *the example given, at the Philly IETF I think, was of a Russian mobile phone operator that made its cell towers broadcast out that they were actually from an Estonian mobile phone operator and then billed Estonians whose phones connected to them (even when they had manual network selection turned on to intentionally avoid accidentially connecting to the Russian network) as if they were roaming on the Russian network. On Wed, August 12, 2009 11:52 am, Stephen Hanna wrote: > However, I agree that it would be better to get IESG clarification > that carrying authorization data in EAP is permissible. As Alan > suggested, the first step is probably to have a WG consensus > check to verify that we have rough consensus that this should > be permitted. After that, maybe we would ask the IESG for a > clarification of the applicability statement for EAP. > > I will note that the IESG has already approved a change to the > EMU charter to add a work item for channel bindings. So they > have already indicated their support for that effort. > > Thanks, > > Steve > >> -----Original Message----- >> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On >> Behalf Of Dave Nelson >> Sent: Wednesday, August 12, 2009 9:33 AM >> To: emu@ietf.org >> Subject: Re: [Emu] EAP and authorization >> >> Stephen Hanna writes... >> >> > I suppose that my basic argument is a practical one. Password >> > change, channel bindings, and NEA assessments are useful things >> > to do during the EAP exchange. >> >> That much I think most of us would agree with. EAP is a >> convenient protocol >> to use for exchanging that kind of information, even if it's >> stretching the >> original purpose of EAP. Remember, EAP was to be used during the >> authentication phase of PPP. >> >> > They are relevant to the authentication process and the server's >> > decision about whether to grant network access. >> >> I really hate to have to agree with Glen's position on this, >> but I do. I >> firmly believe that you, and others, are conflating elements of >> authorization into the meaning of authentication. >> Authentication is about >> proof of identity. I can be authenticated as Dave Nelson, by >> various means. >> I'm still Dave Nelson whether I'm a good guy or a bad guy. >> If I'm a bad >> guy, you may not want to grant me access to your home. If >> I'm a good guy, >> but an active carrier for Swine Flue, you still may not want >> to grant me >> access to your home. In any case I'm still Dave Nelson, and >> none of the >> other "access control" considerations affect my proof of >> identity. All >> those other considerations are authorization considerations, not >> authentication considerations. >> >> I agree that using words clearly and with their exact meaning >> is important. >> >> However, it appears that the real point of this semantic >> debate is whether >> the "domain of applicability" for EAP will admit the >> introduction on very >> useful, but clearly non-authentication, data elements. It's >> quite possible >> for the WG to have consensus to do so and at the same time be >> in apparent >> conflict with the "domain of applicability" for EAP. Of >> course, maybe the >> WG has within its charter the authority to revise the "domain of >> applicability" for EAP. >> >> > There is no harm in doing them as part of the EAP exchange. >> And there >> > is no better way to implement them. >> >> Assuming that's true -- and it may well be -- then EMU ought >> to expand the >> definition of EAP to explicitly include authorization related >> data, rather >> than making semantic, re-definitional, arguments that the >> authorization data >> is really authentication data. >> >> >> _______________________________________________ >> 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
