Access Control and Identity Management

Some key components of any security scheme are identity verification and access control. There must be some way to make sure a user or service is who or what they claim to be, and to provide the correct level of access when requested. The AAA model (Authentication, Authorization, and Accounting) provides a framework in which these components work together to provide access based on the authenticated identity of the client. The core Security+ exam objectives covered in this chapter are as follows:

• Explain the function and purpose of authentication services
• Explain the fundamental concepts and best practices related to authentication, authorization, and access control
• Implement appropriate security controls when performing account management

Back to book index.

Function and Purpose of Authentication Services

The purpose of an authentication service is to establish the identity of a client authoritatively. In an insecure environment, identity may be established with a simple username, or bypassed altogether. In a secure environment, the client not only presents an identity (such as a username) but also provides authenticating information to prove that the identity provided is genuine.

With the use of a dedicated authentication server or service, an administrator can establish a single nexus for authentication, rather than establishing authentication individually for each network service to be provided. A VPN, print server, and web host, for instance, can all authenticate against a single authentication server. Without an authentication server, usernames and passwords (or other methods of identity verification) would have to be individually established on the VPN gateway, print server, and web server for each user. This section will cover the following topics:

• RADIUS
• TACACS
• TACACS+
• Kerberos
• LDAP
• XTACACS

RADIUS

RADIUS stands for Remote Authentication Dial-in User Service, which is a bit of a misnomer. Though originally conceived as a way for users of remote dial-in connections to authenticate, the RADIUS Protocol is an authentication service that can serve many different types of connections. Whether the connection is internal or remote, dial-up, wireless, or VPN, a RADIUS server can be used to authenticate the connection. RADIUS can also provide authorization and accounting. The focus of RADIUS is network access authentication.

The RADIUS Protocol is an older protocol designed primarily with authentication in mind, not necessarily authenticating in the most secure way possible. The only packets that are encrypted are password packets. These packets are generated through the use of an MD5 hash function, which is no longer considered secure. For this reason, the use of the RADIUS Protocol for authentication may expose both the unencrypted information, such as usernames, and the weakly encrypted content of the password packets to a snooper.

RADIUS officially uses UDP port 1812 for authentication and UDP port 1813 for accounting, but these port numbers were assigned after RADIUS had come into common use. Unofficially, RADIUS uses UDP port 1645 for authentication and UDP port 1646 for accounting. Many RADIUS implementations listen on both sets of ports.

TACACS

TACACS, or Terminal Access Controller Access-Control System, is an alternative basic authentication protocol. Like RADIUS, TACACS is an older protocol designed to authenticate remote connections, but it also can be used to authenticate connections from a variety of sources. TACACS provides the same type of authentication service as RADIUS, but without including the authorization and accounting components. It operates over TCP or UDP port 49.

One of the greatest benefits of TACACS is its ability to operate over TCP, which is considered more reliable. Like RADIUS, the focus of TACACS is network access authentication. It is an open authentication standard, though less fully featured than the Cisco proprietary TACACS+ and XTACACS. TACACS is still commonly used in UNIX environments.

TACACS+

TACACS+ allows for much more than simple authentication. TACACS+ is a Cisco proprietary protocol intended to improve upon the TACACS Protocol. The major enhancement in TACACS+ over TACACS is the inclusion of authorization and accounting. Furthermore, the authorization works at a granular level, known as command authorization, allowing a switch or a router to verify with a TACACS+ whether a remote user is authorized to execute specific commands before allowing the user to execute them.

Because TACACS+ does so much more than TACACS or RADIUS, it also tends to have a higher network resource overhead. For instance, multiple challenge response sessions occur for each session, one each for authentication, authorization, and accounting. TACACS+ is considered more secure than RADIUS, as the entire authentication session is encrypted, not just the password packets.

TACACS+ authentication, authorization, and accounting components are modular, where RADIUS integrates authentication and accounting. This allows TACACS+ to offload authentication while still implementing the other features of TACACS+.

Due to the feature-set and Cisco proprietary nature of TACACS+, it is most commonly used to control access to routers and switches. TACACS+ is not backwards compatible with earlier TACACS versions.

Kerberos

Kerberos is a network authentication protocol wherein the client and the server authenticate to one another and can present that authentication to other network services. This allows a user to authenticate against a single server for multiple services.

Kerberos is designed to allow secure authentication for varied network resources across insecure networks. Clients are authenticated and are granted tickets to authorize access to network resources. The process is designed so that the user keys (passwords) never traverse the network, and each ticket builds on previously established authentication and authorization. The Kerberos resource request process is described in detail as follows:

