1. Key Management

2. Shared Key Exchange Problem
How do Alice and Bob exchange a shared secret?
Offline
Doesn’t scale
Using public key cryptography (possible)
Using specially crafted messages (Diffie-Hellman)
Using a trusted third party (KDC)
Secrets should never be sent in clear
We should prevent replay attacks
We should prevent reuse of old keys

3. Diffie-Hellman Key Exchange
Exchange a secret with someone you never met while shouting in a room full of people
Alice and Bob agree on g and large n
Alice chooses random a, sends
Bob chooses random b, sends
Alice takes Bob’s message and calculates
Bob does the same; now they both know shared secret

4. KDC Based Key Distribution
Building up to Needham Schroeder/Kerberos
User sends req. to KDC (key distrib. center)
KDC generates a shared key: Kc,s
Keys KKDC,C and KKDC,S are preconfigured
No keys ever traverse net in the clear
Why are identities in tickets?
1. C, S
3. EKKDC,S{C, Kc,s} C
KDC S
ticket
2. EKKDC,C{S, Kc,s}

5. KDC Based Key Distribution
KDC does not have to talk both to C and S
Messages 2 or 3 can be replayed by Mallory
Force C and S to use same secret for a long time
Cause S to have an old ticket, break comm. w C
ticketS = EKKDC,S{C, Kc,s}
1. C, S C
KDC S
2. EKKDC,C{S, Kc,s}, ticketS
3. ticketS

6. Needham-Shroeder Key Exchange
Use nonces to prevent replay attacks
ticketS = EKKDC,S{C, Kc,s}
1. N1, C, S C
KDC S
2. EKKDC,C{N1, S, Kc,s, ticketS}
3. EKC,S{N2}, ticketS
4. EKC,S{N2-1, N3}
5. EKC,S{N3-1}

7. Problem What happens if attacker gets session key?
Can reuse old session key to answer challenge-response, generate new requests, etc
Need timestamps to ensure freshness = tickets expire after some time

8. Solution Introduce Ticket Granting Server (TGS)
Daily ticket plus session keys
Authentication server (AS) authenticates users
TGS+AS = KDC
This is modified Needham-Schroeder
Basis for Kerberos

9. Kerberos C S Third-party authentication service
Distributes session keys for authentication, confidentiality, and integrity
TGS
4. TGSRep
3. TGSReq AS
2. ASRep
1. ASReq C S
5. SReq

10. Kerberos ASReq = userID, TGS, lifetime1
Kuser = f(passuser)
ASReq = userID, TGS, lifetime1
TTGS = EKAS,TGS(TGS, C, KTGS,C, timestamp1, lifetime2)
ASRep = EKuser(KTGS,C, TGS, timestamp2, lifetime2), TTGS
TGSReq = TTGS, EKTGS,C(C, timestamp3), S, lifetime3
TS = EKS,TGS(S, C, KS,C, timestamp4, lifetime4)
TGSRep = TS, EKC,TGS(KS,C, S, timestamp5, lifetime4)
SReq = EKC,S{C, timestamp6}, TS

11. Public Key Exchange Problem
How do we verify an identity:
Alice sends to Bob her public key Pub(A)
Bob sends to Alice his public key Pub(B)
How do we ensure that those keys really belong to Alice and Bob? Need a trusted third party

12. Man-in-the-Middle Attack On Key Exchange
Alice sends to Bob her public key Pub(A)
Mallory captures this and sends to Bob Pub(M)
Bob sends to Alice his public key Pub(B)
Mallory captures this and sends to Alice Pub(M)
Now Alice and Bob correspond through Mallory who can read/change all their messages

13. Public Key Exchange Public key is public but …
How does either side know who and what the key is for?
Does this solve key distribution problem?
No – while confidentiality is not required, integrity is
Still need trusted third party
Digital certificates – certificate authority (CA) signs identity+public key tuple with its private key
Problem is finding a CA that both client and server trust

14. Digital Certificates Everyone has Trent’s public key
Trent signs both Alice’s and Bob’s public keys – he generates public-key certificate
When they receive keys, verify the signature
Mallory cannot impersonate Alice or Bob because her key is signed as Mallory’s
Certificate usually contains more than the public key
Name, network address, organization
Trent is known as Certificate Authority (CA)

15. Certificate-Based Key Exchange
Authentication steps
Alice provides nonce, or a timestamp is used instead, along with her certificate.
Bob selects session key and sends it to Alice with nonce, encrypted with Alice’s public key, and signed with Bob’s private key. He sends his certificate too
Alice validates certificate – it is really Bob’s key inside
Alice checks signature and nonce – Bob really generated the message and it is fresh

