Access Control

Dr. Ron Rymon

Efi Arazi School of Computer Science

IDC, Herzliya. 2008/9

Pre-requisite: Basic Cryptography, Identity Authentication

Overview

Access Control and Identity Management

Public-Key Infrastructure (PKI)

Firewalls

Client/Server Authentication (Kerberos)

Remote User Authentication Service (RADIUS)

Access Control andIdentity Management

Main Sources: Kaufman et al

Access Control Model

Mandatory, Discretionary, Role-based

Mandatory Access Control (MAC)– Access is restricted not individually but based on a user

attribute (e.g., title, clearance, or a group he belongs to)

Discretionary Access Control (DAC)– Every user/admin that owns a resource can decide (at

his discretion) who may have which access

Role-based Access Control (RBAC)– A user is granted access to privileges according to her

role(s) in the enterprise

Access Control Specification and implementation of policies and rules

Which users (and applications)• Internal and external users, applications

Can access which resources• Files, databases, applications

For what purpose• Read/Write/Execute (access levels)• Limits, e.g., buy up to $5000, (authority level)

When• Time of the day, specific sessions

Under which conditions• Additional authentication, supervisor or dual-approval

Etc…

Access Control – Where

Physical access control– Keys, Key Rings, Master Keys are all ways to control

physical access

– Increased deployment of biometric identification for physical access control

Access Control Software/Hardware Mechanisms– On routers, e.g., Cisco’s TACACS+, and network

access control servers (e.g., RADIUS)

– Systems, e.g., Unix, Windows, Mainframe (file level)

– Within Enterprise applications, databases, Web servers

Access Control Mechanisms Access Control Lists (ACL)

– Specification of access rights per resource: which users (by userid) can access this resource

– One problem: there might be too many such users User Groups

– Group users so that can refer to and specify access policy for the entire group

– Some systems also allow grouping of resources– Group membership can be part of the organizational “directory”, and/or

part of the (signed) certificate of each user– Examples: administrators, power users, marketing, guests– Still, a lot of replication, e.g., Marketing, Sales, and R&D groups may all

share a certain subset of access rights Hierarchical groups

– Employee can be the parent/child of each of Marketing, Sales, R&D

Example: Access Control to File System in Unix, NT Unix

– Every file associated with a “mode”– Read, Write, and eXecute rights, for owner,

group, world– e.g., dr--r-xrwx– getacl, setacl functions support

additional ACL entries for users, groups, and objects

Windows NT– NTFS allows specifying which users,

groups can do what to a file, folder, registry, and other system objects

– A few groups are pre-defined, e.g., admin, power-users, users

Hardening to Restrict OS Access Background: Operating Systems were originally designed

without security in mind– many “friendly” services, e.g., mail, ftp, file, printer, login

– many pre-configured accounts, e.g., system, administrator, backup

Problem: Hackers use these extra services to penetrate

Solution: “harden” OS (aka secured shell)– remove services, e.g., sendmail, remote login

– monitor for unexpected traffic, usually using IDS tools

NIST RBAC Standard– ANSI INCITS 359-2004, Ferraiolo et al, 2/2004

Today implemented in most enterprise software Mandated or recommended by industry regulations

Permissions

Role Based Access Control (RBAC)

Users Roles

Session

Operations ObjectsUA PA

Ad-Hoc Direct Privileges

Hierarchy

Role-Based Security A “logical” layer that links users and allowed resources

– A role specifies the need or circumstances in which a user needs a resource

– User-Role and Role-Resource relations simplify User-Resource relations

C r e d i tT e l e m a r k e t e r s

M a n a g e rA d m i n

C r e d i tS c r e e n

C r e d i tA l e r t

M g m t S e c u r i t y H QM a r k e t i n g

1

32

Roles Layer Employee Org role(s) Geography Member of committee Reporting to In charge of process Weekend shift

Roles can be hierarchical

RBAC Productivity/Security Gains Productivity Gains

– Easier to provision new employees• Alice replaces Bob as VP of Marketing• John joins the security administration team