The Authentication Server is concerned with verifying the identity of the user. This is accomplished by the user sending an unencrypted user ID to the server. This is the only unencrypted communication that occurs. The server then uses symmetrical encryption and a shared secret to generate a secret key, usually the hash of the shared secret. This key is known as the user secret key. The authenticating user already has a copy of this user secret key. This key is never sent across the network.

The server uses this user secret key to securely send the user a Ticket Granting Service (TGS) session key. Only a user in possession of the user secret key is able to read this TGS session key.

The Authentication Server also sends the user a Ticket Granting Ticket (TGT), which is encrypted with the server secret key. The TGT contains client ID, client network address, ticket validity period, and the client TGS session key. The user does not have the information necessary to decrypt the TGT.

Now that the user has received a TGT and a TGS session key, the user has enough information to authenticate to the TGS server.

To request access to a network service, the client will send the ticket granting service the TGT and the client ID of the requested service. The client will also send their client ID but will encrypt it using the TGS session key. The TGS server is able to decrypt the TGT to extract the client’s TGS session key, and then use the client’s TGS session key to authenticate the client.

When the TGS server authenticates the client, it delivers the information necessary for the client to authenticate to the requested service server. The TGS will send the client a Client/Server Ticket, which is encrypted with the service server’s secret key. The client cannot decrypt the Client/Server Ticket, just as the client cannot decrypt the TGT.

The TGS will also send the client a Client/Server Session Key, encrypted with the previously established Client/TGS session key. Through this series of secure exchanges, the client is now in possession of all the data necessary to authenticate to the service server.

The client will provide the service server the Client/Server Ticket, which the service server is able to decrypt. The Client/Server Ticket contains the client ID, client network address, validity period, and the Client/Server Session Key. The client will also provide the service server an authentication with the client ID, encrypted with the Client/Server Session Key. This authenticates the client to the service server. The server responds with an authentication message to the client, encrypted using the same Client/Server Session Key. This authenticates the service server to the client.

After this exchange, the authentication and authorization is complete, and the service server can provide services to the client until the client tickets expire. Upon ticket expiration, the entire process repeats for any tickets that have expired.

LDAP

While LDAP (Lightweight Directory Access Protocol) is not an AAA service per se, it can be a very simple and low overhead way to read or change X.500 directory information across a network. LDAP is a very common way to access Active Directory, Apple Directory, and Novell eDirectory information. LDAP operates over TCP port 389 most commonly. It can also run over UDP port 389.

The use of LDAP can make locating network resources and information regarding network resources much more efficient. LDAP can support queries from a wide variety of sources, potentially providing a single point of network user management.

XTACACS

XTACACS stands for Extended TACACS, which is the intermediate technology between TACACS and TACACS+. Where TACACS provides only authentication and TACACS+ provides modular authentication, authorization, and accounting with command-level authorization, XTACACS was developed as a step toward changing TACACS to fulfill the needs of the AAA security model. It includes supports for authorization and accounting but has a more limited feature set than TACACS+ does.

XTACACS is backward compatible with TACACS. Both TACACS and XTACACS have largely been replaced by TACACS+.

Fundamental Concepts and Best Practices Related to Authentication, Authorization, and Access Control

When it comes to access to network resources, there are a number of ways to make sure that only certain people are able to perform certain tasks. In this section, we will discuss the principles behind identification, authorization, and access control. We will also look at some of the practical methods that can be implemented to ensure the identity of the users on a system. This section will cover the following topics:

• Identification versus authentication
• Authentication (single factor) and authorization
• Multifactor authentication
• Biometrics
• Tokens
• Smart card
• Common Access Card (CAC)
• Personal Identity Verification card (PIV)
• Least privilege
• Separation of duties
• Single sign-on (SSO)
• ACLs
• Access control
• Mandatory access control
• Discretionary access control
• Role/rule-based access control
• Implicit Deny
• Time-of-day restrictions
• Trusted OS
• Mandatory vacations
• Job rotation

Identification versus Authentication

Identification is the act of claiming an identity. A logon without a password is a good example of identification. A timecard punch machine is another good example of identification. These identification processes allow an identity to be claimed, but they do not have any mechanism to ensure that the identity claimed is in fact the identity of the claimant.

The process of ensuring that users can identify only as themselves is known as authentication. Authentication adds a verification step to the identification process. The stronger the authentication method chosen, the more confidence can be placed on the identity presented.

Authentication (Single Factor) and Authorization

Authentication usually falls under three basic types, known as authentication factors: something you know, such as a password; something you have, such as a key or a badge; and something you are, such as a fingerprint scan.

