Actually, in the email that you responded to, I was referring to the EMU working group item in the current charter:
- A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. I hope that we can both agree that this falls within our definition of "channel binding". Otherwise, we really have a communication failure! ;-) I do not agree that EAP channel bindings are about authentication. They have two parts: checking whether the NAS is advertising services that it's not authorized to advertise and using information from the NAS (like which SSID the peer is trying to connect to) to supplement the AAA server's decision about whether to grant the requested access. Both of these are authorization decisions and they are made not based on authenticating the NAS (which we have had for many years in the form of the secret shared between the NAS and the AAA server) but on supplementary information about the SSIDs and other things being advertised by the NAS and requested by the EAP peer. I agree that NEA assessments are a different topic. They're not the same as channel bindings. I'd say that the data conveyed in EAP for channel bindings and for NEA assessments are both authorization data in that they are not authentication protocols but supplementary data that the AAA server will use in deciding whether access should be granted (and maybe whether other action should be taken, like getting the lying NAS repaired or sending remediation instructions to an unhealthy endpoint). Thanks, Steve > -----Original Message----- > From: Dan Harkins [mailto:[email protected]] > Sent: Sunday, August 16, 2009 3:30 AM > To: Stephen Hanna > Cc: Dave Nelson; [email protected] > Subject: Re: [Emu] EAP and authorization > > > 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: [email protected] [mailto:[email protected]] On > >> Behalf Of Dave Nelson > >> Sent: Wednesday, August 12, 2009 9:33 AM > >> To: [email protected] > >> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/emu > >> > > _______________________________________________ > > Emu mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/emu > > > > > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
