AUTHENTICATION APPLICATIONS Chapter 14 Kerberos X 509 Directory

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

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

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

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 and pp. 305 - 308

KERBEROS V 4 Uses DES Complicated! To analyse: Simple More Secure V 4 Auth. Dialogue

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

SIMPLE DIALOGUE 1. C IDC || PC || IDV AS 2. AS Ticket C 3. C IDC || Ticket V 4. Ticket = EKV[ IDC || ADC || IDV ] 5. C : client AS : authentication server 6. V : server ADC : client address 7. (ticket only valid if from C) 8. PC : 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 2. AS IDC || IDTGS EKC[Ticket. TGS] AS C IDC || IDV || Ticket. TGS Ticket. V TGS C (KC from users password) Once/Service 3. C 4. TGS Once/Service Session 5. C IDC || Ticket. V V Ticket. TGS = EKTGS[IDC || ADC || IDTGS || TS 1 || lifetime 1] Ticket. V = EKV[IDC || ADC || IDV || TS 2 || lifetime 2]

ADVANTGAGES of MORE SECURE DIALOGUE Password NOT plaintext instead, pwd sent via KC Uses Multiple Service-Granting Tickets One Problem: Ticket. TGS could be captured Solution: Ticket. TGS includes timestamp TS 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 key TGS key is Kc, TGS Client key TGS prove ID

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 17

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

INTER-REALM AUTHENTICATION 19

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

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

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

KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS (tech) 4. Password Attacks V 4: Vulnerable Keypassword Decrypt by guessing passwords V 5: 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 = EKRauth[T, IDA, KUA] (RSA recommended) Used for S/MIME, IPSec, SSL/TLS, and SET

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

CERTIFICATE DIRECTORY 27

TWO CAs A B A wishes to Cert X 2 EKR 1[T, ID 1, KU 2] obtain B’s public securely via two Cert B EKR 2[T, IDB, KUB] accesses to the directory. CA 2(KU 2) A initially has cert. CA 1(KU 1) from X 1 B initially has cert. 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 from X 2 X 1<<X 2>>X 2<<B>>

X. 509 CA HIERARCHY 29

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

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

X. 509 AUTHENTICATION Three alternatives : a) One-Way Auth. – IDA, message from A, message is for B, integrity/originality of message b) Two-Way Auth. – a) plus IDB, 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 33

ENCRYPTION KEY FROM PASSWORD 34

PCBC MODE 35