Single factor authentication relies on any single type of method to ensure the identity of a user. A password is something you know and is the most common type of single factor authentication. A username and a PIN would also be considered single factor authentication because they fall under the same category of something you know. Another example of an authentication factor is a locked door, which usually requires a key, something you have.

Any of these methods are sufficient to establish the identity and authorization of a user in certain circumstances. The greatest advantage of single factor authentication is that unauthenticated individuals are still denied access, while the authentication process remains relatively simple. The greatest disadvantage lies in the possibility of a single factor being compromised. A password can be inadvertently disclosed, a PIN can be shoulder-surfed, or a key can be lost or stolen.

There are ways to increase the confidence we have in the identity of an authenticating individual, but as we introduce more factors to the authentication process, we increase our confidence at the cost of some simplicity.

Multifactor Authentication

If, instead of just requiring a key (something you have) to open a door, we also require a combination, we can increase our confidence in the authenticating individual’s identity. The requirement of multiple types of authentication mechanisms is known as multifactor authentication. This increases the number of hurdles an attacker must clear to gain access. Now, if an employee loses a key or set of keys, the organization is no longer immediately open to unauthorized access.

One everyday example of multifactor authentication is an ATM card that requires a pin. To withdraw money from an account, the user has to present something they have, the ATM card, and something they know, the PIN. For situations where ensuring the identity of the user is crucial, multifactor authentication is a must.

Biometrics

Though most of our examples have focused on something you know or something you have, there is a third type of authentication: something you are. Using a person’s physical characteristics to authenticate his or her identity is known as biometrics. The convenience store clerk who checks to ensure the face in real life is a match to the face on the ID is engaging in biometric analysis. When an automated system examines a user’s fingerprint, or retina, or typing cadence, or voice, the system is engaging in biometric analysis.

Tokens

The “something you have” category can take many different forms. One method of increasing security is to grant authorized users access to a USB token, or dongle. This device may need to be connected to the computer at the time of login, or it may generate one-time use passwords or PINs that must authenticate to a central server. Using a USB token or token generator is one way to add “something you have” to the authentication process.

Smart Card

Another “something you have” method of authentication is a smart card. This functions similarly to the USB dongle that requires a connection to a computer. The smart card has a chip that must be scanned before access will be granted. The chip contains a certificate tied to a certain user account, and it may require a PIN. It may also act as a non-electronic form of identification, with electronic identity information available on the card.

Common Access Card (CAC)

One specific type of smart card is the Common Access Card (CAC) issued by the United States Department of Defense. A CAC can include photo identification, barcode-encoded information, and embedded PKI and authentication information.

Personal Identity Verification Card (PIV)

Another common smart card is the Personal Identity Verification (PIV) card. This card, granted to federal employees and contractors, contains the necessary data for the cardholder to be granted access to Federal facilities and information systems.

Least Privilege

A security principle that is vital in controlling access to network resources is the principle of least privilege. In any case where access is to be granted to shared resources, the goal is to grant as much access as is needed and as little access as possible. If a user does not need to be able to delete documents, but does need to read them, he or she should be granted only read access.

Separation of Duties

The separation of duties can ensure that no one user or employee is able to singlehandedly make large and possibly detrimental decisions. Just as it is very common to require review and authorization for an unusually large check to be written, it is a good idea to require input from more than one source before making serious infrastructure changes.

Single Sign-on (SSO)

Single sign-on is a concept that allows users to sign on only once to access a wide variety of different network resources. One example of SSO that we have already discussed is Kerberos. Some technical complexity exists in the design of SSO systems, but these systems can greatly contribute to a system’s ease of use from a user perspective. With single sign-on, a user can enter authentication information once and carry that authenticated state with him or her during an entire session.

ACLs

ACLs, or access control lists, are a basic networking tool to determine what traffic can or cannot flow across a network link. These ACLs can be configured to allow traffic based on source network, destination network, or port number, and in any combination.

The configuration of ACLs is a vitally important step for any network that will allow remote access, allowing in only the necessary traffic. ACLs are applied according to the first matching rule. The inclusion, as the final rule, of a rule to deny traffic from all sources to all destinations can establish an implicit Deny form of access control.

Access Control

Access control is just what it sounds like – determining who can and who cannot access network resources. Many different models can be used to assign user rights and privileges. As with all sensitive information, it is best to allow only the access needed. The model you adopt may be shaped by the level of protection the network resources require.

Mandatory Access Control

In mandatory access control, permissions are granted at a level that the user or running processes on the local computer are unable to override. A user in a system based on mandatory access control would not be able to share his or her own data with another user. The policy is set from above and applied. In mandatory access control environments, access to a resource will not be granted unless a rule exists specifically granting access. This is the strictest form of access control.

Discretionary Access Control

