1. Internet Security 1 (IntSi1)
10 Identity and Access Management (IAM)
Prof. Dr. Peter Heinzmann Prof. Dr. Andreas Steffen Dr. Nathalie Weiler* Institute for Internet Technologies and Applications (ITA)
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
* Zürcher Hochschule Winterthur, currently with Credit Suisse

2. Controlled Access is needed to ...
One Computer (Sign-On, Logon)
Many Computers (Single Sign-On, SSO)
Applications (Telnet, Secure Shell, ftp, library catalog)
Mailbox (POP3, IMAP)
Web-Editing (FrontPage)
Web-Pages (.htaccess)
....
Rooms, areas, ...

3. 2. Authorization (Access)
Authentication, Authorization, Accounting (AAA)
0. Identification
I am: "Username"
asteffen
Username:
Password:
Authentication
Prove, that I am "Username"
********
3. Accounting
User
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.
2. Authorization (Access)

4. Internet Security 1 (IntSi1)
10.1 Basic Authentication Schemes

5. Authentication is based on ...
What you know (password, PIN, shared secret)
ask for something only the authorized user knows
Username:
aznHu4Um
Password:
asteffen
What you have (Certificate, Token, Scratch List)
test for the presence of something only the authorized user has
01 Z4GH IKDX 02 67TS PL7 03 UR2A 08 NFLB 04 TIQV K91D 05 3Z5P HA85
What you are (biological pattern, e.g. fingerprint)
non-forgeable biological or behavioral characteristics of the user
There are three ways to authenticate the identity of a user:
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.
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).
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.)
Face
Iris/Retina Scanning
Fingerprint
Voice

6. Username Password H(PW) PW-Hash PW-Hash Username Password-File
Local Windows/Unix Logon Process
Username
Password
Username:
asteffen
Password:
********
Domain:
local
H(PW)
One-Way Function
PW-Hash
WinXP: \WINDOWS\system32\config\SAM
SAM = Security Account Manager (permanent file lock)
Unix: /etc/passwd (User IDs) /etc/shadow (Password Hashes)
Username
PW-Hash
Password-File
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. NT and LANmanager Password Schemes
NTLM Password Hash
Hash function: MD4
LM Password Hashes
Hash function: DES
14 characters with 14 Bit per character (Unicode characters)
Two times 7 characters with 8 Bit per character, capital characters only
16 bytes NTLM Hash
first 8 bytes of LM hash (Characters )
second 8 bytes of LM hash (Characters )
= 0xAAD3B435B51404EE
if password has less than 8 characters
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. Offline Attacks on LM & NTLM Hashes

9.  Unix Password Schemes User ID Password ID Password Host Salt
DES Hash Function
Hash
andi:zM0qKKIURkwh.:12739:0:99999:7:0:: 
/etc/shadow Password File ID
Password
Hash
DES Hash Function
Salt
Salt helps against precomputed tables. UNIX uses 12 bits of salt, resulting in 4096 hashed password variants.
Optional MD5 hash allows passwords and passphrases > 8 characters.
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, 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:
Password
Salt
tpw:$1$Or6ur$eUbm5V2.meW3v7xkBtA77.:

10. Typical Attacks on Passwords
Social engineering
Password guessing
Check for „well known“ passwords
Password cracking (systematic password trying)
Dictionary attack based on word lists (several languages, LOTR, etc.)
Words with permutations and some special characters (rules)
Exhaustive search (brute force)
Precomputed Tables (Rainbow)
Tools: Cain & Abel, John the Ripper
Password sniffing
Sniffing and setting triggers (e.g. on „login“ or „password“)
Keystroke monitoring
TTY watcher, keystroke recorder (HW/SW)
Trojan horse „faked login screen“
Phishing (Redirection to malicious host)

11. Internet Security 1 (IntSi1)
10.2 Challenge / Response Protocols

12. Secure Authentication based on Challenge/Response Protocols
Insecure Channel
User
Server
Keyed Hash Function
MAC
IDU RU
Key RS
Challenge
random value (Nonce) RS
Key
Keyed Hash Function
MAC RU
IDU
Response
MAC
No secrets are openly transmitted
The random values RS and RU must not be repeated !
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 Protocol based on Digital Signatures
Insecure Channel
User
Server
IDU RU
Hash RS
Challenge
random value (Nonce) RS
Hash
IDU RU
Response
Sig
Sig
Encryption with Private Key
Decryption with Public Key
Hash 
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. Internet Security 1 (IntSi1)
10.3 Windows NT LAN Manager NTLM

