Lecture 4 - CCSS

utterlypanoramicΑσφάλεια

30 Νοε 2013 (πριν από 3 χρόνια και 6 μήνες)

90 εμφανίσεις

Authentication and

Identity 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

x
0=
h(R
)
, x
1=
h(h(R
))
, x
2=
h(h(h(R
)))
,..., x
100


Alice keeps this list, host sets her password to x
101


Alice logs on with x
100
, host verifies
h(x
100
)=x
101
,
resets password to x
100


Next time Alice logs on with x
99


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 info

using key merchant shares with passport server

Also 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 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


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 ACM

File/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


a
s 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

SECURITY

AUDIT

RECORDS

GAA: Generic Authentication and
Authorization Architecture

INTRUSION

DETECTION

UNDER

ATTACK

GAA API

EACL

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
T
hrough
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