Distributed Systems Security - Department of Information Technology

Distributed system: collection of (heterogeneous) computers connected via a network, possibly controlled by different organisations and different policies.

Authentication

How do you authenticate a user/principal?
What is the basis for authentication decisions?
- user identity
- network address
- invoked service/operation, (access operation)
Where do you authenticate users? (Server or client, or both, or mix?)
Where do you make access control decisions?

1.1. Example: Network File System in Unix

(telnet, rlogin, rsh examples outdated: these programs should not be used.)

Unix UIDs (and GIDs) are shared between client and host

"my uid" on the client must match "my uid" on the server
typically using YP/NIS (Yellow Pages/Network Information Name Service)

Standard setup: NFS access requests carry the UID and GID list of the user, authenticated at the client. Access control at server accepts the UID/GIDs for access control.

Except (default): "root" (uid 0), which is mapped to "nobody" (uid 65534 or 60001)

(root bypasses access control in Unix)
Implication:
- server trusts client. Easy to fool if you have privileges (e.g. private laptop, Windows machine...)
Control:
- access control based on network address of client
  - using IP address, host name, domain suffix, "netgroups" (group of hosts)
  - negative permissions possible
  - write-protection of whole filesystems based on network address
  - root UID mapping configurable
- nosuid flag (like mount, cf. Unix security but server side)

Stronger authentication possible:

1.2. Example: ssh

Secure Shell Protocol. Basic features:

server authentication
confidentiality using public-key-encrypted shared session keys

More advanced features

client host authentication
client user authentication using "certificates"
port forwarding

1.1. Authentication protocols

Cleartext usernames (UIDs), passwords, IP addresses can be forged and eavesdropped. Stronger authentication needed.

1.1.1. Example: Kerberos

Developed at MIT in Project Athena (also X11, distributed file system, ...).

Elements:

Kerberos realm: similar to Windows Domain; hierarchies of realms possible
Kerberos Authentication Server (KAS): authenticates user at login, gives out "ticket" for acessing TGSs. "King of the Realm"
Ticket Granting Servers (TGS): gives out "tickets" for accessing services/servers. Local TGS e.g. for groups/resources (cf. resource domains)
Tickets Ti: shared-key "certificate-like" capabilities
Nonces Ni: single-use random numbers, to prevent replay attacks and for mutual authentication
Timestamps Ti: also to prevent replay attacks, require (not perfectly) synchronized clocks
Lifetimes Li: (requested) lifetime of tickets, limits use of brute-force attacks

Setup:

KAS knows one-way-encrypted user passwords
The KAS shares a secret key Ktgs for each TGS
Each TGS shares a secret key Kb for each server b
Notation: e(k, v) encrypts v using key k

Basic protocol: User A logs in to client machine, needs access to server B using a TGS

Client requests ticket for use with TGS from KAS: (A, TGS, L1, N1)
KAS responds with (TGS, Katgs, Tags, L1, N1) encrypted with Ka derived from As password hash
- key Katgs is generated session key for use between A and TGS
- ticket Tags is (Katgs, A, T1, L1) encrypted with Ktgs
- Client decrypts with Ka, verifies A, L1, N1
Client creates authenticator: e(Katgs,(A, T3),

and requests ticket from TGS: (A, B, L2, N2, Tags, auth)
- TGS decrypts Tags using Ktgs,
- verifies A (from Tags and message) and T1 against local clock
- retrieves Katgs, verifies A and T3
- generates session key Kab
- creates ticket Tab: e(Kb, (Kab, A, T2, L2))
TGS responds to client with e(Katgs, (B, Kab, Tab, L2, N2))
- client decrypts with Katgs
- verifies B, L2 and N2
- saves Kab and Tab
Client creates authenticator auth2: e(Kab, (A, T4))

and contacts server B: (auth2, Tab)
- B decrypts Tab, retrieving Kab
- verifies A against auth2, validates T4
Server B responds with e(Kab, T4)
- client verifies T4

Repeat steps 5-6 until L2 expires, repeat from step 3 until L1 expires.

Strengths

no cleartext passwords or keys over network

client doesn't store user passwords, only KAS does
limited lifetime of tickets (cf. TOCTTOU)
protection against replays
mutual authentication

Weaknesses

Single points of failure: KAS, TGS
Trust relation TGS-KAS (locally OK, widely distributed more difficult), key distribution problem
Non-strict timestamp validation and lifetimes gives window for replay attacks

(too short lifetimes makes users complain)
Dictionary attack possible: decrypt message 2
Scalability problems

Uses

NFS and other distributed filesystems in Unix
Windows Domains (but version of it...)
PAM
WebDAV
...

1.1.2. Example: DSSA/SPX

Similar, PKS, certificates.

1.2. Security APIs

Which system do we use today? How do we write programs using them?

Abstract from implementation:

1.2.1. Example: GSS-API

Generic Security Services API (application program interface) for portability between Kerberos and DASS

independence of mechanisms (e.g. PKI/shared key)
independence of communication protocol
clients not necessarily in TCB(?)

Basic elements:

credentials: the security-relevant data required to establish security contexts between peers, e.g. tickets
tokens: data supplied to GSS-API interface, converted to mechanism-specific format
security contexts: established using credentials, e.g. between A and B in Kerberos example
status codes: abstracts the mechanism stages. Major codes: independent, minor codes: dependent of mechanism.

Interface

credential management calls: acquire, release, information about credentials
context-level calls: initiation, acceptance, deletion, info about security contexts
per-message calls: integrity, confidentiality
support calls

1.2.2. Example: CORBA

Further abstraction: OS-independent, application layer, object oriented.

CORBA = Common Object Request Broker Architecture

ORB: Object Request Broker
- handles all communication between client and server objects

[figure 10.5, p181]