– Easier to manage change• Richard was relocated to the Singapore office• Bonnie replaces Jack in the computing committee

Security Gains– Many users are “collectors” of access rights– Facilitates compliance with regulations and audit of

access rights

Policy-based Access Control A policy is of a set of rules that govern access control

– Policy Administration Point (PAP)

– Policy Decision Point (PDP)

– Policy Enforcement Point (PEP)

Can itself be based on roles, groups, identity attributes, and resource attributes

PAPPAP

Define & Manage PoliciesDefine & Manage Policies

PEPPEPPDPPDP

Evaluate & DecideEvaluate & DecidePEPPEP

PEPPEPPEPPEPPEPPEP

EnforceEnforce

PDPPDP

Evaluate & DecideEvaluate & Decide

Many systems,Many systems,

locationslocations

Governance, Risk & Compliance (GRC) Regulations:

– Industry regulations: banking, SEC, payment, insurance, utilities

– National, e.g., competition– Enforcement + Demonstration

Fine-grained entitlement management– User/resource attributes– Roles/groups– Access context

IT controls– Segregation of duties, checks and

balances, business process rules

Risk– Assess, prioritize, remediate

Sarbanex-Oxley (SOX), GLB, HIPPASarbanex-Oxley (SOX), GLB, HIPPA

FERC, ISO, PCI, FISMA, Basel IIFERC, ISO, PCI, FISMA, Basel II

Identity Management / Provisioning A set of tools for managing organizational identities and

their access privileges

Management functions– Add/remove/update info about users, resources– Add/delete privileges to platforms and/or applications– Manage access policies

Automated Provisioning– Automates requests and approvals processes– Provisions and de-provisions on target systems (accounts, group

membership, etc.)

Main Benefits– Centralized store for organizational identities– Centralized management– Automated provisioning and removal of privileges

Typical ID Mgmt Functions User provisioning Role Management Password reset and password management Web access control Self-service requests and approvals Authentication & Single sign-on Log management and analysis Public Key Infrastructure Federation of identities

Many IdMs use directories to store identities and policies Some IdM start to provide Governance, Risk, and

Compliance (GRC) capabilities

Directories Goal: centralized repository of users and privileges Solution: Directory

– Centralized repository of users, resources, and privileges– Implements a hierarchical database– Users (leaves) appear with their specific information (attributes)

• name, user names, certificates, org, etc.

– Fast retrieval– Difficult update

IETF X.500 Directory Access Protocol (DAP)– Defines access to the Directory– Runs on top of TCP– Almost all implementations are Lightweight DAP (LDAP)

Federated Directories (a.k.a. Meta-directories)– Integrate and implement trust between directories

Maturity of IdM Technologies

Firewalls and Proxy Servers

Main Sources: Stallings, Checkpoint Software

The Firewall Principle Create a controlled link between the protected network

and the outside world– Inspects all inbound and outbound traffic

private network

Server

Server

HUB

Router

Internet

Allows only authorized traffic– Per specified security policy

Firewall itself can be– Hardware– Software (mostly)

Must itself be immune to penetration– Hardware, or a trusted system, implemented on top of a hardened OS

FW-enforced Policies Service control : which services are allowed

– may determine valid ports– may use a proxy to interpret requests before they are passed on– may host the service outside the internal network (web, e-mail)

Direction control– may limit certain services to only one direction

User control : who is allowed to use the service– may apply access control policy to internal users– may use IPSec to authenticate external users

Behavior control : how a service can be used– may implement intrusion prevention or anti-virus filter– may filter spam in either direction

Limitations and Other Uses Limitations

– The FW cannot protect against internal attacks (unless traffic is filtered)– The FW cannot protect against back-door attacks, e.g., through a dial-up line

that goes directly into the internal network

In addition to its filtering uses, the FW location is ideal for other functions as well

– VPN implementation – Network Address Translation (NAT)– Intrusion detection / prevention– URL filtering– Anti-virus filtering

Personal firewalls (highly recommended)– Control what executes on and communicates from a given machine– Can protect against intra-net attacks

