Chapter 4: Authentication, Authorization, Accounting (AAA) and Identity Management PDF
Document Details
Uploaded by jmclark59
null
Tags
Related
- Module 04 - Identification, Authentication, and Authorization_fax_ocred.pdf
- JTO Ph-II (DNIT) Motive Metasol Elitecore Netsweeper PDF
- Chapter 4_Access Control, Authentication, Authorization and Non-Repudiation .pdf
- Cybersecurity Fundamentals PDF
- Fundamental Security Concepts PDF
- Fundamental Security Concepts PDF
Summary
This document provides an overview of authentication, authorization, and accounting (AAA) and identity management. It discusses different authentication methods such as knowledge-based, possession-based, and characteristic-based authentication. The chapter also explores the importance of least privilege and separation of duties.
Full Transcript
# Chapter 4: Authentication, Authorization, Accounting (AAA) and Identity Management This chapter covers the following topics: * Introduction to Authentication, Authorization, and Accounting * Authentication * Authorization * Accounting * Infrastructure Access Controls * AAA Protocols * Cisco Ide...
# Chapter 4: Authentication, Authorization, Accounting (AAA) and Identity Management This chapter covers the following topics: * Introduction to Authentication, Authorization, and Accounting * Authentication * Authorization * Accounting * Infrastructure Access Controls * AAA Protocols * Cisco Identity Services Engine (ISE) * Configuring TACACS+ Access * Configuring RADIUS Authentication * Additional Cisco ISE Design Tips ## Foundation Topics ### Introduction to Authentication, Authorization, and Accounting In Chapter 1, "Cybersecurity Fundamentals", you learned about different types of authentication-based attacks and high-level concepts of the authentication process. In the following sections, you will learn the tenets of authentication, authorization, and accounting (AAA). An identification scheme, an authentication method, and an authorization model are common attributes of access controls. **Note:** Access controls are security features that govern how users and processes communicate and interact with systems and resources. The primary objective of access controls is to protect information and information systems from unauthorized access (confidentiality); modification (integrity), or disruption (availability). When we're discussing access controls, the active entity (that is, the user or system) that requests access to a resource or data is referred to as the subject, and the passive entity being accessed or being acted upon is referred to as the object. An identification scheme is used to identify unique records in a set such as a username. Identification is the process of the subject supplying an identifier to the object. The authentication method is how identification is proven to be genuine. Authentication is the process of the subject supplying verifiable credentials to the object. The authorization model defines how access rights and permission are granted. Authorization is the process of assigning authenticated subjects the permission to carry out a specific operation. ### The Principle of Least Privilege and Separation of Duties The principle of least privilege states that all users-whether they are individual contributors, managers, directors, or executives-should be granted only the level of privilege they need to do their jobs, and no more. For example, a sales account manager really has no business having administrator privileges over the network, or a call center staff member over critical corporate financial data. The same concept can be applied to software. For example, programs or processes running on a system should have the capabilities they need to get their job done, but no root access to the system. If a vulnerability is exploited on a system that runs everything as root, the damage could extend to a complete compromise of the system. This is why you should always limit users, applications, and processes to access and run as the least privilege they need. Somewhat related to the principle of least privilege is the concept of "need to know," which means that users should get access only to data and systems that they need to do their job, and no other. Separation of duties is an administrative control that dictates that a single individual should not perform all critical- or privileged-level duties. Additionally, important duties must be separated or divided among several individuals within the organization. The goal is to safeguard against a single individual performing sufficiently critical or privileged actions that could seriously damage a system or the organization as a whole. For instance, security auditors responsible for reviewing security logs should not necessarily have administrative rights over the systems. Another example is that a network administrator should not have the ability to alter logs on the system. This is to prevent such individuals from carrying out unauthorized actions and then deleting evidence of such actions from the logs (in other words, covering their tracks). Think about two software developers in the same organization ultimately working towards a common goal, but one is tasked with developing a portion of a critical application and the other is tasked with creating an application programming interface (API) for other critical applications. Each developer has the same seniority and working grade level; however, they do not know or have access to each other's work or systems. ## Authentication Identification is the process of providing the identity of a subject or user. This is the first step in the authentication, authorization, and accounting process. Providing a username, a passport, an IP address, or even pronouncing your name is a form of identification. A secure identity should be unique in the sense that two users should be able to identify themselves unambiguously. This is particularly important in the context of account monitoring. Duplication of identity is possible if the authentication systems are not connected. For example, a user can use the same user ID for his corporate account and for his personal email account. A secure identity should also be nondescriptive so that information about the user's identity cannot be inferred. For example, using "Administrator" as the user ID is generally not recommended. An identity should also be issued in a secure way. This includes all processes and steps in requesting and approving an identity request. This property is usually referred to as "secure issuance." The following list highlights the key concepts of identification: * Identities should be unique. Two users with the same identity should not be allowed. * Identities should be nondescriptive, meaning it should not be possible to infer the role or function of the user from his or her identity. For example, a user called "admin" represents a descriptive identity, whereas a user called "om1337ar" represents a nondescriptive identity. * Identities should be securely issued. A secure process for issuing an identity to a user needs to be established. * Identities can be location-based. A process for authenticating someone based on his or her location needs to be established. ## Authentication by Knowledge Authentication by knowledge is where the user provides a secret that is only known by him or her. An example of authentication by knowledge would be a user providing a password, a personal identification number (PIN) code, or answering security questions. The disadvantage of using this method is that once the information is lost or stolen (for example, if a user's password is stolen), an attacker would be able to successfully authenticate. Nowadays, a day does not pass without hearing about a new breach in retailers, service providers, cloud services, and social media companies. **Note:** If you look at the VERIS community database, you will see hundreds of breach cases where users' passwords were exposed (https://github.com/vz-risk/VCDB). Websites like "Have I been pwned" (https://haveibeenpwned.com) include a database of billions of usernames and passwords from past breaches and even allow you to search for your email address to see if your account or information has potentially been exposed. ## Authentication by Ownership or Possession With this type of authentication, the user is asked to provide proof that he owns something specific-for example, a system might require an employee to use a badge to access a facility. Another example of authentication by ownership is the use of a token or smart card. Similar to the previous method, if an attacker is able to steal the object used for authentication, he will be able to successfully access the system. Examples of authentication by ownership or possession include the following: a one-time passcode, memory card, smartcard, and out-of-band communication. The most common of the four is the one-time passcode sent to a device in the user's possession. A one-time passcode (OTP) is a set of characteristics that can be used to prove a subject's identity one time and one time only. Because the OTP is valid for only one access, if it's captured, additional access would be automatically denied. OTPs are generally delivered through a hardware or software token device. The token displays the code, which must then be typed in at the authentication screen. Alternatively, the OTP may be delivered via email, text message, or phone call to a predetermined address or phone number. A memory card is an authentication mechanism that holds user information within a magnetic strip and relies on a reader to process the information. The user inserts the card into the reader and enters a personal identification number (PIN). Generally, the PIN is hashed and stored on the magnetic strip. The reader hashes the inputted PIN and compares it to the value on the card itself. A familiar example of this is a bank ATM card. A smartcard works in a similar fashion. Instead of a magnetic strip, it has a microprocessor and integrated circuits. The user inserts the card into a reader, which has electrical contacts that interface with the card and power the processor. The user enters a PIN that unlocks the information. The card can hold the user's private key, generate an OTP, or respond to a challenge-response. Out-of-band authentication requires communication over a channel that is distinct from the first factor. A cellular network is commonly used for out-of-band authentication. For example, a user enters her name and password at an application logon prompt (factor 1). The user then receives a call on her mobile phone; the user answers and provides a predetermined code (factor 2). For the authentication to be compromised, the attacker would have to have access to both the computer and the phone. ## Authentication by Characteristic A system that uses authentication by characteristic authenticates the user based on some physical or behavioral characteristic, sometimes referred to as a biometric attribute. The most used physical or physiological characteristics are as follows: * Fingerprints * Face recognition * Retina and iris * Palm and hand geometry * Blood and vascular information * Voice recognition Examples of behavioral characteristics are as follows: * Signature dynamic * Keystroke dynamic/pattern The drawback of a system based on this type of authentication is that it's prone to accuracy errors. For example, a signature-dynamic-based system would authenticate a user by requesting that the user write his signature and then comparing the signature pattern to a record in the system. Given that the way a person signs his name differs slightly every time, the system should be designed so that the user can still authenticate, even if the signature and pattern are not exactly what are in the system. However, it should also not be too loose and unintentionally authenticate an unauthorized user attempting to mimic the pattern. Two types of errors are associated with the accuracy of a biometric system: * A Type I error, also called false rejection, happens when the system rejects a valid user who should have been authenticated. * A Type II error, also called false acceptance, happens when the system accepts a user who should have been rejected (for example, an attacker trying to impersonate a valid user). The crossover error rate (CER), also called the equal error rate (EER), is the point where the rate of false rejection errors (FRR) and the rate of false acceptance errors (FAR) are equal. This is generally accepted as an indicator of the accuracy (and hence the quality) of a biometric system. ## Multifactor Authentication The process of authentication requires the subject to supply verifiable credentials. The credentials are often referred to as factors. Single-factor authentication is when only one factor is presented. The most common method of single-factor authentication is the use of passwords. Multifactor authentication is when two or more factors are presented. Multilayer authentication is when two or more of the same type of factors are presented. Data classification, regulatory requirements, the impact of unauthorized access, and the likelihood of a threat being exercised should all be considered when you're deciding on the level of authentication required. The more factors, the more robust the authentication process. Identification and authentication are often performed together; however, it is important to understand that they are two different operations. Identification is about establishing who you are, whereas authentication is about proving you are the entity you claim to be. In response to password insecurity, many organizations have deployed multifactor authentication options to their users. With multifactor authentication, accounts are protected by something you know (password) and something you have (one-time verification code provided to you). Even gamers have been protecting their accounts using MFA for years. ## Duo Security Duo Security was a company acquired by Cisco that develops a very popular multifactor authentication solution that is used by many small, medium, and large organizations. Duo provides protection of on-premises and cloud-based applications. This is done by both pre-configured solutions and generic configurations via RADIUS, Security Assertion Markup Language (SAML), LDAP, and more. **Tip:** SAML is an open standard for exchanging authentication and authorization data between identity providers. SAML is used in many single sign-on (SSO) implementations. You will learn more about SAML and SSO later in this chapter. Duo integrates with many different third-party applications, cloud services, and other solutions. Duo allows administrators to create policy rules around who can access applications and under what conditions. You can customize policies globally or per user group or application. User enrollment strategy will also inform your policy configuration. Duo Beyond subscribers can benefit from additional management within their environment by configuring a Trusted Endpoints policy to check the posture of the device that is trying to connect to the network, application, or cloud resource. Duo Access Gateway is another component of the Duo solution. The Duo Access Gateway provides multifactor authentication access to cloud applications. You can use your users' existing directory credentials (such as accounts from Microsoft Active Directory or Google Apps). This is done by using the Security Assertion Markup Language (SAML) 2.0 authentication standard. SAML delegates authentication from a service provider to an identity provider. Figure 4-1 shows a high-level overview of the Duo Access Gateway solution. In Figure 4-1, you can see how Duo provides SAML connectors for enterprise cloud applications (Office 365, Google Apps, Amazon Web Services, and so on). The protected cloud applications redirect users to the Duo Access Gateway server that is typically deployed on-premises (that is, on your network). The Duo Access Gateway acts as a SAML identity provider (IdP). It authenticates users by leveraging existing authentication sources for credential verification and then prompting for two-factor authentication before permitting access to the SAML application. **Note:** You can obtain detailed information on how to deploy the different solutions provided by Duo at https://duo.com/docs/getting-started. You can also use Duo to protect virtual private network (VPN) users in your organization. For instance, you can configure a Cisco ASA or Cisco Firepower Threat Defense (FTD) device to terminate connections from remote access VPN clients and integrate Duo to provide multifactor authentication. ## Authorization Once authenticated, a subject must be authorized. Authorization is the process of assigning authenticated subjects permission to carry out a specific operation. The authorization model defines how access rights and permission are granted. The three primary authorization models are object capability, security labels, and ACLs. Object capability is used programmatically and is based on a combination of an unforgeable reference and an operational message. Security labels are mandatory access controls embedded in object and subject properties. Examples of security labels (based on its classification) are "confidential", "secret", and "top secret". Access control lists (ACLs) are used to determine access based on some combination of specific criteria such as a user ID, group membership, classification, location, address, and date. Additionally, when granting access, the authorization process would check the permissions associated with the subject/object pair so that the correct access right is provided. The object owner and management usually decide (or give input on) the permission and authorization policy that governs the authorization process. The authorization policy and rule should take various attributes into consideration, such as the identity of the subject, the location from where the subject is requesting access, the subject's role within the organization, and so on. Access control models, which are described in more detail later in this chapter, provide the framework for the authorization policy implementation. An authorization policy should implement two concepts: * Implicit deny: If no rule is specified for the transaction of the subject/object, the authorization policy should deny the transaction. * Need to know: A subject should be granted access to an object only if the access is needed to carry out the job of the subject. You learned about the least privilege principle and need-to-know concepts earlier in this chapter. ## Mandatory Access Control (MAC) Mandatory access controls (MACs) are defined by policy and cannot be modified by the information owner. MACs are primarily used in secure military and government systems that require a high degree of confidentiality. In a MAC environment, objects are assigned a security label that indicates the classification and category of the resource. Subjects are assigned a security label that indicates a clearance level and assigned categories (based on the need to know). The operating system compares the object's security label with the subject's security label. The subject's clearance must be equal to or greater than the object's classification. The category must match. For example, for a user to access a document classified as "Secret" and categorized as "Flight Plans," the user must have either Secret or Top-Secret clearance and have been tagged to the Flight Plan category. ## Discretionary Access Control (DAC) Discretionary access controls (DACs) are defined by the owner of the object. DACs are used in commercial operating systems. The object owner builds an ACL that allows or denies access to the object based on the user's unique identity. The ACL can reference a user ID or a group (or groups) that the user is a member of. Permissions can be cumulative. For example, John belongs to the Accounting group. The Accounting group is assigned read permissions to the Income Tax folder and the files in the folder. John's user account is assigned write permissions to the Income Tax folder and the files in the folder. Because DAC permissions are cumulative, John can access, read, and write to the files in the Income Tax folder. ## Role-Based Access Control (RBAC) Role-based access controls (RBACS, also called “nondiscretionary controls") are access permissions based on a specific role or function. Administrators grant access rights and permissions to roles. Users are then associated with a single role.There is no provision for assigning rights to a user or group account. Let's take a look at the example illustrated in Figure 4-9. ## Rule-Based Access Control In a rule-based access control environment, access is based on criteria that are independent of the user or group account. The rules are determined by the resource owner. Commonly used criteria include source or destination address, geographic location, and time of day. For example, the ACL on an application requires that it be accessed from a specific workstation. Rule-based access controls can be combined with DACs and RBACS. ## Attribute-Based Access Control Attribute-based access control (ABAC) is a logical access control model that controls access to objects by evaluating rules against the attributes of entities (both subject and object), operations, and the environment relevant to a request. The characteristics of ABAC are as follows: * ABAC supports a complex Boolean rule set that can evaluate many different attributes. * The policies that can be implemented in an ABAC model are limited only to the degree imposed by the computational language and the richness of the available attributes. * An example of an access control framework that is consistent with ABAC is the Extensible Access Control Markup Language (XACML). ## Accounting Accounting is the process of auditing and monitoring what a user does once a specific resource is accessed. This process is sometimes overlooked; however, as a security professional, it is important to be aware of accounting and to advocate that it be implemented because of the great help it provides during detection and investigation of cybersecurity breaches. When accounting is implemented, an audit trail log is created and stored that details when the user has accessed the resource, what the user did with that resource, and when the user stopped using the resource. Given the potential sensitive information included in the auditing logs, special care should be taken in protecting them from unauthorized access. ## Infrastructure Access Controls A network infrastructure is defined as an interconnected group of hosts and devices. The infrastructure can be confined to one location or, as often is the case, widely distributed, including branch locations and home offices. Access to the infrastructure enables the use of its resources. Infrastructure access controls include physical and logical network designs, border devices, communication mechanisms, and host security settings. Because no system is foolproof, access must be continually monitored; if suspicious activity is detected, a response must be initiated. ## Access Control Mechanisms An access control mechanism is, in simple terms, a method for implementing various access control models. A system may implement multiple access control mechanisms. In some modern systems, this notion of an access control mechanism may be considered obsolete because the complexity of the system calls for more advanced mechanisms. Nevertheless, here are some of the most well-known methods: * Access control list (ACL): This is the simplest way to implement a DAC-based system. ACLs can apply to different objects (like files) or they can also be configured statements (policies) in network infrastructure devices (routers, firewalls, etc.). For instance, an ACL, when applied to an object, will include all the subjects that can access the object and their specific permissions. Figure 4-10 shows an example of an ACL applied to a file. **Tip:** After an ACL has been properly configured, apply it to an interface to filter traffic. The security appliance filters packets in both the inbound and outbound directions on an interface. When an inbound ACL is applied to an interface, the security appliance analyzes packets against the ACEs after receiving them. If a packet is permitted by the ACL, the firewall continues to process the packet and eventually passes the packet out the egress interface. In Cisco Next-Generation firewalls you can also configure different access control policies that go beyond the traditional 5-tuple. You will learn detailed information about ACLs and access control policies in Chapter 7, "Cisco Secure Firewall". * Capability table: This is a collection of objects that a subject can access, together with the granted permissions. The key characteristic of a capability table is that it's subject-centric instead of being object centric, like in the case of an access control list. Figure 4-11 shows a user (Derek) capability table. * Access control matrix (ACM): This is an access control mechanism that is usually associated with a DAC-based system. An ACM includes three elements: the subject, the object, and the set of permissions. Each row of an ACM is assigned to a subject, while each column represents an object. The cell that identifies a subject/object pair includes the permission that subject has on the object. An ACM could be seen as a collection of access control lists or a collection of capabilities table, depending on how you want to read it. Figure 4-12 shows an example of access controls using an ACM. * Content-dependent access control: This type of control uses the information (content) within a resource to make an authorization decision. This type of control is generally used in database access controls. A typical example is a database view. **Tip:** A database view could also be considered a type of restricted interface because the available information is restricted depending on the identity of the user. * Context-dependent access control: This type of control uses contextual information to make an access decision, together with other information such as the identity of the subject. For example, a system implementing a context-dependent control may look at events preceding an access request to make an authorization decision. A typical system that uses this type of control is a stateful firewall, such as Cisco ASA, Cisco Firepower Threat Defense (FTD), or Cisco IOS configured with the Zone-Based Firewall feature, where a packet is allowed or denied based on the information related to the session the packet belongs to. ## AAA Protocols Several protocols are used to grant access to networks or systems, provide information about access rights, and provide capabilities used to monitor, audit, and account for user actions once authenticated and authorized. These protocols are called authentication, authorization, and accounting (AAA) protocols. The most well-known AAA protocols are RADIUS, TACACS+, and Diameter. The sections that follow provide some background information about each. ### RADIUS The Remote Authentication Dial-In User Service (RADIUS) is an AAA protocol mainly used to provide network access services. Due to its flexibility, it has been adopted in other scenarios as well. The authentication and authorization parts are specified in RFC 2865, while the accounting part is specified in RFC 2866. RADIUS is a client-server protocol. In the context of RADIUS, the client is the access server, which is the entity to which a user sends the access request. The server is usually a machine running RADIUS services and that provides authentication and authorization responses containing all the information used by the access server to provide service to the user. The RADIUS server can act as proxy for other RADIUS servers or other authentication systems. Also, RADIUS can support several types of authentication mechanisms, such as PPP, PAP, CHAP, and EAP. It also allows protocol extension via the attribute field. For example, vendors can use the attribute "vendor-specific" (type 26) to pass vendor-specific information. Figure 4-13 shows a typical deployment of a RADIUS server, a RADIUS client (wireless router in this example), and a laptop (wireless client or supplicant). RADIUS operates in most cases over UDP protocol port 1812 for authentication and authorization, and port 1813 for accounting, which are the officially assigned ports for this service. In earlier implementations, RADIUS operated over UDP port 1645 for authentication and authorization, and port 1646 for accounting. The authentication and authorization phase consist of two messages: 1. The access server sends an ACCESS-REQUEST to the RADIUS server that includes the user identity, the password, and other information about the requestor of the access (for example, the IP address). 2. The RADIUS server may reply with three different messages: * ACCESS-ACCEPT if the user is authenticated. This message will also include in the Attribute field authorization information and specific vendor information used by the access server to provide services. * ACCESS-REJECT if access for the user is rejected. * ACCESS-CHALLENGE if additional information is needed. RADIUS server needs to send an additional challenge to the access server before authenticating the user. The ACCESS-CHALLENGE will be followed by a new ACCESS-REQUEST message. Figure 4-14 demonstrates the RADIUS exchange for authentication and authorization. The accounting exchange consists of two messages: ACCOUNTING-REQUEST and ACCOUNTING-RESPONSE. Accounting can be used, for example, to specify how long a user has been connected to the network (the start and stop of a session). The RADIUS exchange is authenticated by using a shared secret key between the access server and the RADIUS server. Only the user password information in the ACCESS-REQUEST is encrypted; the rest of the packets are sent in plaintext. ## TACACS+ Terminal Access Controller Access Control System Plus (TACACS+) is a proprietary protocol developed by Cisco. It also uses a client-server model, where the TACACS+ client is the access server and the TACACS+ server is the machine providing TACACS+ services (that is, authentication, authorization, and accounting). Similar to RADIUS, TACACS- also supports protocol extension by allowing vendor-specific attributes and several types of authentication protocols. TACACS- uses TCP as the transport protocol, and the TACACS- server listens on port 49. Using TCP ensures a more reliable connection and fault tolerance. TACACS- has the authentication, authorization, and accounting processes as three separate steps. This allows the use of different protocols (for example, RADIUS) for authentication or accounting. Additionally, the authorization and accounting capabilities are more granular than in RADIUS (for example, allowing specific authorization of commands). This makes TACACS- the preferred protocol for authorization services for remote device administration. The TACACS- exchange requires several packets: * START, REPLY, and CONTINUE packets are used during the authentication process. * REQUEST and RESPONSE packets are used during the authorization and accounting process. The following is an example of an authentication exchange: 1. The access server sends a START authentication request. 2. The TACACS- server sends a REPLY to acknowledge the message and ask the access server to provide a username. 3. The access server sends a CONTINUE with the username. 4. The TACACS- server sends a REPLY to acknowledge the message and ask for the password. 5. The access server sends a CONTINUE with the password. 6. The TACACS- server sends a REPLY with authentication response (pass or fail). Figure 4-15 demonstrates the TACACS- authentication, authorization, and accounting exchange. TACACS- offers better security protection compared to RADIUS. For example, the full body of the packet can be encrypted. Table 4-4 summarizes the main differences between RADIUS and TACACS+. ## Diameter RADIUS and TACACS- were created with the aim of providing AAA services to network access via dial-up protocols or terminal access. Due to their success and flexibility, they have been used in several other scopes. To respond to newer access requirements and protocols, the IETF has proposed a new protocol called Diameter, which is described in RFC 6733. Diameter has been built with the following functionality in mind: * Failover: Diameter implements application-level acknowledgment and failover algorithms. * Transmission-level security: Diameter protects the exchange of messages by using TLS or DTLS. * Reliable transport: Diameter uses TCP or SCTP as the transport protocol. * Agent support: Diameter specifies the roles of different agents such as proxy, relay, redirect, and translation agents. * Server-initiated messages: Diameter makes mandatory the implementation of server-initiated messages. This enables capabilities such as on-demand re-authentication and re-authorization. * Transition support: Diameter allows compatibility with systems using RADIUS. * Capability negotiation: Diameter includes capability negotiations such as error handling as well as mandatory and nonmandatory attribute/value pairs (AVPs). * Peer discovery: Diameter enables dynamic peer discovery via DNS. The main reason for the introduction of the Diameter protocol is the capability to work with applications that enable protocol extension. The main Diameter application is called Diameter base and it implements the core of the Diameter protocol. Other applications are Mobile IPv4 Application, Network Access Server Application, Diameter Credit-Control Application, and so on. Each application specifies the content of the information exchange in Diameter packets. For example, to use Diameter as AAA protocol for network access, the Diameter peers will use the Diameter Base Application and the Diameter Network Access Server Application. The Diameter header field Application ID indicates the ID of the application. Each application, including the Diameter Base application, uses command code to identify specific application actions. Diameter is a peer-to-peer protocol, and entities in a Diameter context are called Diameter nodes. A Diameter node is defined as a host that implements the Diameter protocol. The protocol is based on two main messages: a REQUEST, which is identified by setting the R bit in the header, and an ANSWER, which is identified by unsetting the R bit. Each message will include a series of attribute/value pairs (AVPs) that include application-specific information. In its basic protocol flow, after the transport layer connection is created, the Diameter initiator peer sends a Capability-Exchange-Request (CER) to the other peer that will respond with a Capability-Exchange-Answer (CEA). The CER can include several AVPs, depending on the application that is requesting a connection. Once the capabilities are exchanged, the Diameter applications can start sending information. Diameter also implements a keep-alive mechanism by using a Device-Watchdog-Request (DWR), which needs to be acknowledged with a Device-Watchdog-Answer (DWA). The communication is terminated by using a Disconnect-Peer-Request (DPR) and Disconnect-Peer-Answer (DPA). Both the Device-Watchdog and Disconnect-Peer can be initiated by both parties. Figure 4-16 shows an example of a Diameter capability exchange and communication termination. The following is an example of protocol flows where Diameter is used to provide user authentication service for network access (as defined in the Network Access Server Application RFC 7155): 1. The initiator peer, the access server, sends a CER message with the Auth-Application-Id AVP set to 1, meaning that it supports authentication capabilities. 2. The Diameter server sends a CEA back to the access server with the Auth-Application-Id AVP set to 1. 3. The access server sends an AA-Request (AAR) to the Diameter server that includes information about the user authentication, such as username and password. 4. The access server will reply with an AA-Answer (AAA) message including the authentication results. Figure 4-17 shows an example of a Diameter exchange for network access services. ## 802.1X 802.1X is an IEEE standard that is used to implement port-based access control. In simple terms, an 802.1X access device will allow traffic on the port only after the device has been authenticated and authorized. In an 802.1X-enabled network, three main roles are defined: * Authentication server: An entity that provides an authentication service to an authenticator. The authentication server determines whether the supplicant is authorized to access the service. This is sometimes referred to as the policy decision point (PdP). The Cisco Identity Services Engine (ISE) is an example of an authentication server. You will learn more about Cisco ISE later in this chapter. * Supplicant: An entity that seeks to be authenticated by an authenticator. For example, this could be a client laptop connected to a switch port. Examples of a supplicant software is the Cisco Secure Client and the former Cisco AnyConnect Secure Mobility Client. * Authenticator: An entity that facilitates authentication of other entities attached to the same LAN. This is sometimes referred to as the policy enforcement point (PeP). Cisco switches, wireless routers, and access points are examples of authenticators. Other components, such as an identity database or a PKI infrastructure, may be required for a correct deployment. Figure 4-18 illustrates an example of an authentication server, supplicant, and authenticator. The supplicant is connected to the authenticator (wireless router) via a Wi-Fi connection. 802.1X uses the following protocols: * EAP over LAN (EAPOL): An encapsulation defined in 802.1X that's used to encapsulate EAP packets to be transmitted from the supplicant to the authenticator. * Extensible Authentication Protocol (EAP): An authentication protocol used between the supplicant and the authentication server to transmit authentication information. * RADIUS or Diameter: The AAA protocol used for communication between the authenticator and authentication server. The 802.1X port-based access control includes four phases (in this example, RADIUS is used as the protocol and a Cisco switch as the authenticator): 1. Session initiation: The session can be initiated either by the authenticator with an EAP-Request-Identity message or by the supplicant with an EAPOL-Start message. Before the supplicant is authenticated and the session authorized, only EAPOL, Cisco Discovery Protocol (CDP), and Spanning Tree Protocol (STP) traffic is allowed on the port from the authenticator. 2. Session authentication: The authenticator extracts the EAP message from the EAPOL frame and sends a RADIUS Access-Request to the authentication server, adding the EAP information in the AV pair of the RADIUS request. The authenticator and the supplicant will use EAP to agree on the authentication method (for example, EAP-TLS). Depending on the authentication method negotiated, the supplicant may provide a password, a certificate, a token, and so on. 3. Session authorization: If the authentication server can authenticate the supplicant, it will send a RADIUS Access-Accept to the authenticator that includes additional authorization information such as VLAN, downloadable access control list (dACL), and so on. The authenticator will send an EAP Success message to the supplicant, and the supplicant can start sending traffic. 4. Session accounting: This represents the exchange of accounting RADIUS packets between the authenticator and the authentication server. Figure 4-19 illustrates an example of the 802.1X exchange. In addition to these four phases, it is also very important that the session is correctly terminated. In the standard scenario, where the supplicant terminates the connection, it will send an EAPOL-Logoff message. ## Network Access Control List and Firewalling You learned that one of the most basic implementations of an access control is an ACL. When an ACL is applied to network traffic, it is called a network ACL. Cisco networking devices such as routers, switches, and firewalls include network ACL capabilities to control access to network resources. As for port-based access controls, network ACLs and firewalling are usually seen as special cases of the ABAC model and also sometimes classified as identity-based or rule-based access control because they base the control decision on attributes such as IP or MAC addresses or Layer 4 information. Security group ACLs, on the other hand, are access lists based on the role of the subject trying to access a resource, and they implement role-based access control. Network ACLs can be implemented at various levels of the OSI model: * A Layer 2 ACL operates at the data link layer and implements filters based on Layer 2 information. An example of this type of access list is a MAC access list, which uses information about the MAC address to create the filter. * A Layer 3 ACL operates at the networking layer. Cisco devices usually allow Layer 3 ACLs for different Layer 3 protocols, including the most used ones nowadays-IPv4 and IPv6. In addition to selecting the Layer 3 protocol, a Layer 3 ACL allows the configuration of filtering for a protocol using raw IP, such as OSPF or ESP. * A Layer 4 ACL operates at the transport layer. An example of a Layer 4 ACL is a TCP- or UDP-based ACL. Typically, a Layer 4 ACL includes the source and destination. This allows filtering of specific upper-layer packets. ## VLAN ACLS VLAN ACLs, also called VLAN maps, are not specifically Layer 2 ACLs; however, they are used to limit the traffic within a specific VLAN. A VLAN map can apply a MAC access list, a Layer 3 ACL, and a Layer 4 ACL to the inbound direction of a VLAN to provide access control. ## Security Group-Based ACL A security group-based ACL (SGACL) is an ACL that implements access control based on the security group assigned to a user (for example, based on his role within the organization) and the destination resources. SGACLs are implemented as part of