10 Identity and Access Management • , Authorization, Accounting (AAA) 10.1 Basic Authentication Schemes • Knowledge, possession and being factors – two factor authentication • Local Windows/Unix logon process • NT LAN Manager (NTLM) and LANmanager (LM) password schemes • Unix/Linux password scheme • Typical attacks on passwords 10.2 Challenge / Response Protocols • based on preshared secrets or on public key algorithms 10.3 Windows NT LAN Manager (NTLM) • NTLM challenge/response protocol • NTLM security analysis, offline-attacks 10.4 Key Distribution System • Mediation services offered by a key distribution center (KDC) • Kerberos authentication, ticket granting and client/server services • KDC replication / Inter-realm authentication 10.5 Single Sign-On • Workflow-based user provisioning • Meta-directories • IAM summary

1

2 Identification • Identification establishes who you claim to be: The user claims an identity, usually by supplying a user ID or a user name. Authentication • Authentication verifies that you are who you claim to be: The user supplies authentication information, which proves the binding between the user and the identity. Authorization • Authorization establishes what you„re allowed to do e.g. which files and applications you may access: The systems authorizes the (authenticated) user to do what he is allowed to do. Accounting • Accounting charges for what you do.

3 4 There are three ways to authenticate the identity of a user:

1. The users present something they know, such as a password. This approach is known as a Knowledge factor. (PIN = personal identification number) Passwords are the most common method of using confidential knowledge to authenticate users. Easy to administrate and convenient for most users, passwords are also the least expensive method of user authentication. Unfortunately, passwords have some drawbacks. Often, user-selected passwords are very short and simple, which makes them easy to guess.

2. The user presents something (physical) they have in their possession, such as a key or a card. This approach is known as a Possession factor. To authenticate users digitally people provide them with tokens that contain a digital code. Tokens are available as both hardware and software. They may generate a different code within regular time intervals or upon request (e.g. upon reception of a „challenge“).

These tokens may also be smart cards, similar in size to a standard credit card which is inserted into a card reader as part of the authentication process. They may contain a digital certificate and they are usually presented in combination with a password or Personal Identification Number (PIN).

3. The user presents a personal physical attribute, such as a fingerprint or a retinal scan. This approach is known as a Being factor. Unfortunately biometrical methods (with the exception of iris/retina scans) are still rather unreliable. A two-factor authentication combining 2 of these 3 credentials is much more secure than the use of a single method alone. (e.g. token + PIN, smartcard + fingerprint, etc.)

5 Der Zugang zum Computer soll nur derjenigen Person erlaubt werden, welche das zur Identifikation (zum Username) passende Passwort eingeben kann. Bei der Erstellung eines Benutzer-Accounts wird auf dem Computer das Passwort mit einer Einwegfunktion verschlüsselt. Der resultierende “Passwort-Hash” wird in einem File zusammen mit dem Benutzernamen (Username) abgelegt. Bei jedem Login des Benutzers berechnet das System aus dem eingegebenen Passwort mit Hilfe der Einwegfunktion den Passwort- Hash (PW-Hash) und vergleicht diesen mit dem zum eingegebenen Benuternamen passenden Passwort-Hash im Passwort-File.

Wo die jeweiligen Passwortfiles abgelegt sind und welche Einwegfunktionen zum Einsatz kommen, hängt vom Betriebssytem ab, ist aber öffentlich bekannt.

6 For compatibility reasons on NT and W2K systems all passwords are stored in both formats: as NT password hash as well as LANmanager password hash.

Note: NT distinguishes small and capital letters in the passwords, LANmanager doesn‟t i.e. it converts all password characters to capital letters. Hence, if LANmanager compatibility is enabled, using small and capital letters for passwords does not really improve security.

Windows NT, Windows 2000, and Windows Server 2003 can be configured to eliminate both the storage and use of LM hashes.

7

8 Vulnerability #1: Secret password openly transmitted over insecure channel • Remote login using the still popular telnet protocol requires the transmission in the clear of the remote user„s identity and password to the host computer. As long as this happens over a direct dial-in telephone line this procedure is relatively secure since it is not so trivial to tap a phone line. But as soon as the login happens from one host computer over the internet to another host, it becomes highly dangerous to send a secret password over such an insecure channel. Cryptographically safe mechanisms like e.g. the secure shell (ssh) should be used.

