Hi Alan, On Sun, August 16, 2009 1:09 am, Alan DeKok wrote: > Dan Harkins wrote: >> "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. > > My question again is where do we draw the line? What information is > permissible as authentication credentials, and what isn't permissible?
Authentication has to do with proving an identity. Authorization has to do with determining whether that proven identity is "good" or "bad". > And why? Because it helps answer questions like "why isn't this part of authentication?" > Some sites determine that username/password authentication is > sufficient. Others also require that the MAC be known, too. Is the MAC > part of the authentication credentials? Or is the site doing "posture > checking" by requiring that the MAC be known? I'm not sure what sites do what but I'm not aware of an EAP method that checks a username and a password AND a MAC address. If the policy says, "Alan DeKok is only allowed to access the network if he's on 00:01:02:03:04:05" then the MAC address is not an authentication credential because the username and password are deciding the identity and the MAC address is deciding whether that authenticated identity is "good" or "bad". > We need to achieve a common understanding before making any decisions. Yes, but I hope it's not by going through a hundred or so different things and gauging consensus on "is it authentication or authorization?" Ask yourself, what is the identity of this peer and is this thing critical to proving that identity or not? If it is critical to proving the identity (like a CA certificate to perform validation of the peer's certificate, for instance) then it's for authentication, otherwise it's not for authentication. Channel bindings are subtly different. Since a 2-party protocol is being used with 3 parties it is necessary to ensure that all 3 parties have a consistent view of all 3 identities. But that's still an authentication problem-- is this 3rd entity really who it says it is? Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
