Dave et all, I agree that Authentication in the truest sense of the term is about knowing and verifying who someone is or what something is (you can authenticate things in addition to people). Also remember that authentication is NOT restricted to just usernames and passwords. If we look at a business as a whole, not just the IT network there are lots of different types of data that can be used as authentication credentials. Things from fingerprints, retinal scans, facial recognition, stored CERT, hidden values in the registry of Windows boxes, simple host based names, ID badges or labels, stickers on the rear window of a car, etc can all be used as authentication in the business. Some of these are viewed as really weak forms of authentication and others as really strong, but the point is that everything from strong to really weak data can be used for authentication. It all depends on your appetite for risk.
Given EAP and 802.1X it can also interesting to authentication a system at the same time you authenticate a user. One use case is to make sure that a said computer is one of the company owned computers or looks enough like a company owned computer to be acceptable. You may assess that the computer is company owned computer if it has some hidden regkey, it has a certain vendor's MAC address, it has a hidden file on the filesystem or that the system is fully compliant with the Security Policy of the organization. This is not Authorization of the computer to the network but is verifying that the computer is a company owned or a system that is deemed to look enough like a company owned system to be allowed access to the network, which is authentication. Now EAP back in the day may have been the brain child of simple authentication for PPP links. However, today we need to look into what is really needed to enforce Security Policies on networks. It is my belief that regardless of the legacy name given to the protocol, EAP, EAP makes a great transport for dealing with the age old questions "is this user who they say they are" which has been expanded in recent years to be, "is this user who they say they are and are they using a company owned system in the right part of the building at the right time of day). Yes the later half of the second age old question is a mix of authentication and authorization, but this is the world we live in, for better or worse. NEA and other attributes/data tunneled inside of EAP allow the authentication server and thus the business make more educated decisions about whether or not someone is who they say they are or a machine is what it says it is. This is authentication. Think of this in the terms of the security guard that checks ID badges when you enter the building. If a homeless person, all dressed in rags walks in to Chase Bank headquarters with a valid ID badge, the Security Guard will probably not trust his authentication, the ID badge. Even though the ID badge is valid. The ID badge grants the holder to access certain resources, but the Security Guard through visual inspection is able to make a better determination of are these authentication credentials valid. The username / password presented is often not enough to guarantee that the user is who the user says they are. A business may want to make sure they are using a certain computer, the computer is in a certain location, the computer is being used a certain time of day, and the computer has certain things, before they grant network access. This is NOT authorization. It is all about making sure people are really and honestly who they say they are. Some businesses and government agencies build profiles of work habits. So if I try to use my username/password after what is deemed my normal work patterns, that username/password is not accepted. It is not that I am not authorized to use the systems at weird hours, the system just knows that it is out side my normal usage times and thus it may need to ask me follow up questions to verify that I really am who I say I am. This is all about authentication. Bret On Wed, Aug 12, 2009 at 7:33 AM, Dave Nelson <d.b.nel...@comcast.net> wrote: > 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
