Open authentication can be used in combination with which one of the following

Digest Authentication

Digest authentication is another authentication type specified in HTTP 1.1. Unlike basic authentication, digest authentication does not require the password to be transmitted. Rather, the client takes the username and password and uses the MD5 hashing algorithm to create a hash, which is then sent to the SQL Server.

If you are not familiar with hashing algorithms, they are one-way functions when you put in a stream of values (such as the username and password), and you get a stream of characters as a result. If the hashing algorithm is “reasonable secure,” there is no way to take the output stream of characters from a hashing algorithm and get back to original stream. As a result, most of the research on hashing algorithms revolve around finding techniques to generate collisions. A collision is when two different input streams produce the exact same output stream. For instance, if “dog” and “cat” both produced “boy” when going through a hashing algorithm, we’d have a collision. Unfortunately, recent research against MD5 has found mechanisms for generating collisions rather quickly.

With respect to SQL Server 2005, digest authentication requires two key elements to work. First, the username must be a valid Windows domain login. A local Windows account on the server will not work. Neither will a SQL Server login. Second, the domain controllers for the domain must be at least Windows Server 2003. Windows 2000 domain controllers do not support digest authentication. There is a workaround to make digest authentication work with IIS 5.0, but it requires all user account passwords to be stored in a format where the encryption can easily be reversed (and the password revealed). This insecure method of supporting digest authentication is not utilized by SQL Server 2005. Therefore, if you have SQL Servers on a Windows 2000 domain, you likely won’t be able to use digest authentication.

NTLM Authentication

NTLM stands for NT LAN Manager; it’s the traditional authentication protocol for Windows NT-based kernels (to include Windows 2000, XP, and 2003). NTLM was the most secure protocol for NT 4.0 but it is considered a secondary means of authentication as of Windows 2000. Kerberos, which we’ll discuss next, has taken its place as the primary security authentication protocol for Windows domains.

NTLM works on a challenge-response authentication mechanism. The authenticating mechanism, whether the local server or a domain controller, produces a challenge that the client must use to generate its response. The client takes the challenge and encrypts it with its password. It then sends the response back. The authenticating mechanism, which has the password, too, is able to validate whether or not the client knows the password. It does this by taking the challenge and encrypting it with the password it knows. If both are the same, the client has proven that it knows the password. Therefore, the authenticating mechanism recognizes the client. All this has taken place without a password being transmitted across the network.

Given this challenge response mechanism for authentication, NTLM is considered more secure than either basic or digest authentication. Whenever possible, it should be used rather than those two authentication types.

Kerberos Authentication

Kerberos was introduced as a security protocol starting with Windows 2000. Microsoft’s implementation of this protocol is based off of Request for Comments (RFC) 1510, the RFC for Kerberos version 5 (since superseded by RFC 4120). Admittedly, though, Microsoft has “extended” the Kerberos implementation specified in this Internet “standard.” One advantage Kerberos has over NTLM is that of mutual authentication. In NTLM, only the client is verified. The client must assume the server is legitimate. That is, no rogue server is pretending to be the server being connected to. Kerberos handles this issue by using a trusted third party (in an Active Directory implementation this trusted third party is a domain controller), the details of which are not germane to our discussion here.

However, in order to use Kerberos, the account being used to authenticate must be a domain account. In addition, there is likely some work that’ll be required of a domain administrator in order to ensure the proper Service Principal Names (SPNs) are registered. How to do this will be covered later in this chapter.

Shortcut…

Integrated Authentication

Integrated authentication is actually NTLM and Kerberos Authentication rolled into one exchange. In order to understand what I mean by this, we have to take a look at how HTTP-based authentication normally happens. Let’s take a closer look.

When a client wants to access a resource via HTTP, it first sends a request to the server identifying exactly what it wants. If the resource requires some sort of authentication (SQL Server does), the server will send back a response indicating that authentication is required. In that response the server will indicate to the client what methods of authentication are permitted. When an HTTP endpoint is configured to use Integrated authentication, the server will tell the client that it can choose either Kerberos or NTLM authentication. The client, if it chooses to continue, responds by following through with the appropriate form of authentication. In the case of integrated authentication, the client can either choose to authenticate via Kerberos or NTLM. If the authentication succeeds, the server then provides the resource as requested. However, if the authentication fails, SQL Server will not permit the client to try again with the second method without going through the whole connection process again.

Shortcut…

TCP Endpoints

TCP endpoints have only a few authentication types, two of which we’ve talked about in the previous section. The types available to us are:

NTLM Authentication

Kerberos Authentication

Negotiate Authentication

Certificate Authentication

We’ve already covered NTLM and Kerberos authentication under HTTP endpoints. The authentication method doesn’t differ except with respect to how the client is communicating with SQL Server. Otherwise, authentication is exactly the same. If we’re setting up an endpoint for T-SQL traffic, we actually don’t specify a means of authentication. SQL Server will use whatever the authentication mode is for the server. These authentication types only come into specific use when we’re defining a service broker or database mirroring endpoint.

Note

