Protocols Using Authentication Mechanisms

Last Updated on Fri, 30 Jun 2023 | Network Security

Many protocols require authentication verification before providing authorization and access rights to the user or device. TACACS+, RADIUS, Kerberos, DCE, and FORTEZZA are examples of such protocols. TACACS+ and RADIUS are often used in dial-in environments to provide a scalable authentication database and can incorporate a variety of authentication methods. Kerberos is a protocol used in some campus environments to first verify that users and the network services they use are really who and what they claim to be before granting access privileges. For completeness, the Distributed Computing Environment (DCE) and FORTEZZA authentication mechanisms are included in this section, although their use is not widespread.

The TACACS+ Protocol

The TACACS+ protocol is the latest generation of TACACS. TACACS is a simple UDP-based access control protocol originally developed by BBN for the MILNET. Cisco has enhanced (extended) TACACS several times, and Cisco's implementation, based on the original TACACS, is referred to as XTACACS. The fundamental differences between TACACS, XTACACS, and TACACS+ are given here:

• TACACS: Combined authentication and authorization process

• XTACACS: Separated authentication, authorization, and accounting

• TACACS+: XTACACS with extended attribute control and accounting

TACACS+ uses TCP for its transport. The server daemon usually listens at port 49, the LOGIN port assigned for the TACACS protocol. This port is reserved in the assigned number's RFC for both UDP and TCP. Current TACACS and extended TACACS implementations also use port 49.

TACACS+ is a client/server protocol; the TACACS+ client is typically a NAS and the TACACS+ server is usually a daemon process running on some UNIX or NT machine. A fundamental design component of TACACS+ is the separation of authentication, authorization, and accounting.

TACACS+ Authentication

TACACS+ allows for arbitrary length and content authentication exchanges, which allows any authentication mechanism to be used with TACACS+ clients (including PPP PAP, PPP CHAP, PPP EAP, token cards, and Kerberos). Authentication is not mandatory; it is a site-configured option. Some sites do not require it at all; others require it only for certain services.

TACACS+ authentication has three packet types:

• START, which is always sent by the client

• CONTINUE, which is always sent by the client

• REPLY, which is always sent by the server

Authentication begins with the client sending a START message to the server. The START message describes the type of authentication to be performed (for example, simple cleartext password, PAP, or CHAP), and may contain the username and some authentication data. The START packet is sent only as the first message in a TACACS+ authentication session, or as the packet immediately following a restart. (A restart may be requested by the server in a REPLY packet.) A START packet always has s sequence number equal to 1.

In response to a START packet, the server sends a REPLY. The REPLY message indicates whether the authentication is finished, or whether it should continue. If the REPLY indicates that authentication should continue, the message also indicates what new information is requested. The client gets that information and returns it in a CONTINUE message. This process repeats until all authentication information is gathered, and the authentication process concludes.

TACACS+ Authorization

