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 {Name, Position} 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).

3.1.2 Analysis of Protocol draft 1.0 There is no need to analyse step (1) in detail, since the information sent by C is required to identify himself and to specify which server it wants to contact. Concerning the content of the ticket sent on step (2), IDV is part of the ticket so that during step (3) V can check if the the ticket was decrypted correctly. IDC is included in the ticket simply to inform V about who was given a ticket to contact it. ADC plays an important role; if a malicious attacker captures the ticket sent on step (2) (from another machine), then he could try to get access to V using C’s ticket. Since its address wouldn’t match with ADC , then the attack will not be able to work. Finally there are two problems with this protocol version. First of all, on step (1) C sent his password in plaintext, which means it could be read by an eavesdropper. Secondly, for each access to a service, a ticket has to be generated and the user needs to re enter its password, which doesn’t seem to be very efficient. The problems stated above give us enough reasons to build a draft for a new protocol version.

3.1.3 Protocol draft 2.0 In this new version we will add a new server called ticket-granting server (TGS). Basically, users will receive tickets from the TGS to be able to access services, but only after the user is authenticated by the AS.

Figure 3: Steps necessary for C to access V, now with the presence of a TGS.

With a TGS, steps (1) and (2) (on figure 3) only need to be done once per user logon session. In step (1) C request a ticket-granting ticket from AS in order to contact TGS. So C sends a message to AS containing IDC and IDtgs. On step (2) the AS simply replies to C by sending a ticket (T ickettgs), but T ickettgs is encrypted at the AS using C’s password. So only the real C can decrypt the message and recover the ticket. By using this method we already manage to avoid having C sending his password in plaintext over the network. Now the idea is to be able to reuse the ticket-granting ticket to access different services. In short, steps (3) and (4) will only occur once per type of service. Meanwhile an attacker could capture

6 a ticket and use it later on to access services, to counter that situation, every ticket used in this protocol version contains a timestamp and a lifetime, that way the ticket will not always be valid. It should also be said that T ickettgs is actually a few parameters that were encrypted using a key Ktgs that is only known by the AS and the TGS. This way no one can alter the content of the ticket. On step (3) C sends IDC , IDV and T ickettgs to TGS in order to request a service. On step (4), the TGS decrypts T ickettgs and checks if all the parameters received are correct, if yes then it answers back to C with a new ticket (T icketV ). This ticket is encrypted using KV that only the TGS and V know. With this ticket the client can also request the same service later on, if the lifetime of the ticket didn’t expire. Finally on step (5), C can request a service from V by sending T icketV and IDC .

3.1.4 Analysis of Protocol draft 2.0 In this version we were able to correct the weaknesses from the previous version, unfortunately there are still two problems remaining. The first problem is the lifetime of a ticket; if too short the user will have to retype a password several times, if too long it can be used by a malicious attacker (faking his address) after the user logged off. The second problem is related to the fact that we only considered that the client should identify itself to the server, but not the opposite. An attacker could redirect messages intended for a server, to another machine. We can now consider to have enough tools in our hands to see how the real Kerberos Version 4 protocol works and how it solves the new problems mentioned.

3.1.5 Kerberos Version 4 As usual and to make things more clear let’s add an illustration with all the messages exchanged between the different entities. See figure 4.

Figure 4: Steps necessary for C to access V. Schema with mutual identification.

As on the previous versions, in step (1) C demands a ticket from the AS to request a ticket from the TGS. On step (2), the AS responds to C with a message encrypted with C’s password KC . This time the message contains a session key called Kc,tgs and a ticket T ickettgs which itself contains also Kc,tgs. C can now send a request to the TGS in step (3), using the received T ickettgs, the IDV and an authenticator. T ickettgs can be decrypted by TGS since the key used to encrypt (Ktgs) is shared

7 by the AS and the TGS. When decrypting T ickettgs the TGS can check that C was provided with the session key Kc,tgs. The authenticator is used to check the identity of the agent sending a message to TGS. The authenticator is decrypted by the TGS, using Kc,tgs that he obtained from the ticket sent by C. In conclusion the ticket is used to distribute keys securely and the authenticator is used to identify the client. To prevent from being stolen and reused, the authenticator can only be used once and has a very short lifetime. On step (4), the TGS answers to C with a message similar with step (2); it is encrypted with Kc,tgs and contains a new session key Kc,v that only will only be known by C and V. On step (5) C sends a message to V containing a ticket and an authenticator. The ticket can be decrypted by V using KV that only the TGS and V knows. After that, V obtains the session key necessary to decrypt the authenticator, and can finally check C’s identity. We talked about the server identifying itself to the client, that is done on step (6). It sends back a message encrypted with Kc,v, which only C and V are able to decrypt, since they are the only entities able to recover Kc,v. At the end of this whole process C and V share a secure key Kc,v that can be used for ex- changing messages, and can also be used to transmit a new random session key to secure every new communication.

3.1.6 Kerberos Conclusion We have presented how Kerberos version 4 works, nevertheless the reader should know that there is a version 5 of Kerberos that solves environmental shortcomings and technical defects from the previous version. By knowing how the fourth version works, the reader is prepared to learn the differences in the two versions. We will not detail version 5 on this report.