Though it is possible in SQL Server to create more than one TCP endpoint for T-SQL, there’s no point in doing so. One of the things I attempted when first experimenting with SQL Server 2005 endpoint security was trying to create a second TCP endpoint for T-SQL and locking down its access. The idea was to have one connection, from the internal network, with few restrictions, and a second connection, strictly locked down, for the web servers in the DMZ. Unfortunately, SQL Server 2005 treats all the T-SQL endpoints the same (with the exception of the Dedicated Administrator Connection). Therefore, there is no good reason to have more than one TCP endpoint for T-SQL.

Digest Authentication

Digest authentication is another authentication type specified in HTTP 1.1. Unlike basic authentication, digest authentication does not require the password to be transmitted. Rather, the client takes the username and password and uses the MD5 hashing algorithm to create a hash, which is then sent to the SQL Server.

If you are not familiar with hashing algorithms, they are one-way functions when you put in a stream of values (such as the username and password), and you get a stream of characters as a result. If the hashing algorithm is “reasonable secure,” there is no way to take the output stream of characters from a hashing algorithm and get back to original stream. As a result, most of the research on hashing algorithms revolves around finding techniques to generate collisions. A collision is when two different input streams produce the exact same output stream. For instance, if “dog” and “cat” both produced “boy” when going through a hashing algorithm, you’d have a collision. Unfortunately, recent research against MD5 has found mechanisms for generating collisions rather quickly.

With respect to SQL Server 2005, digest authentication requires two key elements to work. First, the username must be a valid Windows domain login. A local Windows account on the server will not work. Neither will a SQL Server login. Second, the domain controllers for the domain must be at least Windows Server 2003. Windows 2000 domain controllers do not support digest authentication. There is a workaround to make digest authentication work with IIS 5.0, but it requires all user account passwords to be stored in a format where the encryption can easily be reversed (and the password revealed). This insecure method of supporting digest authentication is not utilized by SQL Server 2005. Therefore, if you have SQL Servers on a Windows 2000 domain, you likely won’t be able to use digest authentication.

Capturing Windows NT Authentication Information

Windows operating systems support a number of different authentication types, each of which progressively increase its security. The use of weak Windows NT authentication mechanisms, as explained next, creates one of the weakest links in Windows NT security. The authentication types supported are explained here:

Plaintext Passwords are transmitted in the clear over the network.

Lan Manager (LM) Uses a weak challenge response mechanism where the server sends a challenge to the client, which it uses to encrypt the user's password hash and then send it back to the server. The server does the same, and compares the result to authenticate the user. The mechanism with which this hash is transformed before transmission is very weak, and the original hash can be sniffed from the network and cracked quite easily. In Windows NT 4, even though a stronger authentication mechanism is available (NTLM), the LM hash was still sent over the network along with the NTLM hash, which lowers the security to the security of the LM mechanism.

NT Lan Manager (NTLM) and NT Lan Manager v2 (NTLMv2) NTLM and NTLMv2 provide a much stronger challenge/response mechanism, which has made it much more difficult to crack captured authentication requests. NTLMv2 was introduced with the release of Service Pack 4 for Windows NT 4.0. NTLMv2 should be used if possible; however, care must be taken to ensure that your clients can support the protocol. You may need to install additional software on the clients to allow them to use NTLMv2.

The development of these mechanisms occurred in a series of iterative steps, as weaknesses were found in each prior implementation (fortunately, the weaknesses became less significant with each improvement).

There are specialized sniffers that support only the capture of Windows NT authentication information. A good example is one included with the L0phtcrack program (which is exclusively a Windows NT password cracker). The documentation that comes with L0phtcrack explains in great detail how Windows NT password hashes are created. L0phtcrack can be obtained at http://stake.com/research/lc3.

Authentication Protocols

The protocols used for authenticating identity depend on the authentication type. Some common protocols used for authentication include the following:

Kerberos The default logon authentication protocol used by Windows 2000, XP, and Vista, as well as by Windows Server 2003 and Windows Server 2008. It is also used by Mac OS X. This protocol is based on secret key (symmetric) cryptography, which we'll discuss in Chapter 12. This system uses tickets that a central server issues to determine whether a user can access the network and its resources. Rather than being used to log on to each server, the tickets are used by all of the servers to determine what a user is permitted to access.

Challenge Handshake Authentication Protocol (CHAP) Uses a sequence in which one party sends a challenge and the other responds with an answer. The most common form of this sequence is the server requesting a password, which the client provides to gain access to a system. Microsoft developed its own version of the protocol, called MS-CHAP.

NT LAN Manager (NTLM) Another Microsoft logon authentication method that is supported by newer versions of Windows. NTLMv2 provides more security than NTLMv1, and uses a challenge-response sequence to authenticate the user. Unlike Kerberos, with NTLM, when a client wants to access a server's resources, that server must contact the domain controller to have the client's identity verified. The client doesn't have credentials already issued (the session ticket in Kerberos) that the file or application server knows it can trust.