Vulnerability #2: Secret password residing on a server storage medium • Another problem is the secure storage of user passwords on login servers. Since servers usually operate without human intervention, secrets residing on a server cannot be protected by encrypting them with a passphrase. Making the secrets root-readable only offers a certain protection, but as soon as an intruder gains root status all secrecy is lost. • The original UNIX system did not store the user passwords themselves but a DES hash of them. Since UNIX passwords were restricted to 8 ASCII characters, a dictionary attack could be used by precomputing the hash values of several millions of the most popular passwords. By adding a 12 bit random salt value to the password prior to the hashing process, 4096 different hash variants of the same password could be created, multiplying the storage requirements for a precomputed dictionary attack by this salt factor. With today„s hard disk capacities of several gigabytes, this amont of salting does not pose a serious obstacle for a cracker anymore. • Therefore modern UNIX-like systems compute an iterative MD5 ($1$), SHA-256 ($5$) or SHA-512 ($6$) hash of the password which can have an unlimited number of characters plus a salt string of arbitrary length. Source: http://en.wikipedia.org/wiki/Crypt_(Unix)

9

10 11 Why Challenge/Response Protocols? • The proper way of doing an authentication over an insecure channel is to use a challenge / response protocol which checks if a user requesting access to a server is in possession of a personal secret authenticating her, without actually exchanging any secret information over the open channel.

Challenge/Response Protocols using Message Authentication Codes (MACs) • This method uses a common secret key shared between the user and the server. Every time a user wants to log into a server, the server sends a challenge to the user in the form of a random value or „nonce“. In order to prevent replay attacks a challenge string should never be used twice !

• The user creates a response by concatenating the random value RS received from the server with her user ID and then feeding this string into a keyed hash function initialized with the secret key. In order to thwart any attempts of an attacker to gain only the slightest information about the secret key by sending controlled sequences

of challenge strings, the user adds a random number RU of his own into the hashing process. • The user sends her ID string together with the random number she chose and the generated MAC to the server. Under the assumption that the MAC algorithm cannot be inverted, the transmitted data does not disclose any information about the secret key to potential attackers listening in to the channel. • Since the server has now exactly the same information as the user, i.e. user ID, server nonce, user nonce and secret key, it computes the MAC value as well and compares the result to the MAC transmitted by the user. The user is successfully authenticated if the two values match.

12 Challenge/Response Protocols using Public Key Digital Signatures • Challenge/response protocols can also be based on digital signatures using public key algorithms. The user is the sole possessor of the private key, whereas any potential server has a copy of the corresponding public key.

• The user forms a hash value out of her user ID, the random value RS received from the server as a challenge and a random value RU of her own choice. By encrypting the hash value with her private key the user forms a digital signature that is sent back as a response to the server. • It is of utmost importance that the user contributes some random value of her own to the hashing process. Otherwise the challenge string could be abused to trick the user e.g. into blindly signing a document or even to make her decrypt a secret message that has been encrypted using the user„s public key. If RSA is used for the signatures, certain attacks become possible that can even reveal the private key.

Can public keys be trusted? • Public key cryptosystems have become popular because the public key does not have to be kept secret and can therefore be published and distributed freely. So when a server authenticates a user by verifying the user signature on the basis of the user„s public key, the question remains whether the public/private key pair used in the authentication process really belongs to this user. • If a public key used in an authentication process is fetched from a public directory using an open communications channel, a „man-in-the-middle“ attack can easily replace the original key with a public key generated by the attacker. • This is where certificates come into play. Certificates establish a reliable and trusted link between a user identity and a public key. The trust mechanisms involved will be presented on the following slides.

13 14 15 16 17 18 19 KDC Key Management • Every principal has a secret master key registered with the KDC • User master keys are usually derived from a login password • Machine master keys must be configured on the host • All master keys of the principals are stored in the KDC database, encrypted by using the KDC master key. KDC Physical Security • Because all master keys reside in the KDC, the server which is hosting the KDC service must me physically secured by locking it away in a burglar-proof room.

20 21 Disadvantages of the simplified Kerberos protocol •The principal's master key must be used every time a server must be accessed and a ticket must be issued by the KDC (especially if the lifetime of the ticket is very short). • This means that either the user password must be typed in for every time a ticket request must be sent to the KDC • or alternatively, the principal's master key must be kept in temporary storage which might pose a security risk. Solution: Long-lived Ticket-Granting Ticket • The KDC issues for each user an individual session key and a ticket-granting ticket (TGT) with a typical lifetime of 8-24 hours, so that the entry of the user password is required less often.

22 Security risks • The initial Kerberos authentication message can be sniffed and an offline dictionary attack can be run to crack weak user login passwords. If successful the attacker will be in the possession of the principal's master key. Improvements • Kerberos v5 supports the alternative PKINIT authentication method based on RSA public key pairs that can be securely stored on a smartcard or USB token.

23 Advantages of the Ticket Granting Service • The Kerberos Authentication Service requiring the principals' master keys and the Ticket Granting Service based on the principals' Ticket Granting Tickets can be run on separate servers thus improving the performance.

24 25 KDC Replication • The entire Master KDC database is periodically downloaded to the Slave KDCs • The Slave KDC databases are read-only.

26 27 28 29

30

31

32

33

34

35

36