16. PGP Pretty Good Privacy “Web of Trust”
Public key, identity association is signed by many entities
Receiver hopefully can locate several signatures that he can trust
Like an endorsement scheme

17. SSH User keys installed on server out of band
User logs in with a password
Copies her public key onto server
Weak assurance of server keys
User machine remembers server keys on first contact
Checks if this is still the same host on subsequent contact
But no check on first contact

18. Recovery From Stolen Private Keys
Revocation lists (CRL’s)
Long lists
Hard to propagate
Lifetime / Expiration
Short life allows assurance of validity at time of issue
Real time validation
Receiver of a certificate asks the CA who signed it if corresponding private key was compromised
Can cache replies

19. Authentication and Identity Management

20. Basis for Authentication
Ideally
Who you are
Practically
Something you know (e.g., password)
Something you have (e.g., badge)
Something about you (e.g., fingerprint)

21. Password Authentication
Alice inputs her password, computer verifies this against list of passwords
If computer is broken into, hackers can learn everybody’s passwords
Use one-way functions, store the result for every valid password
Perform one-way function on input, compare result against the list

22. Password Authentication
Hackers can compile a list of frequently used passwords, apply one-way function to each and store them in a table – dictionary attack
Host adds random salt to password, applies one-way function to that and stores result and salt value
Randomly generated, unique and long enough

23. Password Authentication
Someone sniffing on the network can learn the password
Lamport hash or S-KEY – time-varying password
To set-up the system, Alice enters random number R
Host calculates x0=h(R), x1=h(h(R)), x2=h(h(h(R))),..., x100
Alice keeps this list, host sets her password to x101
Alice logs on with x100, host verifies h(x100)=x101, resets password to x100
Next time Alice logs on with x99

24. Password Authentication
Someone sniffing on the network can learn the password
Host keeps a file of every user’s public key
Users keep their private keys
When Alice attempts to log on, host sends her a random number R
Alice encrypts R with her private key and sends to host
Host can now verify her identity by decrypting the message and retrieving R

25. Authentication With Symmetric Key
Server sends random number R
Client encrypts with symmetric key, sends back or
Server sends random number R, encrypted with symmetric key
Client decrypts, sends back
Client decrypts, sends back R-1, encrypted with symmetric key

26. Authentication With Public Key
Server sends random number R
Client encrypts with private key, sends back or
Server sends random number R, encrypted with public key of client
Client decrypts, sends back

27. Authentication With Public Key
Key Distribution
Confidentiality not needed for public key
Can be obtained ahead of time
Performance
Slower than conventional cryptography
Implementations used for key distribution, then use conventional crypto for data encryption
Trusted third party still needed
To certify public key
To manage revocation

28. Single Sign-On
Passport
Shibboleth

29. Passport Goal is single sign-on Implemented via redirections
Solves problem of weak or repeated user/pass combinations
Implemented via redirections
Users authenticate themselves to a common server, which gives them tickets
Widely deployed by Microsoft
Designed to use existing technologies in servers/browsers (HTTP redirect, SSL, cookies, Javascript)

30. David P. Kormann and Aviel D. Rubin,
Risks of the Passport Single Signon Protocol,
Computer Networks, Elsevier Science Press, volume 33, pages 51-58, 2000.
How Passport Works
Client (browser), merchant (Web server), Passport login server
Passport server maintains authentication info for client
Gives merchant access when permitted by client

31. How Passport Works
David P. Kormann and Aviel D. Rubin,
Risks of the Passport Single Signon Protocol,
Computer Networks, Elsevier Science Press, volume 33, pages 51-58, 2000.
SSL
Token = encrypted authentication info using key merchant shares with passport server
Also set cookie at browser (passport)

32. How Cookies Work
Placed into browser cache by servers to store state about this particular user
Contain any information that server wants to remember about the user as name/value pairs
May contain expiration time
May persist across browser instances
Returned to server in clear on new access
Only those cookies created for the server’s domain are sent to the server
May not be created by this server
Usually used for persistent sign in, shopping cart, user preferences

33. Cookies for Authentication
User logs in using her user/pass
Server sets a cookie with some info – username, password, session ID …
Any future accesses return this info to the server who uses it for authentication (equivalent to user/pass)
Once user signs out the cookie is deleted and the session closed at the server
Problems
Cookies can be sniffed, remain on the browser because user did not sign out, be stolen by cross-site scripting or via DNS poisoning
Solutions:
Send cookies over SSL, use timed cookies, secure code, bind cookies to IP address of the client, encrypt cookies …
Learn more at:

