![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.
Stephen Hanna writes...
That much I think most of us would agree with. �EAP is a convenient protocol
> 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.
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.
I really hate to have to agree with Glen's position on this, but I do. �I
> They are relevant to the authentication process and the server's
> decision about whether to grant network access.
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.
Assuming that's true -- and it may well be -- then EMU ought to expand the
> There is no harm in doing them as part of the EAP exchange. And there
> is no better way to implement them.
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 at ietf.org
https://www.ietf.org/mailman/listinfo/emu