3.2. Identification and Authentication
In order to control access to resources and to make users of a computer system accountable for their actions, it is necessary that the computer system has some way of associating actions with users. This means that the computer system must have some way of identifying and distinguishing users. The standard way of doing this is to provide each user with an account. This account provides a way of linking human users with the actions they perform while interacting with the computer.[1]
[1] In networked systems, each machine usually has an account, so that, for example, a client machine can request actions on a remote server and have those actions linked to the client.
Having successfully logged on to a computer system, the user is provided with an interactive environment from which he or she can execute programs. This environment is usually in the form of a command line interface (often known as a shell) or a graphical user interface (often known as a desktop). In the former case, the user types the name of a program that he or she wishes to execute; in the latter, the user clicks on the appropriate icon. In both cases, the interface is provided by the execution of a computer program that is executed following a successful log-in.
The process associated with that program is identified with the account of the authenticated user. Any new programs that are executed by the user from this interface will also be associated with that user account. Hence, the actions of any programs executed by the user can be accounted for. Moreover, we can enforce security policy requirements of the form “Jason can read file.txt but Mick cannot.” Any program that is associated with Jason’s user account will be permitted to access file.txt, and any program associated with Mick’s user account will not.
Each user account is bound to security information for the corresponding user. In the simplest case, this is just the user’s security identifier (SID). Many access control policies specify the access rights for which an SID (and therefore the user) is authorized. Typically, the security information will also include one or more of the following types of security attribute: group identifiers (GIDs), roles, and security levels.
3.2.1. Password-Based Authentication
Everyone is familiar with the process of entering a password into a computerized device in order to gain access. Everyday examples include the PINs we enter to use ATM machines and unlock mobile phones, and the password we enter to log on to our computer at work. Nevertheless, passwords are a poor method of authenticating users: Passwords are reused for each authentication event, and passwords are generally easy for an attacker to obtain, either through social engineering, the carelessness of users, or by exploiting the fact that passwords are generally easy to guess or brute-force.
Ideally, passwords should be easy to remember and hard to guess. Of course, these are conflicting requirements, and users often choose weak passwords that are easy for attackers to guess. This means that passwords are a particularly poor method of authentication in distributed systems, in which the password may have to travel over a network; even if the password is encrypted, an attacker may capture the password in transit and mount an offline brute-force or dictionary attack to recover the password.
Password-based authentication is still the most widely used method of authentication in computer systems. As we have already noted, password information must be readable by the log-in process, so it must be stored within the computer system. This suggests that either the password file containing this information must be very well protected or the information itself must be protected in some way.
There are two obvious possibilities: deploy very strong access controls for the file containing passwords or encrypt the passwords. In practice, both strategies are employed in modern operating systems. It is instructive to consider the authentication method used in early Unix systems to demonstrate why both types of controls are required.
In earlier versions of Unix, the /etc/passwd file contained user information such as user and group identifiers, as well as a ciphertext derived from each user’s password. The /etc/passwd file was readable by all users because other Unix services needed access to some of this user information (but not the passwords). This meant that any user of the system could create a copy of the file and try to “crack” the passwords in his or her own time.
3.2.2. Insecure Communication Channels
In order to authenticate to a computer system, the user must communicate with the system. If an attacker can position him- or herself in some way between the user and the computer system, then he or she can intercept the password. In the past, a common way of doing this was to spoof the authentication process. This problem arises because the user does not confirm that he or she is communicating with (i.e., authenticate) the genuine log-in process. The standard technique for preventing so-called man-in-the-middle attacks is for the communicating parties to mutually authenticate. In many distributed systems, the authentication process is mutual: The (client) user is authenticated by the (server) computer system and the server is also authenticated by the client.
Trusted path functionality (a requirement for B classifications in TCSEC[2]) is used to provide a lightweight method of ensuring that a user is communicating with the genuine authentication process. The user invokes the authentication process through some special key combination. This combination can only be trapped by the operating system kernel and therefore cannot be detected by third-party programs (including malicious programs that attempt to spoof the authentication process). Perhaps the best known example of trusted path functionality is the Ctrl+Del+Enter secure attention sequence (SAS) provided by Windows 2000.
[2] See www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html.
3.2.3. Challenge-Response Systems
One of the problems with using passwords is that they are generally reused. One-time passwords are one solution to this problem [2]. An alternative is to use a challenge-response mechanism. Whenever a user wishes to authenticate, the authentication service issues a challenge to the user. The user is only authenticated if he or she responds in an appropriate way. Like one-time passwords, an intercepted challenge is useless to the attacker, because it will be different for each authentication event.
The challenge-response mechanism may be based on the ability to correctly compute some function of a value provided by the authentication process. The user could share a secret key k with the authentication service. The authentication service sends a random value m to the user, which the user encrypts and returns the ciphertext c to the authentication service. The authentication service also encrypts m to produce a ciphertext c′. The authentication service compares c and c′, and the user is authenticated if the two values are identical. Of course, the authentication process must be assumed to be completely compromised if k is lost or stolen.
If we assume the existence of a public key infrastructure, the user could sign a challenge m with his or her (private) signature key. The authentication service authenticates the user if the signature can be verified using the corresponding (authenticated) public key of the user (since no other user could have produced such a signature).[3]
[3] The authenticity of the public key is guaranteed by a certificate signed by some certification authority trusted by the authentication service.
3.2.4. Authentication in Distributed Systems
Networks of computers are now commonplace, and the client-server model adopted by many distributed applications means that user authentication is performed by an application running on a different machine from the one at which the user is working. Users authenticating to a Windows 2000 domain, for example, are authenticated by a domain controller, not the workstation at which they log in. Let us assume that we have a client C and a server S. Generally, we want S to authenticate C and to establish a secure communication channel between C and S. We can establish a secure channel by creating a shared session key that is used to encrypt data transmitted between C and S (using a symmetric encryption algorithm). As noted above, C may also wish to authenticate S.
Let us assume that the client has chosen a password and the server knows this password. Authenticating a user over a potentially insecure network is considerably harder than authenticating a user locally. If a password-based authentication mechanism is used, we obviously cannot allow passwords to be transmitted over the network in the clear. Ideally, we should not even allow encrypted passwords to be transmitted over the network, because an attacker may intercept the encrypted password and crack the password using a brute-force or dictionary attack. Hence, it is commonplace for authentication mechanisms in distributed applications to include a challenge-response component.
In a distributed system, there may be many different servers, each running services that require client (user) authentication. Clearly it is inconvenient for a client to be authenticated by each of these servers or services, not least because this will require the existence of some prior “trust relationship” between the client and server. In practice, it is far simpler to have an authentication server that is used to authenticate users. This authentication server will have a trust relationship with each server and will therefore be able to provide some kind of assurances about client identities to those servers. Instead of having trust relationships defined between every pair of entities in the system, there exists a trust relationship between every client and the authentication server and between every server and the authentication server. The precise nature of the trust relationship will vary: It may be that every entity (client and server) shares a distinct secret key with the authentication server; alternatively, each entity may have a public and private key and the authentication server is a certification authority that authenticates the binding between entities and their respective public keys (typically by signing digital certificates).
Using Shared Keys
Kerberos is the most widely used protocol for authenticating users in a distributed system using shared keys [3]. It is based on the Needham-Schroeder protocol and uses an authentication server, which acts as a trusted third party. The authentication server enables two parties A and B to be mutually authenticated and to establish a shared session key. In the context of distributed computer systems, A might represent a client and B might be a service on a remote machine that requires client authentication.
If A wants to communicate with B, A first sends a message to the authentication server S, including A and B’s identities. S responds by sending two messages to A: The first is encrypted using the key shared by S and A, and includes the session key and a lifetime for which that key is valid; the second message is encrypted using the key shared by S and B, and also contains the session key and the lifetime, in addition to A’s identity. The second message is sometimes called a ticket. A forwards the ticket to B and a second message encrypted using the session key, which contains A’s identity and a timestamp to ensure freshness. Finally, B returns a message to A in which the timestamp is encrypted using the shared session key. The ticket serves to authenticate A to B, and the fact that B can correctly encrypt the timestamp authenticates B to A.
Using Public Key Cryptography
In the simplest case, A can authenticate B if A simply sends a nonce to B and B signs the nonce using his private key. A then verifies that signature using B’s public key. In fact, A has only confirmed that a valid private–public key pair has been used to sign and verify a signature. In order for B to be properly authenticated, A needs to be assured that the key used to sign the nonce is actually associated with B. A can satisfy herself of the authenticity of a public key if a third party trusted by A has signed a digital certificate binding B’s identity to his public key. (Of course, this requires methods for creating and managing public–private key pairs and for binding public keys to identities using digital certificates. Collectively, these methods form part of a public key infrastructure.)
As we noted before, authentication protocols in distributed systems often exchange a symmetric key that is used to encrypt subsequent communication between the two parties. A can exchange a session key with B (again provided A can be assured of the authenticity of B’s public key) by encrypting the session key using B’s public key and sending it to B. Only B will be able to recover the session key, assuming that B is uniquely associated with that public key and B’s secret (private) key has not been compromised.
Single Sign-On
In the shared symmetric key setting, the authentication server can issue a ticket encrypted using a key shared by the authentication server and a ticket-granting server (TGS). (This ticket is usually called a ticket-granting ticket.) The TGS issues further tickets for network services requiring user authentication, based on the prior authentication of the user by the authentication server (implied by the ticket encrypted with the key shared by the TGS and the authentication server). In this way, Kerberos, for example, can be used to provide single sign-on within a domain in which the servers have a trust relationship with the TGS.
In the public key setting, the authentication server issues “tickets” or “assertions” confirming that A has been authenticated. These tickets will be signed using the authentication server’s private key. All servers that trust the authentication server will accept such tickets and permit the subject of the ticket to use their respective services. This type of model was used by Digital Equipment Corporation in their Distributed System Security Architecture [4].
The Security Assertion Markup Language (SAML), a recent standards-based initiative, is an “XML-based framework for creating and exchanging security information between online partners” [5] that we review in more detail in Section 3.4. One of SAML’s main applications is to support single sign-on. The standard defines a number of different types of assertions, including authentication assertions, which are made by SAML authorities.[4] Of course, this still requires relying parties to trust the SAML authorities and hence for there to be some kind of trust relationship between them. As usual, these trust relationships may be defined explicitly using shared symmetric encryption keys or using some kind of public key infrastructure.
[4] Obviously, the authenticity of such assertions needs to be established. The XML encryption and XML Digital Signature standards provide mechanisms for providing the relevant security services.