Distributed Systems Security - Institutionen för informationsteknologi

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? e.g.
- 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?

What kind of authentication?

peer entity authentication: check that the other end (your peer) is authentic, typically when opening a connection. Cf TOCTTOU, connection hijacking etc.
entity authentication: check an entity's authenticity; valid only for authentication exchange
mutual vs unilateral authentication

1.1. Example: Network File System in Unix

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: Kerberos. (Integrity and confidentiality of traffic can also be protected.)

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" (asymmetric cipher)
port forwarding

1.3. Example: simple HTTP authentication

See RFC2617 for the whole specification.

"Basic" HTTP authentication:

Client: GET /project/internal HTTP/1.1
Server: HTTP/1.1 401 Authorization required
: WWW-Authenticate: Basic realm="Secret stuff"

Client pops up a window asking the user for username and password for "Secret stuff".

Client: GET /project/internal HTTP/1.1
: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

where "QWxhZGRpbjpvcGVuIHNlc2FtZQ==" is the "username:password" encoded with base-64.

Easy to sniff.

"Digest" HTTP authorization

Similar, but the server response uses the header
WWW-Authenticate: Digest realm="Secret stuff", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"...
(with more fields at the end), and the client's authorization will be
Authorization: Digest username="uname", realm="Secret stuff", response="6629fae49393a05397450978507c4ef1"...
(with more fields at the end).

The nonce is a large "random" number (unique, used once).

The "response" field is a hash/message digest:

h(h(uname:realm:password):nonce:h(method:uri))

where nonce is the field send by the server, method is GET (the fetch method used), and uri is the "link" being fetched, which is also specified as a field in the Authorization header.

The server can verify the response field since it knows the password, but noone else can, and replay attacks are prevented by the nonce. However, offline dictionary attacks still possible.

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", Key Distribution Center, Domain Controller (Windows)
Ticket Granting Servers (TGS): gives out "tickets" for accessing services/servers. Local TGS e.g. for groups/resources (cf. resource domains)
Servers: for files, printing, computing, etc.
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, N1)
KAS responds with (E(Ka,(TGS, Katgs, L1, N1)),Tatgs) where Ka is derived from As password hash)
- key Katgs is generated session key for use between A and TGS
- ticket Tatgs 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, N2, Tatgs, auth)
- TGS decrypts Tatgs using Ktgs,
- verifies A (from Tatgs 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, L2, N2)),Tab)
- 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
centralized policies, support for inter-realm authentication

Weaknesses

Single points of failure: KAS, TGS
Trust in TGS/KAS - they know the session keys, and can eavesdrop
Non-strict timestamp validation and lifetimes gives window for replay attacks

(too short lifetimes makes users complain)
Scalability problems

Uses

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

Key establishment

How to establish a shared secret between principals? Important issues:

some protocols have weak keys which are more easy to break (e.g. for an insider)
who suffers if a weak key is used?
who can control the choice of a key?

Some key establishment concepts:

Key transport: one party creates the key and sends it (securely) to the others
Key agreement: both parties contribute to the key generation so that none can predict the outcome (cf. Diffie-Hellman)
Key authentication: assurance that only a specific other party may get access to a particular key
Key confirmation: assurance that another party has access to a particular key
Explicit key authentication: key authentication and key confirmation