15. Windows Domain Authentication
A Domain is a collection of Services ( , File-Shares, Printers, ...) administered by a Domain Controller (DC).
Centralized Administration:
Each user has only one account per Domain managed by the Domain Controller.
Thus there is no need for individual Server accounts.
Flexibility:
Assignment of Users to Groups
Multiple Domains possible (Master-Domains, Trust Relationships)
All users and servers must trust the Domain Controller.
User A
Printer
Server 1
Server 3
Server 2
User B
Domain
Domain
Controller (DC)

16. NTLM – Protocol
Domain:
Wonderland
Username:
Alice
Password:
2Uh7&
User Alice: KeyA
Alice
Alice, f68ba0537, 51ff1d83
f68ba0537 OK
51ff1d83
User Alice
Server
Domain
Controller (DC)
H(2Uh7&) = KeyA E(f68ba0537, KeyA) = 51ff1d83
Challenge: f68ba0537
E(f68ba0537, KeyA) = 51ff1d83 Comparison with 51ff1d83 – ok?
H: Hash function E(x, k): Encryption of x with key k
Windows NT LAN Manager is a proprietary Microsoft scheme.
Typical example of a Challenge-Response protocol.

17. NTLM Security Analysis
User key is known to the user and DC only
The user key is derived from the user's login password.
Only the entitled user can correctly encrypt the challenge.
Non-recurring challenge values (nonces) prevent replay-attacks.
Pros:
Password is never transmitted in the clear.
Simple and secure protocol if strong user passwords are used.
Cons:
The authentication process must be repeated for every use of a server  DC can become a bottleneck.
Weak or short NTLM passwords can be cracked offline with a dictionary or brute force attack.

18. Internet Security 1 (IntSi1)
10.4 Kerberos Key Distribution System

19. Historical Background
Developed in 1983 as part of MIT's Athena project.
Motivation:
Many MIT students „sniffed“ the network and thus got hold of root passwords which they used to reboot the servers.
Requirements:
Authentication in UNIX-based TCP/IP networks
Use of symmetrical cryptography (DES)
Characteristics:
Relies on the mediation services of a trusted referee or notary.
Based on the work by Needham and Schroeder on trusted third-party protocols as well as Denning and Sacco's modifications of these.
Kerberos Releases
Current release is Kerberos v5 (RFC 1510, September 1993).
V5 supports additional encryption ciphers besides DES.

20. Mediated Authentication by means of a Key Distribution Center (KDC)
Bob
Jack
Jip
Mary
Paul
Peter
Harry
Dick
Tom
Alice
Kbob
Kalice
KDC
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. How is Alice going to talk to Bob?
Kerberos Tickets
Each Kerberos participant (Alice, Bob, etc.) – called a Principal – shares a common secret with the Key Distribution Center (KDC) – the Principal’s Master Key.
Each secured communication or secured access is "mediated" by means of a Kerberos Ticket.
How is Alice going to talk to Bob?

22. Simplified Kerberos Protocol
Realm: Wonderland Username: Alice Password: 2Uh7&
User Alice: MKeyA Server Bob: MKeyB
Alice, Bob, a5F113de
9abc571a, Ticket
5cc10981, Ticket
User Alice
KDC
H(2Uh7&) = MKeyA E(time, MKeyA) = a5F113de
D(a5F113de, MKeyA) = time, valid? Session key Alice-Bob: SAB E(SAB, MKeyA) = 9abc571a E({ Alice, SAB }, MKeyB) = Ticket
D(9abc571a, MKeyA) = SAB E({ Alice, time }, SAB) = 5cc10981
MKeyB
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 hours, so that the entry of the user password is required less often.
Server Bob
H: Hash function E(x, k): Encryption of x with key k D(x, k): Decryption of x with key k
D(Ticket, MKeyB) = { Alice, SAB } D(5cc10981, SAB) = { Alice, time } correct?

23. Kerberos Protocol – Authentication Service Session Key and Ticket-Granting Ticket (TGT)
Realm: Wonderland Username: Alice Password: 2Uh7&
User Alice: MKeyA Server Bob: MKeyB
AS_REQ [Alice, a5F113de]
AS_REP [27LnZ8vU]
User Alice
KDC
H(2Uh7&) = MKeyA E(time, MKeyA) = a5F113de
D(a5F113de, MKeyA) = time, valid? Session key for Alice: SA E({ Alice, SA }, MKeyKDC) = TGTA E({ SA, TGTA }, MKeyA) = 27LnZ8vU
D(27LnZ8vU, MKeyA) = { SA, TGTA }
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.
H: Hash function E(x, k): Encryption of x with key k D(x, k): Decryption of x with key k

