Authentication, Authorization, and Accounting (AAA) is a security management framework for network access control. It determines which users can access the network and which resources or services are available to authorized users. This document introduces the three elements of AAA and its implementation, used protocols, as well as applications.
Authentication: confirms the identities of users accessing the network and determines whether the users are authorized.
 Authentication The AAA server compares a user's authentication credentials with those stored in a database. If the credentials match, the user passes identity authentication and is permitted access to the network. If the credentials do not match, the user fails identity authentication and is denied access to the network. The following lists the typical authentication credentials:
Authorization: assigns differentiated rights to authorize users to use specific services.
Authorization After a user passes identity authentication, the following items are authorized to the user:
Authorization follows the least privilege principle. That is, users are granted only the permissions required for executing required functions to prevent any accidental or malicious network behavior.
Accounting: records all the operations of a user during the network service process, including who, when, and what has been performed.
Accounting Accounting records the used service type, start time, and data traffic to collect and record the network resource usage of the user for implementing time- or traffic-based accounting and network monitoring. How Does AAA Work?AAA uses the client/server structure, which is simple, scalable, and facilitates centralized user information management.
AAA framework As shown in the preceding figure, the basic AAA implementation process is as follows:
In the AAA framework:
What Protocols Are Used in AAA?AAA implements authentication, authorization, and accounting through multiple protocols.
RADIUS is a standard protocol supported by almost all mainstream device vendors. Therefore, RADIUS is most widely used on live networks. In RADIUS, authentication and authorization are defined in RFC 2865, while accounting is defined in RFC 2866. RADIUS was defined earlier than the AAA framework model, and RADIUS combines authentication and authorization. Therefore, when AAA is implemented through RADIUS, the user may not know whether the access is denied because of an authentication failure (for example, the password is incorrect) or an authorization failure (for example, the user does not have the permission).
TACACS is an AAA protocol originated in the 1980s. In later development, vendors extended TACACS. For example, Cisco developed TACACS+, whereas Huawei developed Huawei Terminal Access Controller Access Control System (HWTACACS). TACACS+ and HWTACACS are proprietary protocols. They gradually replaced TACACS and are no longer compatible with TACACS. HWTACACS is compatible with TACACS+. HWTACACS and TACACS+ define the same packet structure and types. The main difference is that the meanings or types of attributes carried in the authorization and accounting packets are not exactly the same. Compared with RADIUS, HWTACACS and TACACS+ are more suitable for identity authentication of login users (such as STelnet users). This is because HWTACACS or TACACS+ is more secure in data transmission and encryption, and provides advantages such as command authentication and event recording.
The Lightweight Directory Access Protocol (LDAP) is implemented based on the TCP/IP protocol suite. LDAP can be considered as a database, which can store various types of hierarchical, structured, and associated data, such as email addresses, human resources data, and contact lists. LDAP implements authentication and authorization through bind and query operations. It is typically used in single sign-on (SSO) scenarios. For example, an enterprise user can access multiple mutually trusted application systems after logging in to a PC. Active Directory (AD) is an application instance of LDAP. It is a component that provides directory services to store user information on the Windows operating system. Compared with LDAP, AD integrates the Kerberos protocol into the LDAP authentication process and uses the symmetric key mechanism of Kerberos to prevent user passwords from being disclosed.
Diameter is a next-generation AAA protocol defined by the IETF. It evolves from RADIUS. Diameter overcomes many disadvantages of RADIUS. For example, Diameter supports authentication, authorization, and accounting of mobile IP, multiple interfaces, and mobile agents. With the maturity and standardization of the Diameter protocol and its applications, it will play a great role in promoting the development of the future mobile communication system and broadband access system. What Are the Applications of AAA?Based on the user access mode, AAA can be applied in the following scenarios:
The authentication process is a foundational aspect of network security. In this video, you’ll learn about AAA, authentication factors, federation, single sign-on, and more. << Previous Video: Physical Security Controls Next: Identity and Access Services >> The AAA framework is a foundation of network security. When we’re logging into our network to gain access to resources, we’re usually providing a username and password so that we can prove who we are. And that process of identifying ourselves passes through this authentication, authorization, and accounting framework. The authentication portion of the AAA framework is the part where we can prove that we are who we say we are. We usually provide a username and password, and often additional authentication factors, to help prove that we really are who we say we are. Once we’ve identified ourself and authenticated into the AAA framework, the authorization part is going to determine what type of access we have to the resources available on the network. And the last A in the AAA framework is accounting. It’s a way to keep a log of exactly who logged in, the date and time this login occurred, and when this person may have logged out. When we are authenticating into this AAA framework, there may be a number of factors that could be asked of us so that we can really prove who we say we are. Some of these most common factors are something you are, something you have, something you know, somewhere you are, and something you do. Providing these additional factors of authentication may have a cost associated with them. For example, it may require that everyone carry a hardware-based pseudo-random token generator with them, and each one of those tokens has a cost associated with it. If one of the factors is looking for biometric readings, it may require specialized hardware to be able to take those biometric measurements. But depending on how you implement this authentication, there may be very little cost associated with it. For example, there can be free smartphone applications that you can use to take the place of some of these hardware-based systems. The authentication factor of some thing you are is usually referring to part of you as a person. This would be a biometric authentication, that could be a fingerprint, or an iris scan. Usually the biometric system is not saving your actual fingerprint, but instead is creating a mathematical representation and storing that information for use later. These biometric values are obviously very difficult to change because they’re part of you, and they’re very unique because they are something that nobody else has. Usually you’re combining this biometric with some other type of authentication. Biometrics is not an exact science, and being able to layer different types of authentication makes your authentication process that much more secure. One step removed from something you are is something you have, this would be something that you carry with you. For example, a smart card like this one that we would insert into a computer or a laptop would mean that we would have to have physical access to that card to be able to slide it in and confirm that we happen to be in front of that computer. Usually, we’re combining a smart card with a personal identification number or passphrase. That way, someone can’t steal your smart card and use it instead of you. They would also have to know additional pieces of information to provide this level of authentication. Another good way to validate who you are is to provide a specialized certificate that only you have. A very common way to store the certificate is on a USB token, and you would plug in your USB key any time you needed to authenticate. There are also hardware or software tokens that you could use. These devices create pseudo-random numbers that are synchronized on both sides, so you can type in this very specific number that nobody else has and it is confirmed that you must have that particular token with you. A very common type of something we have is our mobile phone. That’s usually not something that’s shared with other people, so we can trust that sending a message to that mobile phone might only be read by the individual who owns the phone. We can then use that message as part of the authentication factor whenever someone is trying to log in to the network. One of the most common authentication factors is something you know. This would commonly be something like a password. We would put our user name into the system and then a secret code or passphrase that we’ve created that we would only know ourselves. Another good example of something you know is a personal identification number. We use these often when we’re using an ATM. It asks for a four-digit code, and it’s a code that only we would know. A specialized type of something you know would be on the front of your phone. On Android devices, you can swipe a very particular pattern to unlock your phone, and you would be the only one who would know what that pattern is. The authentication factor of some where you can be a very useful method of authentication. This is providing details of where you are based on your geographical location. You’re able to log into a system, it knows exactly where you happen to be, and then the system can decide whether that is an appropriate place to be able to authenticate to your systems. One very broad use of somewhere you are is to use an IPv4 address. Not everybody is connecting to the network using an IPv4 address, and even the IP version 4 addresses themselves don’t provide a great deal of geographic accuracy. However, the mobile devices that we carry with us do provide a great deal of geographic accuracy. It can find a very specific location and then allow or disallow someone to authenticate using that particular factor. The authentication factor of something you do is something that’s going to be very unique to the way you do something. A good example of this is handwriting. We all have a very specific signature, and it’s very difficult for someone to duplicate that signature unless they happen to be us. Another way to determine who you happen to be is the way that you type. We all have a certain pattern that we use when we’re typing, and that could be used as a type of authentication factor. This is very similar to using biometrics, but instead of it being something you are, it instead is something that you can do. You may have services on your network that you’d like to make available to as many people as possible. But instead of having to create a separate username and password and account information for every single user, you may want to take advantage of an authentication system that may already exist. That can very easily be accomplished by using a federated network where you can authenticate and authorize between two different organizations. For example, you may have seen a login screen like this on a website that instead of using a traditional email address and password that’s local to that server, you can authenticate using existing Twitter, Facebook, LinkedIn, and other third-party accounts. This is a formal trust process that’s created between these organizations. Usually the password and account information is not shared between these organizations, instead the authentication process is passed to the third party. The third party validates the authentication and then provides the clearance back to the original site. If you’ve ever connected to a large corporate network, then you know there are many different services that you’re taking advantage of. You might be connecting to the internet, there may be file shares that you’re connecting to, and you might be using printers on that network. Imagine if you had to put in a username and password every time you wanted to access one of those services. To avoid that process, most organizations use SSO, or single sign-on. This saves a lot of time for the end user because they don’t have to put in a username and password every time they connect to a new service. There are a number of complexities behind the scenes, and usually there’s a bit of cryptography that takes place but all of this is hidden from the end user. All the end user knows is they put in a username and password when they first connect to the network and everything else from that point on is automatic. If you’re on a Windows network, this is probably using Kerberos to accomplish the single sign-on. But there are also third-party options if you need to have the same type of single sign-on capability used with other systems. Authentication systems rely on trust. Often this trust is within a single organization or domain, but sometimes we have a need to trust other organizations as well. And it’s important that we build and configure these different types of trusts depending on the relationships that we have with those third parties. One of these types of trusts may be a one-way trust where domain B may trust domain A, but it doesn’t work in the other direction. Domain A might not trust domain B. If both sides trust each other, then we have a two-way trust where both sides will trust each other equally. When we’re building these trusts, it’s common to configure either a non-transitive trust or a transitive trust. A non-transitive trust means that we are building a trust to one entity, and this trust that we’re creating will only apply to that particular entity. If we have a transitive trust in this trust relationship could extend itself based on the other trusts that are in place. For example, if domain A trusts domain B, and domain B trusts domain C, a transitive trust would allow domain A to then trust domain C. |
Which element of the AAA framework determines what a particular user can and Cannot do once they have accessed the network?
Pos Terkait
Copyright © 2024 ketajaman Inc.
