3. • Goal is single sign-on
– Solves problem of weak or repeated user/pass
combinations
• Implemented via redirections
– Users authenticate themselves to a common server,
which gives them tickets
– Similar flavor to Kerberos but different environment
– many organizations
• Widely deployed by Microsoft
– Designed to use existing technologies in
servers/browsers (HTTP redirect, SSL, cookies,
Javascript)
Passport v1
4. • Client (browser), merchant (Web server),
Passport login server
• Passport server maintains authentication
info for client
– Gives merchant access when permitted by client
• Divides client data into profile (address) and
wallet (credit card)
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.
5. 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 = 3DES encrypted authentication info
using key merchant shares with passport server
Also set cookie at browser (passport)
6. • 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
How Cookies Work
7. • 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
…
Cookies for Authentication
Learn more at:
http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf
8. • User interface is confusing and may misrepresent
the reality – user may log out from a server but not
from the Passport or vice versa
• Weak keys may be used for 3DES
• Single key is used to encrypt cookies for all clients
• Cookies stay on machine, can be stolen
– No authenticator (timestamp) like in Kerberos, enables
reuse by others
Some Problems with Passport
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.
Read more at http://avirubin.com/passport.html
9. • Multiple federated identity providers
– E.g. ISPs register own users
– One can rely on claims made by other ID providers
• Claims
– Emails, relationships, authorization for scenarios,
ownership of private/public key pair
• Need “translators” for different claim languages
Federated Passport
10. • Similar to Federated Passport, i.e. no
central authority
• Use SAML (Security Association Markup
Language) to describe trust across
authorities, and what assertions mean from
particular authorities
• Four assurance levels
– How much we trust a given identity assertion
– Little, some, high and very high confidence
Liberty Alliance
11. • 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
Federated Identity - Shibboleth
12. 6. I know you now.
Redirect to SP, with a
handle for user
8. Based on attribute
values, allow access to
resource
Identity Provider
(IdP)
Web Site
Service Provider (SP)
Web Site
1. User requests
resource
2. I don’t know you, or
where you are from
LDAP
WAYF
3. Where are you from?
4. Redirect to IdP for your org
5. I don’t know you.
Authenticate using your
org’s web login
1
2
3
4
5
7
7. I don’t know your attributes. Ask
the IdP (peer to peer)
6
Client
Web Browser
8
Source: Kathryn Huxtable khuxtable@ku.edu
10 June 2005
13. • Common API for client-server authentication
• Standard interface for choosing among
authentication methods
– Once an application uses GSS-API, it can be changed
to use a different authentication method easily
• No code rewriting required
• Dominant implementation is Kerberos
– Some procedure calls
• Acquire and release credentials
• Manage security context
– Init, accept, and process tokens (challenges)
• Wrap and unwrap (encrypt/decrypt)
Generic Security Services API
Moving up the Stack
14. • Brute force
• Dictionary
• Guessing
• Finding elsewhere
Attacks on Password Authentication
15. • Cards
– Mag stripe (= password)
– Smart card, USB key
– Time-varying password
• Issues
– How to validate
– How to read (i.e. infrastructure)
Something You Have
16. • Biometrics
– 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
Something About You
17. • IP Address
• Caller ID (or call back)
• Past transaction information
– Example of something you know
Other Forms Of Authentication
18. • Require at least two of the classes we
mentioned, e.g.
– Smart card plus PIN
– RSA SecurID plus password
– Biometric and password
Multi-factor Authentication
20. • Determining permission
– Is principal P permitted to perform action A on
object U?
• Adding permission
– P is permitted to perform action A on object U
• In this course, we use the first definition
Authorization: Two Meanings
21. • 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
Access Control
22. Example ACM
File/User Tom Dick Harry
Readme.txt read read read, write
passwords write
Term.exe read, write, execute
23. • Access Control Lists (ACLs)
– For each object, list principals and actions
permitted on that object
– Corresponds to rows of ACM
Instantiations of ACMs
File/User
Readme.txt Tom: read, Dick: read, Harry: read, write
passwords Harry: write
Term.exe Tom: read, write, execute
24. • 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…?
Instantiations of ACMs
User
Tom Readme.txt: read, Term.exe: read, write, execute
Dick Readme.txt: read
Harry Readme.txt: read, write; passwords: write
25. • Permissions may need to be determined
dynamically
– Time
– System load
– Relationship with other objects
– Security status of host
• Distributed nature of systems may aggravate this
– ACLs need to be replicated or centralized
– Capabilities don’t, but they’re harder to revoke
Problems
27. • Owners control access to objects
• Access permissions based on identity of
subject/object
• E.g., access to health information
Discretionary Access Control
28. • Rules set by the system, cannot be overriden
by owners
• Each object and subject has a category and a
classification
• Rules speak about how to match categories
and classifications
– Access is granted on a match
Mandatory Access Control
29. • Individual subjects are granted access to
objects if allowed by rules
• Rules are set by the system administrator
Rule-Based Access Control
30. • 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
Role-Based Access Control
31. • Creator of an object decides who will access it
• E.g., owner can listen to a song but cannot
share it with others
Originator-Based Access Control
32. • Final goal of security
– Determine whether to allow an operation
• Depends upon
– Policy
– Authentication
– Other characteristics
Authorization
33. • 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)
The Role Of Policy
34. • 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
Policy models: Bell-LaPadula
35. • Three security properties:
– Simple Security Property - a subject at a given
security level may not read an object at a higher
security level (no read-up)
– Star Property - a subject at a given security level must
not write to any object at a lower security level (no
write-down). Strong Star Property – only write to
same level
– The Discretionary Security Property - discretionary
access control specified via an access control matrix
• Trusted subjects - no star property rule
– Transfer info from high clearance to low clearance
Policy models: Bell-LaPadula
36. • Like Bell-LaPadula but speaks about integrity
• Cannot write to higher-level objects
• Subject’s integrity drops if it reads a lower-level
object
Policy Models: Biba
37. • Today’s security tools work with no coordinated
policy
– Firewalls and Virtual Private Networks
– Authentication and Public Key Infrastructure
– Intrusion Detection and limited response
• We need better coordination
– Not just who can access what, but policy says what
kind of encryption to use, when to notify IDS
• Tools should implement coordinated policies
– Policies originate from multiple sources
– Policies should adapt to dynamic threat conditions
– Policies should adapt to dynamic policy changes
Security > Mix Of Point Solutions
39. • Focus integration efforts on authorization and
the management of policies used in the
authorization decision
– Applications shouldn’t care about authentication or
identity
• Separate policy from mechanism
– Authorization may be easier to integrate with
applications
– Hide the calls to individual security services
• E.g. key management, authentication, encryption, audit
GAA: Integration Through Authorization
40. • Positive and negative access right
• Conditions on each rule - evaluated in a given
order
• Sample ACL (http://gost.isi.edu/info/gaaapi/eacl.html)
– Tom cannot login to the host
– Logins from the specified IP address range are
permitted, using either X509 or Kerberos for
authentication if previous login attempts <= 3. If the
request fails, the number of the failed logins should
be updated. The connection duration < 8 h.
– Anyone, without authentication, can check the status
of the host if his IP is in specified range
– Host shut downs are permitted, using Kerberos for
authentication. On success, the user ID must be
logged. On failure, the sysadmin is sent an e-mail
GAA: Extended ACLs
41. • Pre-conditions
– What must be true in order to grant request
• Request-result
– These conditions must be activated regardless of
whether the access is granted or not
• Mid-conditions
– What must be true during execution of requested
operation
• Post-conditions
– What must be true on completion of requested
operation.
GAA: Conditions
42. Three Phases of Condition Evaluation
GAA-API
a.isi.edu, connect, Tom
gaa_check_authorization() T/F/U
System State
EACL gaa_get_object_policy_info()
gaa_post_execution_actions() T/F/U
gaa_execution_control() T/F/U
43. • Dynamic policy evaluation enables response to
attacks:
– Lockdown system if attack is detected
– Establish quarantines by changing policy to establish
isolated virtual networks dynamically
– Allow increased access between coalition members
as new coalitions are formed or membership
changes to respond to unexpected events
What Dynamic Policies Enable
44. Scenario - LockDown
You have an isolated local area
network with mixed access to web
services (some clients authenticated,
some not).
45. Scenario - LockDown
You have an isolated local area
network with mixed access to web
services (some clients authenticated,
some not).
You need to allow incoming
authenticated SSH or IPSec
connections.
46. • You have an isolated local area
network with mixed access to web
services (some clients authenticated,
some not).
• You need to allow incoming
authenticated SSH or IPSec
connections.
• When such connections are active,
you want to lock down your servers
and require stronger authentication
and confidentiality protection on all
accesses within the network.
Scenario - LockDown
48. Disclaimer
• Some techniques and tools mentioned in this class
could be:
– Illegal to use
– Dangerous for others – they can crash machines
and clog the network
– Dangerous for you – downloading the attack code
you provide attacker with info about your machine
• Don’t use any such tools in real networks
– Especially not on USC network
– You can only use them in a controlled
environment, e.g. DETER testbed
Dangerous
49. Intrusions
• Why do people break into computers?
• What type of people usually breaks into computers?
• I thought that this was a security course. Why are we
learning about attacks?
