Single Sign-On

Single sign-on is an attempt to address a problem that is common for all users and administrators. Various systems within the organization likely require the user to log on multiple times to multiple systems. Each one of these systems requires the user to remember a potentially different username and password combination. Most of us tire of trying to remember all this information and begin to look for shortcuts. The most common is to just write down the information. Walk around your office, and you might see that many of your co-workers have implemented the same practice. Single sign-on is designed to address this problem by permitting users to authenticate once to a single authentication authority and then access all other protected resources without reauthenticating. Before you run out and decide to implement single sign-on at your organization, you should be aware that it is expensive and if an attacker can gain entry, that person then has access to everything. Kerberos, SESAME, KryptoKnight (by IBM), and NetSP (a KryptoKnight derivative) are authentication server systems with operational modes that can implement single sign-on.

Thin clients can be considered a type of single sign-on system because the thin client holds no data. All information is stored in a centralized server. Thus, once a user is logged in, there is no reason for that user to reauthenticate.

 

Kerberos

Kerberos is a network authentication protocol created by the Massachusetts Institute of Technology (MIT) that uses secret-key cryptography. Kerberos has three parts: a client, server, and trusted third party (KDC) to mediate between them. Clients obtain tickets from the Kerberos Key Distribution Center (KDC), and they present these tickets to servers when connections are established. Kerberos tickets represent the client's credentials.

The KDC is a service that runs on a physically secure server. The KDC consists of two components:

• Authentication service The authentication service issues ticket-granting tickets (TGTs) that are good for admission to the ticket-granting service (TGS). Before network clients can get tickets for services, they must obtain a TGT from the authentication service.
• Ticket-granting service Clients receive tickets to specific target services.

The basic operation of Kerberos is as follows (and is shown in Figure 4.1):

1. The client asks the KDC for a ticket, making use of the authentication service (AS).
2. The client receives the encrypted ticket and the session key.
3. The client sends the encrypted TGT to the TGS and requests a ticket for access to the application server. This ticket has two copies of the session key: One copy is encrypted with the client key, and the other copy is encrypted with the application server key.
4. The TGS decrypts the TGT using its own private key and returns the ticket to the client that will allow it to access the application server.
5. The client sends this ticket, along with an authenticator, to the application server.
6. The application server sends confirmation of its identity to the client.

Figure 4.1. Kerberos operation.

Some Kerberos literature uses the term principal instead of client. Principals can be a user, a process, or an application. Kerberos systems authenticate one principal to another.

Although Kerberos can provide authentication, integrity, and confidentiality, it's not without its weaknesses. One weakness is that Kerberos cannot guarantee availability. Some others are listed here:

• Kerberos is time sensitive; therefore, it requires all system clocks to be highly synchronized.
• The tickets used by Kerberos, which are authentication tokens, can be sniffed and potentially cracked.
• If an attacker targets the Kerberos server, it can prevent anyone in the realm from logging in. It is important to note that the Kerberos server can be a single point of failure.

SESAME

The Secure European System and Applications in a Multivendor Environment (SESAME) project was developed to address some of the weaknesses found in Kerberos. SESAME incorporates MD5 and CRC32 hashing and two certificates. One of these certificates is used to provide authentication, as in Kerberos, and the second certificate is used to control the access privileges assigned to a client.

Access-Control Models

Access-control models can be divided into two distinct types: centralized and decentralized. Depending on the organization's environment and requirements, typically one methodology works better than the other.

Centralized Access Control

Centralized access-control systems maintain user IDs, rights, and permissions in one central location. RADIUS, TACACS, and DIAMETER are examples of centralized access-control systems. Characteristics of centralized systems include these:

• One entity makes all access decisions.
• Owners decide what users can access, and the administration supports these directives.

RADIUS

Remote Authentication and Dial-In User Service (RADIUS) is a UDP-based client/server protocol defined in RFCs 2058 and 2059. RADIUS provides three services: authentication, authorization, and accounting. It facilitates centralized user administration and keeps all user profiles in one location that all remote services share. Although ISPs have used RADIUS for years, it has become a standard in may other ways. RADIUS is widely used for wireless LAN authentication. The IEEE designed EAP to easily integrate with RADIUS to authenticate wireless users. The wireless user takes on the role of the supplicant, and the access point serves as the client. If the organization has an existing RADIUS server that's being used for remote users, it can be put to use authenticating wireless users, too.

RADIUS functions are as follows (see Figure 4.2):

1. The user connects to the RADIUS client.
2. The RADIUS client requests credentials from the user.
3. The user enters credentials.
4. The RADIUS client encrypts the credentials and passes them to the RADIUS server.
5. The RADIUS server then accepts, rejects, or challenges the credentials.
6. If the authentication was successful, the user is authenticated to the network.

Figure 4.2. RADIUS authentication.

Other centralized authentication methods include TACACS and LDAP.

TACACS

Terminal Access Controller Access Control System (TACACS) is available in three variations: TACACS, XTACACS (Extended TACACS), and TACACS+, which features two-factor authentication. TACACS also allows the division of the authentication, authorization, and auditing functions, which gives the administrator more control over its deployment. TACACS has failed to gain the popularity of RADIUS; it is now considered a somewhat dated protocol.

Decentralized Access Control

Decentralized access-control systems store user IDs, rights, and permissions in different locations throughout the network. Characteristics of decentralized systems include these:

• Gives control to individuals closer to the resource, such as department managers and occasionally users
• Maintains multiple domains and trusts
• Does not use one centralized entity to process access requests
• Used in database-management systems (DBMS)
• Peer-to-peer in design
• Lacks standardization and overlapping rights, and might include security holes