Password Authentication Protocol (PAP) A remote access authentication protocol used for Point-to-Point (PPP) or dial-up connections. Its distinguishing characteristic (and the reason it should not be used on secure networks) is the fact that it sends passwords in plain text. This means an unauthorized person can intercept and use the passwords during transmission. The only good reason to use PAP is if you face a situation in which the remote server doesn't support other, more secure authentication methods. Shiva PAP (S-PAP) addresses this problem by using a two-way reversible authentication method that encrypts passwords so that they will not be subject to interception and misuse.

The Remote Authentication Dial-in User Service (RADIUS) Another means of authenticating remote connections that takes the authentication responsibility off each individual remote access server by providing a centralized server to authenticate clients securely.

Secure Shell (SSH) Allows users to log on to UNIX systems remotely. Both ends of the connection (client and server) are authenticated, and data—as well as passwords—can be encrypted.

On the Scene

LEAP

LEAP (Lightweight Extensible Authentication Protocol) is an EAP authentication type used primarily in Cisco Aironet WLANs. LEAP supports strong mutual authentication, based upon a modified MS-CHAPv2 challenge/response, between the client and a RADIUS server using a logon password as the shared secret. It provides dynamic per-user, per-session WEP encryption keys. LEAP has been superseded by EAP-FAST due to the public availability of LEAP hash cracking tools such as ASLEAP. There is some disagreement regarding the value of complex password enforcement when using LEAP. When in doubt, use the longest, most complicated passwords that your userbase will agree to.

802.1x

802.1x is a port authentication control protocol used to translate messages from a variety of different authentication types into their appropriate frame formats. You can use 802.1x in other 802-based technologies such as Ethernet (802.3) and Token Ring (802.5). For the purposes of this chapter, we will refer to 802.1x and its use for wireless (802.11) networks.

802.1x supports the requirements for per-user authentication and settings. It supports mutual authentication methods between the access point and the wireless client that is authenticating. Allowing the wireless client to authenticate the wireless gateway just as the wireless gateway authenticates the client user helps improve security by preventing the possibility of clients authenticating to a possible rogue device or, perhaps, a planted attacker’s access point. 802.1x also supports dynamic per-user keying. Dynamic creation of encryption keys and per-user capability create robust security for enterprise networks.

Although 802.1x does not choose what authentication and algorithm types it will use, it does work with EAP to provide such information.

The three common components of 802.1x are the supplicant Port Access Entity (PAE), the authenticator PAE, and the authentication server. The supplicant is the client end user trying to authenticate and connect to the wireless network resources. The authenticator is normally the access point that enforces authentication before it allows access to the resources. The authentication server is used to verify end-user credentials against a local or remote database. Figure 7.23 shows the relationship among the three components.

You may have noticed the acronym EAPOW in the figure. EAPOW stands for Extensible Authentication Protocol Over Wireless and it is an EAP message that is encapsulated over wireless networks. During the authentication phase, the access point will only allow EAPOW traffic through to the wired network from the end user trying to establish connectivity. This mechanism prevents the authenticating user from sending anything but its credentials into the wired network. After a successful authentication completes, an EAP message is sent from the authentication server to the access point telling the access point that the authentication has passed. At this point, the access point lifts the EAPOW access-only filter and opens up other communications specified by the security policy for the authenticating user.

Changing Authentication Settings

You can take several actions in the security space, such as changing the authentication type for your Web site or application. The needs of your Web applications often differ even though they are running on the same server and it is important to understand how to change authentication settings.

Extensible Authentication Protocol (EAP)

The Extensible Authentication Protocol (EAP) was designed to provide authentication methods within the Point-to-Point-Protocol (PPP). EAP allows for the integration of third-party authentication packages that use PPP. EAP can be configured so that it can support a number of methods for authentication schemes, such as token cards, public key, certificates, PINs, and on and on.

When you install PPP/EAP, EAP will not select a specific authentication method at the Link Control Protocol (LCP) Phase, but will wait until the Authentication Phase to begin. What this does is allow the authenticator the ability to request more information, and with this information it will decide on the method of authentication to use. This delay will also allow for the implementation of a server on the backend that can control the various authentication methods while the PPP authenticator passes through the authentication exchange.

In this way, network devices like Access Points (APs) or switches do not need to understand each request type, because they will simply act as a conduit, or passthrough agent, for a server on a host. The network device will only need to see if the packet has the success or failure code in order to terminate the authentication phase.

EAP is able to define one or more requests for peer-to-peer authentication. This can happen because the request packet includes a type field, such as Generic Token, one-time password (OTP), or an MD5 challenge. The MD5 challenge is very similar to the Challenge Handshake Authentication Protocol (CHAP).

EAP is able to provide you with a flexible, link-layer security framework (see Figure 15.2), by having the following features:

EAP mechanisms are IETF standards–based and allow for the growth of new authentication types when your security needs change:

Transport Layer Security (TLS)

Internet Key Exchange (IKE)

GSS_API (Kerberos)

Other authentication schemes (LEAP)

There is no dependency on IP, because this is an encapsulation protocol.

There is no windowing as this is a simple ACK/NAK protocol.

No support for fragmentation.

Can run over any link layer (PPP, 802.3, 802.5, 802.11, and so on).

Does not consider a physically secure link as an authentication method to provide security.

Assumes that there is no reordering of packets.

Retransmission of packets is the responsibility of authenticator.