Post on 25-Feb-2016
description
Authentication andIdentity Management
• Ideally– Who you are
• Practically– Something you know (e.g., password)– Something you have (e.g., badge)– Something about you (e.g., fingerprint)
Basis for Authentication
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
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
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
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
• 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
Public Key Authentication
• Passport• Shibboleth
Single Sign-On
• 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
• 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.
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 infousing key merchant shares with passport serverAlso set cookie at browser (passport)
• User interface is confusing and may misrepresent the reality – user may log out from a server but not from the Passport or vice versa
• 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
• 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
• 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
• 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
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 login1
2
3
4
5
7
7. I don’t know your attributes. Ask the IdP (peer to peer)
6
ClientWeb Browser
8
Source: Kathryn Huxtable khuxtable@ku.edu 10 June 2005
Shibboleth - Protocol
• Cards– Mag stripe (= password)– Smart card, USB key– Time-varying password
• Issues– How to validate– How to read (i.e. infrastructure)
Something You Have
• 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
• 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
Authorization and Policy
• Is principal P permitted to perform action A on object O?– Authorization system will provide yes/no answer
Authorization
• 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
Example ACMFile/User Tom Dick Harry
Readme.txt read read read, write
passwords write
Term.exe read, write, execute
• Access Control Lists (ACLs)– For each object, list principals and actions
permitted on that object– Corresponds to rows of ACM
Instantiations of ACMs
File
Readme.txt Tom: read, Dick: read, Harry: read, write
passwords Harry: write
Term.exe Tom: read, write, execute
• 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
• Discretionary• Mandatory • Rule-based• Role-based• Originator-controlled
Types of Access Control
• Owners control access to objects• Access permissions based on identity of
subject/object• E.g., access to health information
Discretionary 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
Mandatory 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
Role-Based Access Control
• Final goal of security– Determine whether to allow an operation
• Depends upon– Policy– Authentication
Authorization
• 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)
Policy
• 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
• 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
Policy models: Bell-LaPadula
• Only concerned about integrity– a subject at a given clearance may not write an object
at a higher classification (no write-up)– a subject at a given clearance must not read any
object at a lower classification (no read-down) • Reverse from Bell-LaPadula
– as if content with lower integrity pollutes subjects at higher integrity
Policy models: Biba
• 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
SECURITYAUDIT
RECORDS
GAA: Generic Authentication and Authorization Architecture
INTRUSIONDETECTION
UNDERATTACK
GAA APIEACL
. . .
Authentication
Databases
Web Servers
Firewalls
IPSec
…
• 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
• Positive and negative access right• Conditions on each rule - evaluated in a given
order– 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: Extended ACLs
• From 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
Sample EACL
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
• 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
Scenario - LockDown You have an isolated local area
network with mixed access to web services (some clients authenticated, some not).
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.
• 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