Centralised Authentication Fabian Alenius Guerreiro Jo~ao Uwe Bauknecht March 3, 2009 Contents 1 Introduction 2 2 LDAP 3 2.1 History of LDAP . 3 2.2 Directory servers . 3 2.3 Distinguished Names . 3 2.4 Directory Information Trees . 3 2.5 LDAP Authentication . 4 2.6 SASL binding . 4 3 Authentication Methods [5] 5 3.1 Kerberos . 5 3.1.1 Protocol draft 1.0 . 5 3.1.2 Analysis of Protocol draft 1.0 . 6 3.1.3 Protocol draft 2.0 . 6 3.1.4 Analysis of Protocol draft 2.0 . 7 3.1.5 Kerberos Version 4 . 7 3.1.6 Kerberos Conclusion . 8 3.2 X.509 certificates . 8 4 RADIUS 9 4.1 Introduction . 9 4.2 Functionality . 9 4.2.1 Authentication and Authorization . 9 4.2.2 Accounting . 10 4.2.3 Realms and Proxies . 10 4.3 Usage . 10 References 11 1 1 Introduction When a user wants to login to a computer system he has to go through the process of authentication. If the same user wants to authenticate against two computer systems he needs to authenticate twice. This becomes unpractical very fast as the number of systems grow, especially if the user has to remember separate usernames and passwords for each system. Another problem with this is that the management of the user accounts becomes complicated as we need several user accounts for each user. So, if we for example want to remove one user completely, we need to update all our systems. The solution to this problem is to use a centralized authentication server. This means that every time a user wants to authenticate, he always does it against the same server. This also means that all the accounts are stored in the same place, so there is no redundancy. In order to use centralized authentication, the systems have to include support for it. There are different protocols and applications that can be used for central authentication. Due to the limited time available for the report we decided to focus on just three protocols: LDAP, Kerberos and RADIUS. 2 2 LDAP LDAP is a directory server, its most common use is as an enterprise management tool [1]. It can be used as a central authority for users, groups and accounts. In the directory we store information about the users, such as usernames, passwords, real names, telephone numbers and email addresses. 2.1 History of LDAP LDAP is an abbreviation for Lightweight Access Directory Protocol. LDAP at its core is a network protocol designed to retrieve and store data in a X.500 directory (a directory server architecture, designed and standardized in the 1980s). The original LDAP servers were thus just gateways to these X.500 directories [1]. Today however, LDAP has grown into a directory service in its own right and now includes standards for full-fledged directory servers. 2.2 Directory servers A directory might for example be a phonebook or a catalogue. Since the phonebook is organized in alphabetic order we can search it efficiently. A digital directory is not that different from its analogue cousin: The purpose of the directory is to organize information and to make it searchable. Of course you also need to be able to add and remove information, but it is assumed that modifications occur less frequently than searches. A directory server is a server containing one or more directories and is optimized so that searching is very effective [1]. A typical entry in a company personnel directory might look something like this: Name: Joe Average Position: Vice President Street: Example-street 112 City: New York Postal Code: 23423-3433 Phone Number: 555-123321 ObjectClass: person 2.3 Distinguished Names To be able to uniquely identify an entry we need a way to distinguish it from the the other entries in the directory. This is accomplished by setting a Distinguished Name(DN), this is a similar concept to keys in relational databases. The DN is a set or subset of the attributes associated with the entry. For example we might choose fName, Positiong as DN and this will work fine as long as we don't have two employees with the same name and position. A better solution is to assign every employee a unique integer, a user/employee ID. The ObjectClass attribute is similar to a type declaration and specifies which attributes this entry has. 2.4 Directory Information Trees Entries in a directory are organized into hierarchies, consider for example a company Acme. At the top is the company itself, below is the different departments such as Accounting and Marketing. Under these departments are the employees working for that department. 3 Figure 1: DIT 2.5 LDAP Authentication In order to interact with the LDAP server we must first authenticate with the server. This is called "binding". LDAP supports two methods of binding: Simple binding and SASL binding. Simple binding is exactly what it sounds like, very simple to setup and administrate. Unfortunately it is also very insecure, as it simply sends the DN and password in plaintext over the network [1]. Maybe somewhat ironically, the password can optionally be stored in encrypted format on the server while being sent in plaintext over the network. In order to bind to the server we need to send our DN and password to the server. If the client software does not know the DN of the user we need to find it in some way. LDAP can achieve this by allowing anonymous connections. When connecting as Anonymous, no password is required and the client can find the DN. The client then rebinds using the DN found as Anonymous. Unfortunately this means that anyone can browse the directory server and see the DN:s used to login. One way to make this slightly more secure is to add an authentication user auth with an associated password. So that instead of binding as Anonymous, the client now first binds as auth and finds the DN used to login. This means that the auth password will need to be distributed to the clients in some way. You can also use SSL/TSL to encrypt the LDAP traffic making it a lot harder to gain unautho- rized access to the LDAP directory. 2.6 SASL binding SASL is an abbreviation for Simple Authentication and Security Layer, it is a framework for au- thentication [4]. By decoupling the authentication mechanism from the application SASL allows an application to support several authentication mechanisms. LDAP includes support for SASL and thus every authentication mechanism that implements SASL. Some examples are: • DIGEST-MD5 • OTP One-time Passwords • Kerberos • GateKeeper (Microsoft) 4 3 Authentication Methods [5] In this chapter we will look at two of the most used and well known mechanisms for authentication, that are well supported by LDAP and Active Directory. 3.1 Kerberos Kerberos is a computer network authentication protocol developed by MIT. Its name refers to Cerberus, a character from Greek mythology which was a three-headed dog that was responsible for guarding the entrance of the underworld, ruled by Hades. To understand Kerberos we will analyse its construction. We will start by building up version four step by step so that we can grasp what and why, some mechanisms are used. As a starting point we will consider the following scenario : We have a network composed of several client machines and several servers that provide services for the clients. When a client applies for a service provided by a certain server, the server needs to confirm the identity of the requester. We need a protocol to implement such system, in a secure and efficient way. Let's make a protocol draft. 3.1.1 Protocol draft 1.0 Besides the servers that provide services to clients, we will introduce a new server in the network that will be known as the authentication server (AS). We make the assumption that the AS has all the user's passwords stored in a database it has access to and it also shares a unique secret key with each service providing server. The way the AS obtained all this information is supposed to have been done in a secure way. Let's consider the following dialogue : Figure 2: Steps necessary for C to access V. In figure 2 a user decides to log in to a client machine C and wants to request a service from a server V. Let's see what happens in the different steps : • In step (1), the client C sends to the AS, a message containing the user's ID (IDC ), the user's password (PC ) and the server's ID (IDV ). • Step (2) will only happen if the AS confirms the user's password and that it has the right to access the requested service. If it is the case, then the AS will send a ticket to C. The ticket contains the user's ID (IDC ) and network address (ADC ) and the server's ID (IDV ). Of course this information should not be sent in plain text, so the ticket is encrypted with a secret key KV that is shared by the AS and the server V. 5 • In step (3), C sends a message to V to request a service. V receives a message containing IDC and the ticket. V can decrypt the ticket using KV . By doing this, V can check if the decrypted user ID received and the encrypted user ID contained in the ticket, match. If they do match, then C gains the right to access V for its service(s).