FW types: Packet-Filtering Implemented in IP layer Applies a set of rules to individual IP packets Rules are based on IP and TCP header parameters The first rule that matches the packet is applied

• If no rule applies, the default is usually to drop the packet

Advantages: application independent, fast

Rule action Dir Protocol source Port destination Port

untrusted block any any 123.4.5.* * 192.168.*.* *

email allow in TCP * * * 25

Spoofing block in any 192.168.*.* * * *

Default block any any * * * *

FW types: Application Gateways Application-specific software that brokers between the

server and its clients Brokers and examines each C/S transaction

Pros:– better security through app awareness

Cons:– application dependent

– slow

– requires awareness of internal user

Examples: FTP, Telnet, Web apps

FW types: Stateful Inspection Problem: packet filters examine isolated packets

– e.g., may not want to allow FTP data communication on a port that is not associated with an open FTP session

Solution: maintain a state– Communication-derived state, e.g., which

ports are open– Application-derived state, e.g., whether the

user was already authenticated by the service

Packets intercepted at IP layer, but also tracked in upper layers

– Creates a virtual session, useful even for connectionless protocols

Cons (vs. app gateway): usual implementations do not analyze packet internals

Bastion Host Bastion Host services external users

– Hosts proxy servers + externally available services– Only server addressable directly from outside network– Usually located after a packet filter– Must be very well protected

• hardened OS• requires authentication

Examples:– Victim BH : provides unprotected services to external

users– Non-routing dual-homed BH : services internal and

external users (does not transfer packets between them)– Internal BH : located inside network, and services

external users – must be very well secured

Example: Firewall Configuration (1)

Screened host firewall with single-homed Bastion Host– All communication with external network goes through the BH

– BH may perform authentication and proxy functions

Example: Firewall Configuration (2)

Screened host firewall with dual-homed Bastion Host– In the single-homed BH, if the packet-filter is compromised then

intruder has access to rest of the network

– Here, there is a physical separation, so intruder must gain control of the BH as well (an example of Defense-in-Depth)

Example: Firewall Configuration (3)

Screened subnet firewall– Another packet filter offers a third level of protection

– Outside router does not advertise internal network, and therefore hard for intruder to map it

The screened subnet a.k.a. perimeter network or DMZ is often used to host services for external users

Proxy Servers An “Application Gateway” Firewall Usually located on a BH

Must be written specifically for each application– Standard ones for TCP services: FTP, Telnet, HTTP– Generic ones that can be configured for new applications

Every proxy server software must be configured to maximize security– may be configured to access only specific hosts– may require additional authentication– a simple software that can be more easily audited for security flaws– maintain log for future audit– proxies are independent– proxies run in a non-privilege mode, and in own private folders

Example: Web Application Gateway Web applications are very common, and hackers often try to

penetrate and exploit them A Web gateway “hides” the actual web server

Enforce intended business logic and business policies– Build/learn policy for web application, reflecting the intended use

Web App Gateway Functions (2007) Multi-application gateway Web app firewall, including “deep” packet inspection” Web app access control Web services protection (for SOA) Automated learning of legitimate use patterns App layer Denial-of-Service protection Website cloaking: hiding from crawlers (but not Google...)

Application gateway devices often include functions of regular packet filters and/or stateful inspection firewall

And also other security features– Access control to protect specific sensitive data– Encryption– NAT

Attacks on Firewalls Firewalls can be difficult to configure and many contain

bugs in their policies– Most implementations of firewalls are fairly superficial in

examining the application fields– Usually firewalls cannot deal with IP spoofing

Perimeter-based firewall cannot protect against internal attacks and Trojans

Firewall cannot prevent DoS attacks

Market trends:– application gateways, e.g., for web services and XML– Smarter firewalls, e.g., “learning”, “identity role-based”– combined security appliances– centralized consoles for management

Client/Server Authentication

Kerberos

Main sources: Stallings, Schneier, Kaufman et al

Kerberos Background

– Client/Server authentication service, developed by Project Athena– Deployed as a Single-Sign On service

