AUTHENTICATION APPLICATIONS - Chapter 14 Kerberos X.509 Directory Authentication (S/MIME)

SERVER ATTACKS B[A] : Pretend B  A: Impersonate B(A  Server): Eavesdrop/Replay Server W/station Server W/station

CENTRALISED AUTHENTICATION Symmetric Key - YES Public Key - NO Central Auth. K W/stationServerW/station

KERBEROS Two Versions Version 4. Version 5. – Draft Internet Standard

KERBEROS Secure no eavesdropper / user impersonation Reliable backup / critical Transparent user unaware / password Scalable large number of clients

KERBEROS Trusted Third-Party Authentication Uses Needham/Schroeder scheme Fig 7.9

KERBEROS V4 Uses DES Complicated! To analyse: Simple More Secure V4 Auth. Dialogue  Dialogue  Dialogue

SIMPLE DIALOGUE Impersonations: Server Confirms Client ID Authentication Server (AS) contains User Passwords (centralised) Unique Server Keys

SIMPLE DIALOGUE 1. C  ID C || P C || ID V AS 2. AS  Ticket C 3. C  ID C || Ticket V Ticket = E K V [ ID C || AD C || ID V ] C : client AS : authentication server V : server AD C : client address (ticket only valid if from C) P C : client password

MORE SECURE DIALOGUE Re-usable Tickets? But different tickets for every server Solution: Use Ticket Granting Server (TGS)

MORE SECURE DIALOGUE Once/Logon 1. C  ID C || ID TGS AS 2. AS  E K C [Ticket TGS ] C (K C from users password) Once/Service 3. C  ID C || ID V || Ticket TGS TGS 4. TGS  Ticket V C Once/Service Session 5. C  ID C || Ticket V V Ticket TGS = E K TGS [ID C || AD C || ID TGS || TS 1 || lifetime 1 ] Ticket V = E K V [ID C || AD C || ID V || TS 2 || lifetime 2 ]

ADVANTGAGES of MORE SECURE DIALOGUE Password NOT plaintext instead, pwd confirmed via K C Uses Multiple Service-Granting Tickets One Problem: Ticket TGS could be captured Solution: Ticket TGS includes timestamp T S and lifetime

MORE SECURE DIALOGUE WEAKNESSES 1. Short lifetime  too many password requests Long lifetime  replay attacks 2. False servers

VERSION 4. AUTHENTICATION DIALOGUE Table 14.1 – Protocol Table 14.2 – Rationale 1. Protect from Captured Tickets: AS  key Client Client  key TGS  key TGS prove ID key is K c, TGS

VERSION 4. Note: (1) TS 1 (2) TS 2, lifetime 2 (3) Authenticator – use once – short life (authenticates ticket sender as owner) After complete dialogue, Client : Server share secret key

KERBEROS SERVER REQUIRES User IDs Hashed Passwords Symmetric Server Keys (registered servers)

KERBEROS OVERVIEW

INTER-REALM AUTHENTICATION Two realms share secret key (mutually registered) - needs mutual trust (Fig 14.2) Problem: Does not scale well to many realms N realms  N(N-1) secure key 2 exhanges

INTER-REALM AUTHENTICATION

KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS 1.Encryption System Dependence V4: (DES,export) V5: Ciphertext tagged with encryption id - keys tagged with type/length 2. Internet Protocol Dependence V4: requires IP addresses V5: addresses tagged with type/length (IP/ISO) 3. Message Byte Ordering V4: tagged message with ordering V5: Abstract Syntax Notation One Basis Encoding Rules

KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS 4. Ticket Lifetime V4: 8-bit, 5 minute units, Max = 1280 minutes V5: Start time/End time – arbitrary 5. Authentication Forwarding V4: NO Credential Forwarding V5: Credential Forwarding 6. Inter-Realm Authentication V4: O(N 2 ) keys V5: Fewer keys

KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS (Tech) 1.Double Encryption ((2), (4) of Table 14.1) V4: Yes V5: Second encryption omitted 2. PCBC Encryption V4: Nonstandard DES mode, PCBC (vulnerable), for integrity check V5: Explicit, separate integrity + CBC mode 3. Session Keys V4: Replay risk using repeated ticket V5: Subsession key. Once only

KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS (tech) 4. Password Attacks V4: Vulnerable Key password  Decrypt by guessing passwords V5: Vulnerable Pre-authentication makes attacks more difficult

KERBEROS 5 AUTHENTICATION DIALOGUE Compare Tables 14.1 and 14.3 (1),(3) new: Realm, Options (flags), Times, Nonce Times are client requests for ticket time settings (5) new: Optional Mutual Authentication (6) new: No timestamp needed - use keys instead

X.509 AUTHENTICATION Directory – database : network adddress, certificate,…etc Certificate: CA = E KR auth [T,ID A,KU A ] (RSA recommended) Used for S/MIME, IPSec, SSL/TLS, and SET

CERTIFICATE DIRECTORY CA or user  (trusted) Directory Certificate Fig 14.3a - formats Certificates unforgeable Directory of certificates used to distribute authentic user public keys

CERTIFICATE DIRECTORY

TWO CAs A B Cert X 2 Cert B E KR 1 [T,ID 1,KU 2 ] E KR 2 [T,ID B,KU B ] CA 2 (KU 2 ) CA 1 (KU 1 )  X 1 >X 2 > A wishes to obtain B’s public securely via two accesses to the directory. A initially has cert. from X 1 B initially has cert. from X 2 Having X 1 ’s pub. key gives access to X 2 ’s pub. key Having X 2 ’s pub. key gives access to B’s pub. key

X.509 CA HIERARCHY

CHAIN OF CERTIFICATES Hierarchy : Fig 14.4 Forward Certificates : e.g. W > cert of X generated by W Reverse Certificates : e.g. X > cert of W generated by X e.g. X >W >V>>Y>>Y >Z > result: A recovers B’s public key

CERTIFICATE REVOCATION 1.User secret key compromised 2. User no longer certified 3. CA’s certificate compromised each CA has Certificate Revocation List (CRL)

X.509 AUTHENTICATION Three alternatives : a) One-Way Auth. – ID A, message from A, message is for B, integrity/originality of message b) Two-Way Auth. – a) plus ID B, reply from B, integrity/originality of reply c) Three-Way Auth. – b) plus signed nonce – to avoid t/stamps - used when clocks not synchronised

X.509 AUTHENTICATION

ENCRYPTION KEY FROM PASSWORD

PCBC MODE