Copyright © 1995-2002 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Advanced Operating Systems Lecture notes Dr.

Copyright © 1995-2002 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Advanced Operating Systems Lecture notes

Dr. Clifford Neuman

Dr. Dongho Kim

University of Southern California

Information Sciences Institute


Focus on Authorization

• Focusing on authorization and the management of policies used in the authorization decision.

– Not really new - this is a reference monitor.

– Applications shouldn’t care about authentication or identity.

▪ Separate policy from mechanism

– Authorization may be easier to integrate with applications.

– Hide the calls to the key management and authentication functions.


Generic Authorization and Access-control API

Allows applications to use the security infrastructure to implement security policies.

gaa_get_object_eacl function called before other GAA API routines which require a handle to object EACL to identify EACLs on which to operate. Can interpret existing policy databases.

gaa_check_authorization function tells application whether requested operation is authorized, or if additional application specific checks are required

Application

GAA API

input

output

gaa_get_ object_eacl

gaa_check_authorization

Yes,no,maybe

SC,obj_id,op


Credential transport (needed)

The GAA-API gets user & connection info from Security Context: Evaluated and unevaluated credentials Delegated authority Cross-calls to transport to retrieve additional

creds The security context is provided as:

– Output from GSS-API (requires many calls)– Credentials from transport or session protocols

–SSL, ARDP–Other extensions are needed:

– IPSec, pulled from Kernel, other extensions


Evaluation of credentials

POLICY

gaa_get_object_eacl


GAA API

AppEACL

. . .

GAA APISecurityContextGSS-API

LIBRARY

TransportMechanism

2 3

1 4

4a

6a

5

6

7

5a

6b


Integrating security services

The GAA-API calls must be made by applications.– This is a major undertaking, but one which must

be done no matter how one chooses to do authorization.

These calls are at the control points in the app– They occur at auditable events, and this is where

records should be generated for ID systems– They occur at the places where one needs to

consider dynamic network threat conditions.– Adaptive policies use such information from ID

systems.– They occur at the right point for billable events.


Electronic commerce

Some authorization policies do not require user authentication at all - just that an item is paid for.

– Policy specifies required payment.

– Cross call to credential transport retrieves payment credentials and grants access.

– If application used GAA-API, no change to the application is necessary, simply specify the payment policy instead of a more traditional identity based policy.


ID and Audit relation to GAA-API

SECURITYAUDIT

RECORDS

THREATCONDITION

UNDERATTACK

POLICY

gaa_get_object_eacl


GAA API

AppEACL

. . .

GAA APISecurityContextGSS-API

LIBRARY

TransportMechanism

2 3

1 4

4a

6a

5

6

7

5a

6b


Application based ID

Without the GAA-API– Convince each application developer to add calls

to audit functions in addition to all the other security calls they make (good luck). Of course it needs to do authentication too.

With the GAA-API– Get developers to use the GAA for authorization

decisions instead of making multiple calls to implement their own authorization database.

– Create module for GAA implementation that generates audit records according to policy.

– Write policy (inc. adaptive or credential based) that says when to generate audit records.


CSci555: Advanced Operating SystemsLecture 7 - October 10 and 11, 2002

Security Architecture

Dr. Clifford Neuman

University of Southern California

Information Sciences Institute


Key distribution

• Conventional cryptography

– Single key shared by both parties

• Public Key cryptography

– Public key published to world

– Private key known only by owner

• Third party certifies or distributes keys

– Certification infrastructure

– Authentication


Authentication w/ Conventional Crypto

• Kerberos

2

3

1

or Needham Schroeder

,4,5

KDC

C S


Authentication w/ PK Crypto

• Based on public key certificates

1

DS

SC

3

2


Kerberos

Third-party authentication service– Distributes session keys for authentication,

confidentiality, and integrity

TGS

4. Ts+{Reply}Kt

3. TgsReq

KDC

1. Req2. T+{Reply}Kc

C S5. Ts + {ts}Kcs


Public Key Cryptography (revisited)

• Key Distribution– Confidentiality not needed for public key– Solves n2 problem

• Performance– Slower than conventional cryptography– Implementations use for key distribution, then

use conventional crypto for data encryption• Trusted third party still needed

– To certify public key– To manage revocation– In some cases, third party may be off-line


Certificate-Based Authentication

Certification authorities issue signed certificates– Banks, companies, & organizations like

