1

10 Identity and Access Management

• Authentication, 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 Kerberos 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

2

3

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.

4

5

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.)

6

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.

7

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.

8

9

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)

10

11

12

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.

13

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.

14

15

16

17

18

19

20

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.

21

22

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.

23

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.

24

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.

25

26

KDC Replication

• The entire Master KDC database is periodically downloaded to the Slave KDCs

• The Slave KDC databases are read-only.

27

28

29

30

31

32

33

34

35

36