3.2 X.509 certificates In LDAP and Active Directory it is also possible to use X.509 certificates for authentication of users. We have studied this certificate during the course so I will not give a detailed description. Just as a reminder we can say that it involves public key cryptography and the use of digital signatures. The certificates should be issued by a trusted certification authority (CA). In the case of a company we can have a system administrator issuing himself certificates, on the company’s behalf.

8 4 RADIUS 4.1 Introduction RADIUS is an acronym for Remote Authentication Dial-In User Service. It allows a user to get access to networking resources based on a set of credentials it provides to a Network Access Server (NAS). This server checks the credentials using the RADIUS protocol against a database of allowed users on an authentication server, which in turn provides authorization and configuration information back to the NAS and by extension to the user. The name ”RADIUS” is used for both, the protocol and the authentication server. RADIUS was originally developed in 1991 for the company Merit Network which wanted to have a control system for clients dialling in to their network for control and billing purposes.

4.2 Functionality The new system should provide the three features of an AAA protocol [6]: Authentication The identification of a user based on a set of credentials, usually a username and password.

Authorization Allowing access to specified services of the network based on the user authentica- tion. Accounting Collecting statistical information about the network connection like transmitted data and uptime for billing purposes.

4.2.1 Authentication and Authorization Let’s look at the communication in more detail to see, how the protocol achieves these properties. For detailed information on packet structure and options see [7]. RADIUS can use various flavours of authentication including PAP1, CHAP2 and EAP3 protocols, depending on the implementation of RADIUS. If a user wants access to a network it connects to a NAS and presents its credentials, as seen in figure 5 (1). In the case of PAP the username and password will be given, for CHAP only the username. The NAS will contact the RADIUS server by sending an Access Request (2) message containing the user’s credentials and additional information like the service requested, his address, etc. The password is hashed together with a secret the NAS and the RADIUS server share using MD54 to reduce the insecurity of protocols like PAP. The RADIUS server will check whether the request comes from a valid NAS and if this is true, verifies the user’s credentials against a database which can either be local or remote (3). A remote user database might be implemented as a directory using LDAP, a simple table in a SQL server or even a full-fleged Kerberos server. In case of CHAP (or most EAP protocols) the RADIUS server will send an Access-Challenge message to the NAS (4) containing a challenge like a nonce and the NAS will in turn notify the user (5) to provide further means of authentication by encrypting his password together with this nonce. This will be send to the RADIUS server via the NAS in yet another Access Request message (6)(7). The RADIUS server checks these new credentials also and then might respond with an Access-Accept or Access-Reject message (8)(9) accordingly.

1Password Authentication Protocol. Uses plaintext-transmission of passwords. Used in PPP. 2Challenge-Handshake Authentication Protocol. Provides higher security through eg. nonces which have to be hashed/encrypted together with the password. 3Extensible Authentication Protocol. This is a framework for various more modern protocols. 4Because of MD5’s vulnerabilities [9] it is highly suggested to use IPsec to provide proper confidentiality.

9 The Access-Accept message will contain configuration information for the requested network, for example the IP-address for a PPP-connection. Now the user can access the network (10).

Figure 5: Authentication and Authorization using RADIUS.

4.2.2 Accounting Once the user is authenticated and authorized and the connection is established the NAS will send an Accounting Start message to the RADIUS which can now log metrics like connection uptime, transferred data and transferred packets and so on for billing and statistics purposes. The NAS may continue to send further interim accounting messages to the RADIUS. Once the connection is closed the NAS will notify the RADIUS with an Accounting Stop message. For more information see [8].

4.2.3 Realms and Proxies The set of users and network resources under the control of a RADIUS server is called ”realm”. Several RADIUS servers may work together in a larger network, establishing a trust relationship between their realms. A RADIUS server might therefore act as proxy and forward messages on behalf of its users in order to authenticate them in other trusted realms.

4.3 Usage RADIUS is widely used with many implementations [10] by telecommunication providers, ISPs, and Companies with internal networks. It can be used to authenticate and authorize users within PSTN or ISDN-phone networks, VoIP, RAS- and Internet services. A user of DSL for example will connect to a NAS via PPPoE and transmit his user data and from there on get access to the internet via his ISP’s network. Another example is the widespread use of RADIUS to secure WLANs, especially in corporate environments, also referred to as captive portal mechanism: The user will be allowed to connect to an access point which redirects all traffic to a NAS which will display a website in order to log into the network using the RADIUS server.

10 References

[1] Morgan Hallgren and Kristian Holm Hur hanterar institutioner en milj med blandade Operativsystem? [2] Matt Butcher Mastering OpenLDAP: Configuring, Securing and Integrating Directory Services

[3] http://en.wikipedia.org/wiki/LDAP [4] http://en.wikipedia.org/wiki/Simple Authentication and Security Layer [5] William Stallings Cryptography and Network Security, Principles and Practice, 2nd edition [6] IETF WG for Authentication, Authorization and Accounting (http://tools.ietf.org/wg/aaa/) [7] IETF RFC 2865 (http://tools.ietf.org/html/rfc2865)

[8] IETF RFC 2866 (http://tools.ietf.org/html/rfc2866) [9] Xiaoyun Wang and Hongbo Yu: How to Break MD5 and Other Hash Functions [10] TechRepublic article: Ultimate wireless security guide: Microsoft IAS RADIUS for wireless authentication (http://articles.techrepublic.com.com/5100-10878 11-6148579.html)

11