Verisign act as CA’s

– Certificates bind a public key to the name of a user

– Public key of CA certified by higher-level CA’s

– Root CA public keys configured in browsers & other software

– Certificates provide key distribution


Certificate-Based Authentication (2)

Authentication steps– Verifier provides nonce, or a timestamp is used

instead.

– Principal selects session key and sends it to verifier with nonce, encrypted with principal’s private key and verifier’s public key, and possibly with principal’s certificate

– Verifier checks signature on nonce, and validates certificate.


Secure Sockets Layer (and TLS)

Encryption support provided betweenBrowser and web server - below HTTP layer

Client checks server certificateWorks as long as client starts with the correct URL

Key distribution supported through cert stepsAuthentication provided by verify steps

C S

Attacker

Hello

Hello + CertS

{PMKey}Ks [CertC + VerifyC ]

VerifyS


Trust models for certification

• X.509 Hierarchical

– Single root (original plan)

– Multi-root (better accepted)

– SET has banks as CA’s and common SET root

• PGP Model

– “Friends and Family approach” - S. Kent

• Other representations for certifications

• No certificates at all

– Out of band key distribution

– SSH


Global Authentication Service

• Pair-wise trust in hierarchy

– Name is derived from path followed

– Shortcuts allowed, but changes name

– Exposure of path is important for security

• Compared to Kerberos

– Transited field in Kerberos - doesn’t change name

• Compared with X.509

– X.509 has single path from root

– X.509 is for public key systems

• Compared with PGP

– PGP evaluates path at end, but may have name conflicts


Capability Based Systems - Amoeba

“Authentication not an end in itself”• Theft of capabilities an issue

– Claims about no direct access to network– Replay an issue

• Modification of capabilities a problem– One way functions provide a good solution

• Where to store capabilities for convenience– In the user-level naming system/directory– 3 columns

• Where is authentication in Amoeba– To obtain initial capability


Capability Directories in Amoeba

BCN User Group Other

File1

File2

users

Katia User Group Other

File3

bcn

users

users User Group Other

BCN

Katia

tyao

Login Cap

BCN

Katia

tyao


Security Architectures

• DSSA – Delegation is the important issue

▪ Workstation can act as user▪ Software can act as workstation - if given key▪ Software can act as developer - if checksum

validated– Complete chain needed to assume authority– Roles provide limits on authority - new sub-principal

• Proxies - Also based on delegation– Limits on authority explicitly embedded in proxy– Works well with access control lists


Distributed Authorization

• It must be possible to maintain authorization information separate from the end servers– Less duplication of authorization database

– Less need for specific prior arrangement

– Simplified management

• Based on restricted proxies which support– Authorization servers

– Group Servers

– Capabilities

– Delegation


Proxies

• A proxy allows a second principal to operate with the rights and privileges of the principal that issued the proxy

– Existing authentication credentials

– Too much privilege and too easily propagated

• Restricted Proxies

– By placing conditions on the use of proxies, they form the basis of a flexible authorization mechanism


Restricted Proxies

• Two Kinds of proxies

– Proxy key needed to exercise bearer proxy

– Restrictions limit use of a delegate proxy

• Restrictions limit authorized operations

– Individual objects

– Additional conditions

+ ProxyProxyConditions:Use between 9AM and 5PMGrantee is user X, Netmaskis 128.9.x.x, must be able toread this fine print, can you

PROXY CERTIFICATE

Grantor


Authorization and Group Services

1. Authenticated authorization request (operation X)

2. [operation X only]R, {Kproxy} Ksession

3. [operation X only]R, authentication using Kproxy

R

2

SC3

1


Central Authorization

• Authorization server usesextended ACLs

– Conditions are not evaluated, but insteadattached to credentials

• Groups implemented by auth server– Server grants right to assert group membership

• Application servers configuredto use authorization server

– Minimal local ACL– Can use multiple Authorization servers


Applied Security

• Electronic commerce – SSL Applies authentication and encryption

– NetCheque applies proxies

– SET applies certification

– End system security a major issue

• What we have today

– Firewalls

– Web passwords, encryption, certificates

– Windows 2000 uses Kerberos

Copyright © 1995-2002 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Advanced Operating Systems Lecture notes Dr.

Documents

gaaapi calls

eacl gaa

clifford neuman university

authorization gaa api

gaa api routines

authorization policies

authorization function

mechanism authorization