Services– Client/Server authentication– Allows users and servers to mutually authenticate– Key Distribution Center (KDC)– Uses symmetric key as proof of identity (DES/RC4)

• New versions use other forms of authentication

Requirements– Protect against user impersonation– Protect against spoofing of device identity– Protect against replay attacks– Provide high availability– Provide transparency to the user and application server

Kerberos Protocol

Ticket: T(c,s) = s,EKs(c,a,v,Kc,s)– c-client, s-server, a-client address, v-validity time– Used as a “pass” until expiration

Authenticator: A(c,s) = E Kc,s(c,t,k)– t-time stamp, k-additional session key– Used once, but the client can generate as many as she wishes

Client

KerberosAuthenticationServer (AS)

TicketGranting

Server

ServerReqTGT

GrantTGT

ReqTicket

GrantTicket

ReqService

Kerberos Protocol

Req TGT: Send c,tgs

Client

KerberosAuthenticationServer (AS)

TicketGranting

Server

ServerReqTGT

GrantTGT

ReqTicket

GrantTicket

ReqService

Grant TGT: Gen Kc,tgs; Send EKc(Kc,tgs), T(c,tgs)

Req Ticket: Send A(c,tgs), T(c,tgs), s

Grant Ticket: Gen Kc,s; Send EKc,tgs(Kc,s), T(c,s)

Req Service: A(c,s), T(c,s)

Kerberos Security Features Kerberos acts as a KDC (Key Distribution Center)

Kerberos AS verifies the identity of a client through the key, and comparing identity and address to a database– Key can be symmetric key, or derived from password

Tickets T(c,tgs/s) is given to the client but is locked

Server continuously verifies client through session key in authenticator

Timestamps used to ensure synchronicity and against original ticket validity (typically 8 hours)

It is common to quickly replace use of client long-term key with a session key

Example: Windows 2000 Kerberos

Windows 2000Windows 2000Active DirectoryActive Directory

Windows 2000 Domain ControllerWindows 2000 Domain Controller

AS TGS

KDC

Application Server1

2

2.2. Authenticate user Authenticate user and get a Ticket and get a Ticket Granting Ticket (TGT) Granting Ticket (TGT) from KDC from KDC

1. 1. Locate the Active DirectoryLocate the Active Directory and Kerberos KDC for the and Kerberos KDC for the domain using DNS lookup.domain using DNS lookup. Client receives key encryptedClient receives key encrypted with own passwordwith own password

User Client

Attacks on Kerberos Security

Kerberos itself stores many keys and should be protected

Tickets may be replayed within allowed lifetime. Server should store recent requests and check for replays

Adversary may cache many TGTs and work offline to decrypt them (see Wu’s attack). Clients shall use safe passwords.

By changing server clocks, adversary may replay tickets. Hosts shall synchronize clocks often

Enhancements– Allow authentication using public-key certificates, smart cards– Mutual authentication, where server returns signed timestamp

Wu’s Attack Dictionary attack on the TGT ticket returned by AS Kerberos authentication exchange step-by-step

– Initial request sent in clear• User name, requested ticket/service information

– AS responds, message encrypted with key based on user password• Session key, service name, …

– Client decrypts (verifying identity through knowledge of the key) Attacking Kerberos client

– Applies dictionary attack, decrypting with different passwords– Seeking service name = “krbtgt”

In two weeks, Wu has broken 2045 passwords in a real 25,000 users domain

Kerberos V5 requires pre-authentication– Client sends timestamp encrypted with authenticating key

Other Kerberos Features Kerberos Administration Server (KADM)

– Purpose: add/manage users in the Kerberos database– Employs another protocol

Kerberos Replication and Realms– In large organizations, it is possible to replicate the TGT/Ss, with

one copy serving as a master and the others being read-only– It is also common to divide the network services into Realms, each

covered by different Kerberos servers, with a trust between realms

Kerberos is widely implemented– Most popular in network authentication– Main authentication mechanism in Win2K and up (esp. in domains

that require Unix integration), and MS Passport– Directory servers and API available from Microsoft, Sun, etc.