Authorization is the action of determining what a user is allowed to do. Generally, authen-tication precedes authorization, but, this is not required. An authorization request may indicate that the user is not authenticated (that is, we don't know who they are). In this case, it is up to the authorization agent to determine whether an unauthenticated user is allowed the services in question.

When authentication is completed (if authentication is used), the client can start the authorization process, if authorization is required. An authorization session is defined as a single pair of messages: a REQUEST followed by a RESPONSE. The authorization REQUEST message contains a fixed set of fields that describe the authenticity of the user or process, and a variable set of arguments that describes the services and options for which authorization is requested.

Note In TACACS+, authorization does not merely provide yes or no answers---it may also customize the service for the particular user. Here are some examples of when authorization would be performed: When a user first logs in and wants to start a shell; when a user starts PPP and wants to use IP over PPP with a particular IP address. The TACACS+ server daemon might respond to these requests by allowing the service, by placing a time restriction on the login shell, or by requiring IP access lists on the PPP connection.

TACACS+ Accounting

Security Technologies

Accounting is typically the third action after authentication and authorization. Accounting is the action of recording what a user is doing or has done. Accounting in TACACS+ can serve two purposes:

• It may be used to account for services used, such as in a billing environment.

• It may be used as an auditing tool for security services.

To this end, TACACS+ supports three types of accounting records:

• Start records indicate that a service is about to begin.

• Stop records indicate that a service has just terminated.

• Update records are intermediate notices that indicate that a service is still being performed.

TACACS+ accounting records contain all the information used in the authorization records and also contain accounting-specific information such as start and stop times (when appropriate) and resource usage information.

TACACS+ Transactions

Transactions between the TACACS+ client and TACACS+ server are authenticated through the use of a shared secret, which is never sent over the network. Typically, the secret is manually configured in both entities. TACACS+ encrypts all traffic between the TACACS+ client and the TACACS+ server daemon.

Figure 2-13 shows the interaction between a dial-in user and the TACACS+ client and server.

Related Posts

Readers' Questions

  • KAIJA UUSIPAIKKA
    What function does the tacacs protocol perform?
    1 month ago
    • The TACACS (Terminal Access Controller Access Control System) protocol performs the function of providing authentication, authorization, and accounting (AAA) services for network devices. Authentication: TACACS verifies the identity of users who are attempting to access a network device. It ensures that only authorized users can gain access. Authorization: TACACS determines the privileges and permissions granted to authenticated users. It controls what actions and commands a user can perform on the network device. Accounting: TACACS tracks and records the activities of authenticated users. It logs information such as login attempts, commands executed, and other network activities for auditing and billing purposes. Overall, the TACACS protocol enhances network security by controlling access to network devices, managing user permissions, and monitoring user activities.
    • Gerolamo
      Which of the following protocols or services is commonly used on cable internet?
      6 months ago
      • ? The most commonly used protocol for cable internet service is DOCSIS (Data Over Cable Service Interface Specification).
      • Bisrat
        Which of the following are authentication mechanisms for the application level?
        7 months ago
        1. Two-factor authentication
        2. Single sign-on
        3. Password validation
        4. OpenID Connect
        5. Kerberos authentication
        • luisa
          Which of the following protocols can be used to centralize remote access authentication?
          7 months ago
          • Kerberos
          • awet
            When using kerberos, what is the purpose of a ticket?
            7 months ago
            • A ticket is a data structure used in the Kerberos protocol to prove the identity of a user. The ticket is issued by the Kerberos server and allows the user to authenticate to other services on the same network, without requiring the user to enter their password again.
            • Peony
              Which of the following is not among the three types of authentication mechanisms?
              7 months ago
              • Biometric Identification
              • duenna
                Which of the following describes authentication?
                7 months ago
                • Authentication is the process of verifying an identity, typically through providing valid credentials such as a username and password. It is an important part of computer security and is used to verify the identity of a user before they are granted access to a secure system or system resources.
                • mai
                  Which of the following are required when implementing kerberos for authentication and authorization?
                  7 months ago
                  1. A Key Distribution Center (KDC)
                  2. A unique user identity
                  3. A trusted third-party authentication server
                  4. A database of authorized users and their associated privileges
                  5. A secure communication channel between the client and the KDC
                  • Libby
                    Which of the following protocols or mechanisms is not used to provide?
                    8 months ago
                    • Network Layer Security
                    • JOHAN
                      Which remote access authentication protocol periodically and transparently?
                      8 months ago
                      • Kerberos
                      • codey burns
                        What type of protocol is kerberos?
                        8 months ago
                        • Kerberos is an authentication protocol.
                        • ulla
                          Which of the following are used when implementing kerberos for authentication and authorization?
                          8 months ago
                          1. Client-Server Exchange.
                          2. Key Distribution Center (KDC).
                          3. Ticket-granting server (TGS).
                          4. Secure Authentication Service (AS).
                          5. Ticket Granting Ticket (TGT).
                          6. Encrypted Timestamps (TIMESTAMPS).
                          7. Kerberos Database (KDB).
                          • jill
                            How does tacacs work?
                            8 months ago
                            • TACACS (Terminal Access Controller Access Control System) is a remote authentication protocol that is used to communicate with an authentication server commonly used in UNIX networks. It is used to control access to network resources. When users attempt to access a network resource, the authentication server will prompt them for their username and password. The authentication server will then verify the user's credentials against its database and will either allow or deny access to the requested network resource. If access is granted, the user is then allowed to use the requested resource. TACACS also provides an additional layer of security by using encryption to protect the data sent and received by the authentication server. This prevents malicious individuals from intercepting and intercepting passwords or other sensitive data. TACACS is a secure protocol and is commonly used in enterprise-level networks for user authentication.
                            • giuditta
                              Which two features are included by both tacacs and radius protocols (choose two.)?
                              8 months ago
                              1. Authentication
                              2. Authorization
                              • calvin
                                Does TACACS use tickets?
                                1 year ago
                                • No, TACACS (Terminal Access Controller Access Control System) does not use tickets. TACACS is an authentication protocol used to authenticate, authorize and log users’ access to a network and its associated resources.

                                Figure 2-13: A TACACS+ Exchange

                                The Remote Address Dial-In User Service (RADIUS) protocol was developed by Livingston Enterprises, Inc., as an access server authentication and accounting protocol. In June 1996, the RADIUS protocol specification was submitted to the IETF. The RADIUS specification (RFC 2058) and RADIUS accounting standard (RFC 2059) are now proposed standard protocols.

                                RADIUS uses UDP as its transport. Generally, the RADIUS protocol is considered to be a connectionless service. Issues related to server availability, retransmission, and timeouts are handled by the RADIUS-enabled devices rather than by the transmission protocol.

                                RADIUS is a client/server protocol. The RADIUS client is typically a NAS; the RADIUS server is usually a daemon process running on some UNIX or NT machine. The client is responsible for passing user information to designated RADIUS servers and then acting on the response that is returned. RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver the service to the user. A

                                RADIUS server can act as a proxy client to other RADIUS servers or to other kinds of authentication servers.

                                RADIUS Authentication

                                The RADIUS server can support a variety of methods to authenticate a user. When the server is provided with the user name and original password given by the user, the server can support PPP PAP or CHAP, UNIX login, and other authentication mechanisms. What is supported depends on what a vendor has implemented.

                                Typically, a user login consists of a query (Access-Request) from the NAS to the RADIUS server and a corresponding response (Access-Accept or Access-Reject) from the server. The Access-Request packet contains the username, encrypted password, NAS IP address, and port. The format of the request also provides information about the type of session the user wants to initiate.

                                When the RADIUS server receives the Access-Request packet from the NAS, it searches a database for the username listed. If the username does not exist in the database, either a default profile is loaded or the RADIUS server immediately sends an Access-Reject message. This Access-Reject message can be accompanied by an optional text message, which can indicate the reason for the refusal.

                                RADIUS Authorization

                                In RADIUS, the authentication and authorization functionalities are coupled together. If the username is found and the password is correct, the RADIUS server returns an Access-Accept response, including a list of attribute-value pairs that describe the parameters to be used for this session. Typical parameters include service type (shell or framed), protocol type, IP address to assign the user (static or dynamic), access list to apply, or a static route to install in the NAS routing table. The configuration information in the RADIUS server defines what will be installed on the NAS.

                                RADIUS Accounting

                                The accounting features of the RADIUS protocol can be used independently of RADIUS authentication or authorization. The RADIUS accounting functions allow data to be sent at the start and end of sessions, indicating the amount of resources (such as time, packets, bytes, and so on) used during the session. An Internet service provider (ISP) might use RADIUS access control and accounting software to meet special security and billing needs.

                                RADIUS Transactions

                                Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server to eliminate the possibility that someone snooping on an unsecure network could determine a user's password.

                                Figure 2-14 shows the RADIUS login and authentication process.

                                Figure 2-14: RADIUS Login and Authentication

                                NOTE With both TACACS+ and RADIUS, it is important to remember that encryption is performed between the TACACS+/RADIUS client and the TACACS+/RADIUS server. If the TACACS+/RADIUS client is a NAS and not the client PC, any communication between the PC and the NAS is not encrypted (see Figure 2-15).

                                Figure 2-15: TACACS+/RADIUS Encryption

                                Kerberos is a secret-key network authentication protocol, developed at Massachusetts Institute of Technology (MIT), that uses the Data Encryption Standard (DES) cryptographic algorithm for encryption and authentication. The Kerberos Version 5 protocol is an Internet standard specified by RFC 1510.

                                Kerberos was designed to authenticate user requests for network resources. Kerberos is based on the concept of a trusted third party that performs secure verification of users and services. In the Kerberos protocol, this trusted third party is called the key distribution center (KDC), sometimes also called the authentication server. The primary use of Kerberos is to verify that users and the network services they use are really who and what they claim to be. To accomplish this, a trusted Kerberos server issues "tickets" to users. These tickets have a limited lifespan and are stored in the user's credential cache. They can later be used in place of the standard username-and-password authentication mechanism.

                                Kerberos Authentication Request and Reply

                                Initially, the Kerberos client has knowledge of an encryption key known only to the user and the KDC, Kclient. Similarly, each application server shares an encryption key with the KDC, Kserver (see Figure

                                Figure 2-16: Kerberos Keys

                                When the client wants to create an association with a particular application server, the client uses the authentication request and response to first obtain a ticket and a session key from the KDC (see Figure 2-17).

                                Figure 2-17: Kerberos Authentication Request and Reply

                                The steps are as follows:

                                Step 1 The client sends an authentication request to the KDC. This request contains the following information:

                                • Its claimed identity

                                • The name of the application server

                                • A requested expiration time for the ticket

                                • A random number that will be used to match the authentication response with the request

                                Step 2 The KDC verifies the client access rights and creates an authentication response.

                                Step 3 The KDC returns the response to the client. The authentication response contains the following information:

                                o The session key, Ksession

                                o The assigned expiration time o The random number from the request o The name of the application server o Other information from the ticket

                                This information is all encrypted with the user's password, which was registered with the authentication server, Kclient. The KDC also returns a Kerberos ticket containing the random session key, Ksession, that will be used for authentication of the client to the application server; the name of the client to whom the session key was issued; and an expiration time after which the session key is no longer valid. The Kerberos ticket is encrypted using Kserver.

                                Step 4 When the client receives the authentication reply, it prompts the user for the password. This

                                Security Technologies password, Kdient, is used to decrypt the session key, Ksession. Now the client is ready to communicate with the application server.

                                Note Kclient is used as the bootstrap mechanism, but in subsequent communication between the KDC and the client, a short-term client key, Kclient-session, is used. Kclient-session is created by having the KDC

                                convert the user's password to the short-term client key. The KDC sends the short-term client key, Kclient-session, encrypted with the user's password, to the client. The user decrypts the short-term client key and subsequent KDC to client communication use

                                Kerberos Application Request and Response

                                The application request and response is the exchange in which a client proves to an application server that it knows the session key embedded in a Kerberos ticket. The exchange is shown in Figure 2-18.

                                Figure 2-18: Kerberos Application Request and Reply

                                The steps in the application request and response are as follows:

                                Step 1 The client sends two things to the application server as part of the application request:

                                • The Kerberos ticket (described earlier)

                                • An authenticator, which includes the following (among other fields):

                                • The current time

                                • An optional encryption key

                                These elements are all encrypted with the session key, Ksession, from the accompanying ticket.

                                Step 2 After receiving the application request, the application server decrypts the ticket with Kserver, extracts the session key, Ksession, and uses the session key to decrypt the authenticator.

                                If the same key was used to encrypt the authenticator as was used to decrypt it, the checksum will match, and the verifier can assume that the authenticator was generated by the client named in the ticket and to whom the session key was issued. By itself, this check is not sufficient for authentication because an attacker can intercept an authenticator and replay it later to impersonate the user. For this reason, the verifier also checks the timestamp. If the timestamp is within a specified window (typically 5 minutes), centered around the current time on the verifier, and if the timestamp has not been seen on other requests within that window, the verifier accepts the request as authentic.

                                At this point, the identity of the client has been verified by the server. For some applications, the client also wants to be sure of the server's identity. If such mutual authentication is required, a third step is required.

                                Step 3 The application server generates an application response by extracting the client's time from the authenticator and returns it to the client together with other information, all encrypted using the session

                                Reuse of Credentials

                                The basic Kerberos authentication protocol allows a client with knowledge of the user's password to obtain a ticket and session key and to prove its identity to any verifier (usually an application server) registered with the KDC. The user's password must be presented each time the user performs authentication with a new verifier. A system should support single sign-on, where the user logs in to the system once and provides the password at that time; subsequent authentication occurs automatically.

                                The obvious way to cache the user's password on the workstation is dangerous. Although a Kerberos ticket and the key associated with it are valid for only a short time, an intruder knowing the user's password can obtain valid tickets and impersonate the user until the password is changed. This is why the short-term client key, Kclient-session, is used in place of the user's actual password in all but the initial bootstrap communication. The Kerberos approach is to cache only tickets and encryption keys (collectively called credentials) that will work for a limited time period.

                                The ticket-granting exchange of the Kerberos protocol allows a user to obtain tickets and encryption keys using such short-lived credentials, without reentering the user's password. When the user first logs in, an authentication request is issued, and a ticket and the client session key for the ticket-granting service is returned by the KDC. This ticket, called a ticket-granting ticket(TGT), has a relatively short life (typically on the order of 8 hours). The response is decrypted, the ticket and session key are saved, and the user's password is forgotten. Subsequently, when the user wants to prove its identity to a new verifier, a new ticket is requested from the KDC using the ticket-granting exchange.

                                Note The ticket-granting exchange is identical to the authentication exchange except that the ticket-granting request has embedded within it an application request (authenticating the client to the authentication server), and the ticket-granting response is encrypted using the client session key from the ticket-granting ticket rather than from the user's password.

                                Practical Considerations

                                Multiple realms, or domains, are supported in Kerberos to allow for scalable implementations. Assume that a corporation has implemented a Kerberos system with two separate realms, Italy and Hungary. When a client in Italy's realm connects to a server in Hungary's realm, Italy's KDC authenticates the client to Hungary's KDC. Hungary's KDC authenticates the client to Hungary's server. Multi-KDC chaining is not allowed, and trust for KDC chaining should go back only one level.

                                Several utility programs must be installed on the workstation to allow users to obtain Kerberos credentials (kinit), destroy credentials (kdestroy), list credentials (klist), and change their Kerberos passwords (kpasswd). Some sites choose to integrate the Kerberos login tool kinit with the workstation

                                Security Technologies login program so that users do not have to type their password twice. This makes the use of Kerberos nearly transparent; users may not even be aware they are using Kerberos.

                                Note Client/server applications must be modified to use Kerberos for authentication; such Kerberos-aware applications are said to be Kerberized.

                                You should also consider using some method of accurate time in all systems because Kerberos has a time-dependency issue through the use of timestamps. A synchronized, dependable mechanism of obtaining time is needed; most likely, the use of NTP is warranted.

                                The Distributed Computing Environment

                                The Distributed Computing Environment (DCE) is a set of functional specifications from the Open Software Foundation (OSF, found at http://www.opengroup.org/). DCE is a set of distributed computing technologies that provide security services to protect and control access to data; name services that make it easy to find distributed resources; and a highly scalable model for organizing widely scattered users, services, and data.

                                DCE has a modular design and supports authentication and authorization. The implemented authentication part is Kerberos Version 5 (although, in theory, another mechanism can be substituted). The authorization part works in a manner similar to Kerberos but is implemented by privilege servers and registration servers. In practice, these are usually delivered with the KDC. The registration server ties the KDC with the user's privileges, which are found in the privilege server. The privilege server combines the universal unique ID (UUID) and the groups into a Kerberos ticket for secure transmission. Kerberos uses usernames (which may not always be consistent or unique across the enterprise). DCE uses the UUIDs, which are 128 bits long. On most systems, the user ID (UID) and group ID (GID) fields are 32 bits each.

                                In practice, a user can authenticate from any workstation with a username and password. The TGT is issued by the KDC. The workstation then uses that session key to form a session to the privilege server. The UUID and access control list (ACL) information is then passed to the workstation through a privilege ticket-granting ticket (PTGT) from the privilege server. The session key encrypted in the PTGT is used. The UUID and the group information are then used as the authorization information to allow or disallow access to services and resources.

                                Note The DCE effort has not produced the groundswell effect its supporters hoped for. Today, some organizations have embraced it, but it is manpower intensive to support (as is Kerberos) because it is fairly complex and relies on several other DCE services being implemented. Therefore, it is not found in use very often.

                                Continue reading here: The Fortezza

                                Was this article helpful?

                                0 0