24. Kerberos Protocol – Ticket Granting Service Requesting a ticket for accessing server Bob
Session Key: SA Ticket: TGTA
Server Bob: MKeyB
TGS_REQ [Bob, TGTA, qR71htp9]
TGS_REP [b22sYG1k]
User Alice
KDC
E({ Alice, time }, SA) = qR71htp9
D(TGTA, MKeyKDC) = { Alice, SA } D(qR71htp9, SA) = { Alice, time }, valid? Session key for Alice-Bob: SAB E({ Alice, SAB }, MKeyB) = TAB E({ SAB, TAB }, SA) = b22sYG1k
D(b22sYG1k, SA) = { SAB, TAB }
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.
H: Hash function E(x, k): Encryption of x with key k D(x, k): Decryption of x with key k

25. Kerberos Protocol – Client/Server Authentication Accessing server Bob
Session Key: SAB Ticket: TAB
AP_REQ [TAB, w86EQa55]
MKeyB
AP_REP [4tMJs73c]
User Alice
Server Bob
E({ Alice, timeA }, SAB) = w86EQa55
D(TAB, MKeyB) = { Alice, SAB } D(w86EQa55, SAB) = { Alice, time }, valid? E({ Bob, timeB }, SAB) = 4tMJx73c
D(4tMJx73c, SAB) = { Bob, timeB }, valid?
H: Hash function E(x, k): Encryption of x with key k D(x, k): Decryption of x with key k

26. Realm KDC Replication Slave KDC Slave KDC Master KDC Slave KDC
Host
Host
Host
Host
Slave KDC
Host
Host
Host
Host
Host
Host
Master KDC
{db; MKeyKDC}
Slave KDC
Host
Host
Host
Host
Host
Host
Host
Host
Host
Host
Slave KDC
Host
Host
Host
Host
Host
Slave KDC
Host
KDC Replication
• The entire Master KDC database is periodically downloaded to the Slave KDCs • The Slave KDC databases are read-only.
Host
Realm
Host
Host

27. Inter-Realm Authentication
Wonderland
KDC
Lions
KDC
1. TGS_REQ
2. TGS_REP [credentials for Lions KDC]
3. TGS_REQ
4. TGS_REP [credentials for
Realm Lions
Realm Wonderland
Carol
Alice
5. AP_REQ [Alice, KA{KBA, “Alice”,...}]

28. Summary Ticket Granting Service Kerberos Authentication Client Server
1. authenticate user
2. access control for server
3. communication

29. Internet Security 1 (IntSi1)
10.5 Single Sign-On

30. Single Sign-On (SSO)
80% of helpdesk calls are password-related. Single sign-on systems could enable a company to reduce its helpdesk by 40% savings of nearly $4.4 million for company with 20'000 users. Forrester Research

31. Workflow-Based User Provisioning

32. Example: Novell Identity Manager

33. Synchronized Data View using a Meta-Directory

34. Meta Directories Standardized, consistent view Meta Directory Sync
Customized
Connectors
LDAP DB
Flat File
Meta directories contain information replicated from various source directories.
Constant synchronization with the source directories guarantees the consistency between original and copy.

35. Modified LDAP response
Virtual Directories
Modified LDAP request
LDAP request
LDAP
Broker
Agent
Client
Modified LDAP response
LDAP response
LDAP
Server
Virtual Directory
Virtual directories provide access to the existing data sources without moving the data out of the original repository.
Virtual directories act as a proxy between an LDAP server and a client. Configurable modules allow data to be manipulated during the transfer.

36. Identity and Access Management (IAM)
Enterprise Information Architecture
Identify key business processes and determine the applications, information assets and transactions critical to meeting its business goals.
Define which users need what resources and at what level of security.
Permission and Policy Management
Establish and enforce policies governing the access control rights of users. Single sign-on (SSO) procedures facilitate the access to all applications a user is entitled to use.
Entreprise Directory Services
Use the Lightweight Directory Access Protocol (LDAP) to access an organization's central repository of user identies and access privileges, as well as applications, information, network resources and more.
User Authentication
The use of a Public key infrastructure (PKI) is the preferred mechanism.
Workflow-Based User Provisioning
Provisioning deploys access rights for employees, customers and business partners. Automated workflow systems reduce tedious manual tasks.