34. Federated Identity - Shibboleth
Service Provider
Browser goes to Resource Manager who uses WAYF, and user’s Attribute Requester, and decides whether to grant access.
“Where are you from” (WAYF) service
Redirects to correct servers
Federation to form trusted relationships between providers

35. Shibboleth - Protocol
2. I don’t know you, or where you are from
3. Where are you from?
Client
Web Browser
4. Redirect to IdP for your org
1. User requests resource
5. I don’t know you. Authenticate using your org’s web login 8 1 3 5
Service Provider (SP)
Web Site
WAYF
Identity Provider
(IdP)
Web Site 2 4
LDAP 6 7
6. I know you now. Redirect to SP, with a handle for user
8. Based on attribute values, allow access to resource
7. I don’t know your attributes. Ask the IdP (peer to peer)
Source: Kathryn Huxtable 10 June 2005

36. Something You Have Cards Issues Mag stripe (= password)
Smart card, USB key
Time-varying password
Issues
How to validate
How to read (i.e. infrastructure)

37. Something About You Biometrics Issues Measures some physical attribute
Iris scan
Fingerprint
Picture
Voice
Issues
How to prevent spoofing
What if spoofing is possible? No way to obtain new credentials

38. Multi-factor Authentication
Require at least two of the classes we mentioned, e.g.
Smart card plus PIN
RSA SecurID plus password
Biometric and password

39. Authorization and Policy

40. Authorization
Is principal P permitted to perform action A on object O?
Authorization system will provide yes/no answer

41. Access Control
Who is permitted to perform which actions on what objects?
Access Control Matrix (ACM)
Columns indexed by principal
Rows indexed by objects
Elements are arrays of permissions indexed by action
In practice, ACMs are abstract objects
Huge and sparse
Possibly distributed

42. Example ACM File/User Tom Dick Harry Readme.txt read read, write
passwords
write
Term.exe
read, write, execute

43. Instantiations of ACMs
Access Control Lists (ACLs)
For each object, list principals and actions permitted on that object
Corresponds to rows of ACM
File
Readme.txt
Tom: read, Dick: read, Harry: read, write
passwords
Harry: write
Term.exe
Tom: read, write, execute

44. Instantiations of ACMs
Capabilities
For each principal, list objects and actions permitted for that principal
Corresponds to columns of ACM
The Unix file system is an example of…?
User
Tom
Readme.txt: read, Term.exe: read, write, execute
Dick
Readme.txt: read
Harry
Readme.txt: read, write; passwords: write

45. Types of Access Control
Discretionary
Mandatory
Role-based

46. Discretionary Access Control
Owners control access to objects
Access permissions based on identity of subject/object
E.g., access to health information

47. Mandatory Access Control
Rules set by the system, cannot be overriden by owners
Each object has a classification and each subject has a clearance (unclassified, classified, secret, top-secret)
Rules speak about how to match categories and classifications
Access is granted on a match
19:59
19:59

48. Policy models: Bell-LaPadula
Focuses on controlled access to classified information and on confidentiality
No concern about integrity
The model is a formal state transition model of computer security policy
Describes a set of access control rules which use security classification on objects and clearances for subjects
To determine if a subject can access an object
Combine mandatory and discretionary AC (ACM)
Compare object’s classification with subject’s clearance (Top Secret, Secret, Confid., Unclass.)
Allow access if ACM and level check say it’s OK

49. Policy models: Bell-LaPadula
Mandatory access control rules:
a subject at a given clearance may not read an object at a higher classification (no read-up)
a subject at a given clearance must not write to any object at a lower classification (no write-down).
Trusted subjects – the “no write-down” rule does not apply to them
Transfer info from high clearance to low clearance

50. Role-Based Access Control
Ability to access objects depends on one’s role in the organization
Roles of a user can change
Restrictions may limit holding multiple roles simultaneously or within a session, or over longer periods.
Supports separation of roles
Maps to organization structure

51. Attribute-Based Access Control
Ability to access objects depends on attributes assigned to user and object, environment attributes, etc.
Attributes can have single value (clearance) or multiple values (project membership)
Example:
students can view their grades only during weekdays and for courses that they took less than 3 years ago

52. Authorization Final goal of security Depends upon
Determine whether to allow an operation
Depends upon
Policy
Authentication

53. Policy
Policy defines what is allowed and how the system and security mechanisms should act
Policy is enforced by mechanism which interprets it, e.g.
Firewalls
IDS
Access control lists
Implemented as
Software (which must be implemented correctly and without vulnerabilities)