In discretionary access control, the owner of an object determines the ability of other users to access the object. Each file or folder has an owner, and there is no central authority for establishing who can access what data. Because this type of access control is easily subverted, and control of the data so diffuse, it is not normally recommended for environments with sensitive data.

Role/Rule-based Access Control

In the role-based access control model, users are assigned to roles, and those roles are granted permission to access resources. For instance, three part-time receptionists may have nearly identical permissions requirements. Rather than assigning the permissions to each receptionist individually, an administrator could assign those permissions to a receptionist role and assign the role to each of the receptionists.

These settings can be by department, by level of authority, by job role, or by any other criteria. A user can be assigned to multiple roles, and as long as any role has permissions to access a resource, the user will have the ability to access the resource. Role-based access control greatly simplifies the maintenance of user and group permissions.

Implicit Deny

Implicit Deny is an important security principle. A system can either default to granting access (open and insecure) or default to denying access (closed and secure). In those situations where a rule has not been configured to grant access, systems that must be secure should default to denying access. This “When in doubt, lock them out” practice ensures that resources do not accidentally open up to any and all users. Maintaining the implicit Deny is a basic security practice.

Time-of-Day Restrictions

Access can be restricted not just with object level or role-based permissions but also with time-of-day permissions. It may be necessary to allow different levels of access depending on the time of day. This may prevent changes to data while it is being backed up, or it may prevent access to restricted areas outside of normal office hours.

Trusted OS

The trusted OS is a concept relevant for extremely high security or sensitive systems. Because all of the operations of a computer rely on the OS to run, an untrustworthy OS can lead to a total compromise of all the data to which the computer has access. Operating systems can be designed, evaluated, and tested specifically to ensure they are trustworthy. A set of standards trusted operating systems seek to meet is known as the Common Criteria for Information Technology Security Evaluation (Common Criteria).

There is also an Evaluation Assurance Level (EAL) that ranks from 1 to 7. The higher an OS is ranked in EAL, the more rigorous testing the OS has been subjected to, and the better it has been shown to conform to the Common Criteria for trusted operating systems.

Mandatory Vacations

Mandatory vacations can be imposed on employees to ensure that another employee will occasionally review any work commonly done by the vacationing employee. This can help to deter or reveal any inappropriate conduct that an employee might otherwise be able to hide.

Job Rotation

Similarly, job rotation, in which employees regularly change job roles, can guarantee that each person’s work is regularly reviewed by another employee. This guarantees another set of eyes regularly reviewing any work, but this practice runs the risk of preventing specialization and deep proficiency in any job role.

Appropriate Security Controls When Performing Account Management

In an environment where data security is of utmost concern, limiting access to that data becomes an important consideration. When users have multiple accounts or responsibilities, or account policy enforcement is lax, this can be difficult to maintain, and sensitive data can slip through the cracks. Therefore, it is necessary to enforce strict controls on user accounts and privileges. This section will cover the following topics:

• Mitigate issues associated with users with multiple accounts/roles
• Account policy enforcement
• Group-based privileges
• User-assigned privileges

Mitigate Issues Associated with Users with Multiple Accounts/Roles

Users with multiple accounts and/or roles can have a menagerie of capabilities that can be difficult to keep track of in a large environment. A security principle that can help mitigate issues that arise from this situation is to apply the principle of least privilege: allowing users only those permissions that they need in order to complete their work, regardless of how many or what type of accounts they use. Account audits should be undertaken as frequently as necessary to ensure the principle of least privilege is being followed.

Account Policy Enforcement

To ensure your user accounts are not compromised and their privileges abused for malicious purposes, it is vital to enforce account management policies. These policies include minimum password length, complexity rules, password age (expiration), self-service password reset, account lockout rules, and temporary account types for contractors or temporary employees.

Group-based Privileges

Along the same lines as caring for users with multiple user accounts, users with multiple group memberships can be cause for security concern. Users belonging to multiple groups can end up with a diverse set of privileges that may not be desirable. It is important to monitor group-based privileges and to calculate effective privileges on users, and notice whether any users are receiving privileges they should not be.

User-assigned Privileges

With that in mind, it is also important to ensure individual users are not restricted to the point where they are unable to perform their work, or the help desk/tech support is not unduly flooded with requests for assistance. Too many requirements for oversight in a fully managed environment can cause an exasperated administrator to allow policy violations, such as incorrect privileges, too many privileges, incorrect user account type, etc., to slip through the cracks. User-assigned privileges must be monitored with care and should usually follow a precedent when configured initially to ensure all users have a predictable set of privileges based on account type. User-assigned privileges are not as easy to manage as group-based privileges are, simply due to the number of instances that must be changed.