MODULE 13
Authentication Methods and Services
From Modules 3 and 11, you now understand what authentication is and why it’s a distinct process in the overall process of identification, authentication, and authorization. In this module we will focus on authentication methods and services, and we’ll describe their role in the process used to get authorized users the right access to systems and data. We will look at various protocols and techniques used to authenticate both local (within the network) and remote (outside the network boundaries) users, and how these fit into the overall authentication process.
Authentication Concepts
In Module 11 we defined authentication as the process of validating user credentials, usually against a centralized database. We also discussed various methods of identification and authentication, including single and multifactor authentication, as well as tokens and personal identity verification cards, such as smart cards and common access cards used in various private and governmental areas. That said, authentication uses various protocols and techniques to verify user credentials both internal and external to hosts and networks. Some of these are specifically designed for remote access, while others are designed to authenticate users to a Windows host or Active Directory domain. In the next few sections, we’ll discuss authentication principles and methods, including the use of single sign-on technologies and one-time passwords. We’ll also discuss various authentication services and protocols, to include RADIUS, TACACS+, Kerberos, and others you’ll need to know for the exam.
Authentication Protocols and Methods
Several concepts and methods are particular to authentication, and you should know about them for the exam and for real life. Some of these include the use of single sign-on technologies, one-time passwords, and various authentication protocols you may encounter. In the next few sections, we’ll look at some of these protocols and methods, which can be used either to connect remotely to the network from the outside or to authenticate internally to a network. Later, we’ll look at specific remote access protocols that provide authentication and connection services.
Single Sign-On
We briefly mentioned the term “single sign-on” back in Module 11; here we will discuss it in more depth. As you may recall, single sign-on refers to the ability to use the same set of credentials throughout an enterprise. This is actually more complicated than it sounds; it requires that the infrastructure have interoperable technologies as well as centralized account management and authentication throughout the enterprise. There are a couple of technologies that you will hear about in relation to single sign-on—the older Sesame protocol and the Kerberos protocol—which we’ll discuss a bit later in this module.
Single sign-on has many advantages, particularly in a federated (multi-organizational and security domain) structure. First, single sign-on enables you to access resources throughout the enterprise, without requiring an additional set of credentials. As you may also recall from Module 11, this involves centralized security policies, account management, and resource permissions. This is different from a decentralized model, where each resource or system requires its own distinct set of credentials. Using a single sign-on process, users have to remember and maintain only one set of credentials. These credentials, whenever they are changed, replicate across the entire enterprise, so the changes don’t have be manually applied to individual resources. This is definitely not true in a decentralized model, where changing credentials on one resource or system may require that you change them manually across the board in other areas. This prevents credentials from being synchronized throughout the network. An Active Directory environment is a good example of how single sign-on is used throughout an enterprise.
Single sign-on may also have certain disadvantages as well; in highly secure environments, where resources need to be kept logically and physically separated, there may be a need for a different set of credentials, based upon the sensitivity of systems and data in question. Often, users may have single sign-on capability throughout the organization for non-sensitive systems, but more sensitive systems requiring controlled access may require an additional set of credentials, and single sign-on may not provide the security that these resources require. A reduced sign-on environment may be more appropriate in situations where single sign-on is not practical for security reasons.
Single sign-on is implemented in Windows environments using the Kerberos authentication protocol.
SAML
The Security Assertion Markup Language (SAML) is a standardized method of transferring information about authenticating users to an authentication service. SAML enables different, but interoperable, authentication technologies to work with each other by providing a standardized format for passing authentication information between services. This XML-based standard can pass both identification and authorization information. SAML uses three types of information: the principal (the authenticating user), the identity provider, and the service provider. The identity provider is the entity authenticating the user, and the service provider is the entity who must accept the authentication information and in turn provide access to a resource. The most common example of SAML is its use by web-based single sign-on technologies, which use a web browser and a centralized authentication server. Typically, SAML is seen on internal networks, providing web-based authentication services to internal network clients.
SAML is an open standard that uses XML as its markup language format. It’s usually seen in web-based applications.
One-Time Passwords
A one-time password (OTP) is generated and used only once, and it is never repeated again. Usually, one-time passwords are generated for secure communication sessions, and these will be generated by the system. An example of a one-time password is that provided by a token that is used in conjunction with another factor, such as a PIN or regular password, to provide better security in a multifactor environment. Another example of a one-time password use is during a secure communications session, where the secure protocols generate a session key that is used only during that particular session. The session key could be considered a one-time password.
A time-based one-time password (TOTP) uses time as a factor to assist in generating the OTP. In our example regarding the token, the TOTP changes very often, sometimes after only a few seconds. Therefore, it must keep its time synchronization exactly with the authentication database. If the user is even 1 or 2 seconds off from using the correct TOTP displayed on the token, authentication fails. Normally, the user has a set number of seconds to input the correct password before it changes and another one must be used. This has many advantages, including the prevention of replay attacks. Another advantage is that it can be very difficult to predict TOTPs, based upon the time factor that is input into the algorithm used to create them. So this can make it very difficult for an attacker to guess what TOTPs might be used. Tokens are not the only devices that can use TOTPs. A great example of how you might use them in the personal world is demonstrated by how Google, using strong authentication practices, may send a TOTP to a personal device, such as a smartphone, that you would be required to have in your possession during authentication. Your Google account may require you to input this TOTP within a certain amount of time, and after you receive a text message with the TOTP, you would input this password, usually a set of digits, into the corresponding field on the screen. You would then be authenticated and allowed to access your Google account.
Understand the different instances of when a one-time password is used; they are typically generated by tokens or mobile devices to facilitate multifactor authentication.
One algorithm used to generate OTPs is the HMAC-based One-Time Password (HOTP) algorithm. If you recall from Module 8, the HMAC (Hash-based Message Authentication Code) is a method used to provide for message authentication and data integrity. HMAC can use either MD5 or the SHA series of hashing algorithms and various key sizes. In the case of HOTP use, the user is authenticated against the centralized authentication database, and the HMAC value is calculated by the authentication server and sent to the user via an authentication device such as a token. Several popular authentication mechanisms that use mobile devices, such as smartphones, make use of HOTP, and it has also become an Internet standard (RFC 4226).
PAP
The Password Authentication Protocol (PAP) is an older type of protocol used to pass usernames and passwords to a central authentication server. PAP was usually seen with older dial-up remote connection methods, which use the Point-to-Point Protocol (PPP). Unfortunately, PAP does not pass usernames and passwords securely during authentication by default; this information is generally sent over the network in clear text, making it easily intercepted by someone using a network sniffer.
PAP is an older protocol that is not secure and has been deprecated. You should always use an authentication protocol that hashes or encrypts user credentials that travel across a network connection.
CHAP
The Challenge-Handshake Authentication Protocol (CHAP) is an Internet standard method (described in RFC 1994) of authenticating users or a host to a centralized authentication server. CHAP is an older protocol that replaced sending username and password information over clear text, as non-secure implementations of PAP did. CHAP was primarily used over PPP connections, and it was the first of several different versions of challenge-response authentication protocols. In CHAP, the authentication server sends a challenge message to the user or host. The user inputs his password, and the system hashes the combination of the password and challenge together, using a one-way hash function. The host then sends this hashed response back to the authentication server. The authentication server, which knows the user’s password, repeats the hashing process with the password and challenge, and produces its own hash value. If the hash values match, then the authentication server knows that the user input the correct password and the user can be authenticated. If the hash values do not match, authentication fails. Figure 13-1 illustrates how this process works.
Figure 13-1 The CHAP authentication process
CHAP periodically reauthenticates clients during a session; this process uses a three-way handshake. CHAP can prevent replay attacks and also enables the user to authenticate without directly sending his password over non-secure network connections. Microsoft developed its own version of the CHAP protocol, MS-CHAP, and later MS-CHAP v2, which was used in earlier versions of Microsoft Windows. It is been all but deprecated on all recent versions of Windows in favor of more secure authentication mechanisms such as Kerberos.
CHAP relies on challenge-responses and hashes passwords, as do other modern protocols. This ensures that passwords or other user credentials are never sent over the network in clear text.
LANMAN, NTLM, and NTLMv2
Microsoft developed a series of proprietary authentication protocols early on during Windows development, and for the most part, they have been deprecated and are no longer included in new versions of the Windows operating system. However, you should be aware of them for the exam, and you may actually run into some of these from time to time in your professional career. The first of these protocols that we’ll discuss is the LAN Manager (LANMAN) protocol, which was developed and included in Microsoft Windows NT. While it does hash passwords in Windows, these hashes are easily broken if they are obtained by an attacker. LANMAN was disabled by default starting in Windows Vista and shouldn’t be used unless you’re running legacy clients that require it.
NT LAN Manager (NTLM) was created by Microsoft to replace LANMAN and is in fact backward-compatible with it. It’s also a very non-secure protocol, and it was quickly replaced by NTLM version 2 (v2). Both versions are challenge-response authentication protocols and work similarly to CHAP. Version 2 is actually still carried forward into modern iterations of Windows, but it has been largely deprecated as well. Kerberos is now the default authentication protocol that comes with Windows, but there are still times when NTLM v2 is used, even in modern iterations of Windows. These instances include authenticating to a server using only an IP address, authenticating to a different Active Directory (AD) forest that has a legacy trust enabled, authenticating a host to a non-Active Directory domain, or authenticating when no AD domain exists. In these instances, Windows will default to using NTLM v2.
Understand the situations when Windows will default to using NTLM v2 instead of Kerberos for its authentication protocol. Usually this occurs in situations where there is no AD environment and the host is communicating in a workgroup setup.
Kerberos
Kerberos is a network authentication protocol that is prominently used in Active Directory implementations. It began as a project of the Massachusetts Institute of Technology (MIT) and has been implemented as a centralized, single sign-on authentication mechanism. It is an open standard, supported officially as an Internet standard by RFC 4120. As of this writing, the most current version of Kerberos widely in use is version 5.
Kerberos uses a system based on authentication tickets and timestamps that are issued out to the authenticated user. Timestamps help prevent replay attacks because the tickets expire after a short time and must be refreshed, requiring that the user be reauthenticated and the ticket reissued. Kerberos’s timestamps rely heavily on authoritative time sources throughout the network architecture, so many implementations also provide for a network time server. If clients are outside a certain tolerance for time difference with the Kerberos server, the users logging into those clients will not be authenticated. The default tolerance for time differences is 5 minutes in an Active Directory network, although this can be changed.
Kerberos uses several components, which you should be familiar with for the exam. First is the Kerberos Key Distribution Center (KDC), which is responsible for authenticating users and issuing out session keys and tickets. In Active Directory implementations, the domain controller serves as the KDC. There is also an Authentication Service (AS) and a Ticket-Granting Service (TGS). Although they are not required to be on the same host, these services frequently are, for simplicity and efficiency’s sake, on AD domain controllers in a Windows environment and are part of the KDC implementation.
When a user logs into the system, the AS verifies her identity using the credentials stored in AD. The user is then issued a Ticket-Granting Ticket (TGT) by the AS, which can be used to access resources throughout the domain. The TGT expires after a certain amount of time, so it must be periodically reissued. When a user wants to access a resource in the domain, the TGT is presented to the TGS for authentication and the TGS generates a session key for the communications session between the user and the resource server. This is known as a service ticket and is used for the duration of the access to the resource. When a user later needs access to the same or a different resource, the older ticket is not reused and a new service ticket is generated.
Note that the process we’ve described is specific to Windows AD implementations of Kerberos, but the principles are the same regardless of what operating system and LDAP-based implementation is in use. A network that uses Kerberos as its authentication protocol is called a Kerberos realm. Kerberos uses both TCP and UDP ports 88, and it uses symmetric key cryptography. Figure 13-2 illustrates the Kerberos process in Windows AD.
Figure 13-2 Kerberos process in Windows environments
LDAP and Secure LDAP
The Lightweight Directory Access Protocol (LDAP) isn’t an authentication protocol; it’s used to assist in allowing authenticated users to browse and locate objects in a distributed network database. It’s also used to facilitate authentication and authorization for these objects. LDAP is a modern replacement for older X.500 directory services protocols. Although the most popular iteration of LDAP (its current version is version 3) can be found in AD, other platforms use LDAP as well, including the popular OpenLDAP. LDAP uses both TCP and UDP ports 389. There is a secure version of LDAP that uses TCP port 636. It’s primarily LDAP over SSL, and it has been deprecated with LDAP version 2.
Keep in mind that LDAP is not an authentication protocol, but it does facilitate authentication and resource access.
Remote Access Connection and Authentication Services
In the next several sections, we will look at various remote authentication services and protocols that provide the ability to authenticate external authorized users and hosts into an internal network. These methods are normally used for older dial-up and Integrated Services Digital Network (ISDN) connections, but we’ll also look at the two primary tunneling protocols that can provide remote access services for Virtual Private Network (VPN) connections—the subject of later modules, so we won’t go much in depth here.
One aspect of authentication that you might want to be aware of before diving into some of these protocols and services is the concept of authentication, authorization, and accounting, known as AAA. Although you already know the definitions of authentication and authorization, when used in this context, they all relate to functions performed by authentication services, particularly remote authentication services. In this context, authentication and authorization mean the same thing, although there might be intermediary devices that provide certain related services rather than having a host authenticate directly with a centralized authentication server or database. The accounting function, when used in the context of remote access, describes the process of accounting for connection time and billing functions, another throwback to the older days of dial-up, when users paid for their connection to an ISP by the minute or hour. These days, users typically connect via a broadband method that is “always on,” such as DSL or cable modem. Although users are still charged for their service, it’s typically on a flat-rate basis and not by the minute or hour. Still, the accounting function of remote access takes care of this particular aspect of the connection, including time of connection, the traffic that was used over the connection, and which hosts connected at which times to make use of the connection.
RADIUS
The Remote Authentication Dial-In User Service (RADIUS) protocol was originally developed to provide for remote connections through older dial-in services. RADIUS provides AAA services to clients and providers. It is a standardized Internet specification and falls under several different RFCs, including RFC 2058, RFC 2059, and others. A basic client/server protocol, RADIUS uses User Datagram Protocol (UDP) as its transport protocol on ports 1812 (for authentication and authorization) and 1813 (for accounting functions).
RADIUS has a few interesting terms you need to be aware of. A RADIUS client is not the host attempting to connect; it is the network access server itself, which remote hosts connect to. This server is an intermediary that processes the connection request and passes it onto other servers, called RADIUS servers, which provide authentication services and can be either Windows or UNIX-based servers. Active Directory, in fact, can provide for authentication services to RADIUS clients, acting as a RADIUS server, through the Microsoft remote access and VPN services. In terms of security, though, RADIUS is a bit lacking. Although the communications between the RADIUS client and the RADIUS server are encrypted, communications between the RADIUS client and the remote host are not. Unfortunately, username and password information could be intercepted between the remote host and the RADIUS client. RADIUS can support a variety of authentication methods, including some of the older ones, including PPP, PAP, and CHAP.
A RADIUS client is the network server that receives the connection request from the remote host and communicates with the RADIUS server. It is not the remote host itself.
Diameter
Diameter is an AAA protocol proposed to replace RADIUS. Its name is actually a pun and doesn’t really stand for anything. It makes sport of the fact that the diameter of a circle is twice the radius. It allows for a wider variety of authentication protocols that will use it, including the Extensible Authentication Protocol (EAP). It uses TCP port 3868 instead of the UDP that RADIUS uses. It also allows for more advanced security using IPsec and Transport Layer Security (TLS).
TACACS, XTACACS, and TACACS+
The Terminal Access Controller Access Control System (TACACS) supplanted RADIUS and allows a remote user to connect and authenticate to a network via an intermediary TACACS server. It works pretty much the same way as RADIUS, with a few exceptions. XTACACS, which stands for Extended TACACS, provides additional functionality for the TACACS protocol. It also separates the authentication, authorization, and accounting functions out into separate processes, even allowing them to be handled by separate servers and technologies. TACACS+ was a Cisco-proprietary version of the older TACACS protocol that enabled newer, more secure authentication protocols to be used over it, such as Kerberos and EAP. It also permitted two-factor authentication. It later became an open standard. Unlike the issues that plague RADIUS with encryption between the remote host and the RADIUS client, TACACS+ encrypts all traffic between all connection points, to include usernames and passwords. Unfortunately, TACACS+ is not backward-compatible with the earlier versions of the protocol. TACACS uses TCP port 49 by default.
L2TP and PPTP
Two protocols stand out as remote connection protocols designed to carry traffic over an existing network, encapsulating the traffic within them. Although you can use both protocols to connect remotely via dial-in or older connection technologies, both are primarily used to connect to clients using an intermediary network, such as the Internet, to provide the transport capabilities between remote host and the destination network. The Point-to-Point Tunneling Protocol (PPTP) was developed by Microsoft to include VPN connection technologies within Microsoft operating systems. PPTP enables a client to send data in it, much as you would a letter in an envelope. The PPTP packet contains the destination IP address of the network you are attempting to connect to. Inside this PPTP envelope is the traffic that will pass through the external VPN connection device intended for the destination network. This traffic would not be secure using PPTP alone; Microsoft uses its proprietary Microsoft Point-to-Point Encryption (MPPE) protocol to secure traffic traveling over PPTP. PPTP uses TCP port 1723. It’s actually rarely seen over VPN connections these days, as most modern VPNs use some form of L2TP, described next.
Layer 2 Tunneling Protocol (L2TP) was developed jointly by Microsoft and Cisco, but it has become an Internet standard. Microsoft contributed aspects of its PPTP, while Cisco used its proprietary Layer 2 Forwarding (L2F) protocol. Like PPTP, L2TP is only an encapsulation protocol, simply providing transport services and protecting data through untrusted networks (such as the Internet) to get it to a destination network. It doesn’t provide any security services by itself; it uses IPsec to provide authentication and encryption services for the traffic it contains. We will discuss VPNs that use L2TP and IPsec more in-depth in Modules 17 and 20. L2TP uses UDP port 1701. Figure 13-3 shows how IPsec-encrypted packets are encapsulated in L2TP frames.
Figure 13-3 Encapsulating IPsec into L2TP
Understand that neither L2TP nor PPTP is responsible for securing its traffic payloads using encryption or authentication services. Both are only encapsulating protocols that do the heavy lifting of carrying traffic destined for secure networks through untrusted networks, like the Internet. For security services, L2TP and PPTP rely on other protocols, such as IPsec and MPPE, respectively.
Module 13 Questions and Answers
Questions
1. Which of the following allows a user to use one set of credentials throughout an enterprise?
A. TACACS
B. RADIUS
C. Single Sign-on
D. TACACS+
2. Which of the following would use a SHA-2 algorithm to generate a password that is used for only one session?
A. Kerberos Authentication Service
B. HOTP
C. TOTP
D. Kerberos Ticket-Granting Service
3. Which of the following authentication protocols sends user and password information in clear text?
A. PAP
B. CHAP
C. MS-CHAP v2
D. MS-CHAP
4. Which of the following authentication protocols was the first of its kind to offer challenge-response mechanisms for protecting user credentials sent over a network?
A. PPP
B. Kerberos
C. PAP
D. CHAP
5. Under which of the following circumstances would a Windows host use Kerberos instead of NTLM v2 to authenticate users?
A. Authenticating to a server using only an IP address
B. Authenticating to a modern Windows Active Directory domain
C. Authenticating to a different Active Directory forest with legacy trusts enabled
D. Authenticating to a server in a Windows workgroup
6. Which of the following issues a service ticket to a user in a Kerberos realm?
A. Authentication Service
B. Server Service
C. Ticket-Granting Service
D. Key Distribution Center
7. Which of the following remote authentication protocols uses UDP ports 1812 and 1813?
A. L2TP
B. TACACS+
C. TACACS
D. RADIUS
8. All of the following are characteristics of the RADIUS authentication protocol, except:
A. It encrypts data between the RADIUS client and the remote host.
B. It uses UDP port 1812 for authentication and authorization.
C. It supports both PAP and CHAP.
D. The RADIUS client is the network access server that requests authentication information from the RADIUS server.
9. Which of the following remote authentication protocols can use both Kerberos and EAP, as well as multifactor authentication?
A. RADIUS
B. TACACS+
C. TACACS
D. PPTP
10. Which of the following are characteristics of the Point-to-Point Tunneling Protocol (PPTP)? (Choose two.)
A. Uses TCP port 1723
B. Uses TCP port 1701
C. Uses MPPE as its encryption protocol
D. Uses IPsec as its encryption protocol
Answers
1. C. Single sign-on allows a user to use one set of credentials throughout an enterprise to access various resources without having to reauthenticate with a different set of credentials.
2. B. The HMAC-based One-Time Password (HOTP) algorithm uses hashing algorithms, such as SHA, to generate one-time passwords.
3. A. The Password Authentication Protocol (PAP) sends user and password information in clear text and should not be used.
4. D. The Challenge Handshake Authentication Protocol (CHAP) was the first authentication protocol designed to offer challenge-response mechanisms for protecting user credentials sent over a network.
5. B. When authenticating to a modern Windows Active Directory domain, Windows uses Kerberos as its authentication protocol by default.
6. C. The Ticket-Granting Service issues a service ticket to a user in a Kerberos realm.
7. D. RADIUS uses UDP ports 1812 and 1813.
8. A. RADIUS does not encrypt data between the RADIUS client and the remote host.
9. B. TACACS+ supports both Kerberos and EAP, as well as multifactor authentication.
10. A, C. PPTP uses TCP port 1723 as well as MPPE for its security protocol and encryption mechanism.