1 / 35

AUTHENTICATION APPLICATIONS - Chapter 14

AUTHENTICATION APPLICATIONS - Chapter 14. Kerberos X.509 Directory Authentication (S/MIME). SERVER ATTACKS. B[A] : Pretend B  A: Impersonate B(AServer): Eavesdrop/Replay. CENTRALISED AUTHENTICATION. Symmetric Key - YES

jemima
Download Presentation

AUTHENTICATION APPLICATIONS - Chapter 14

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. SERVER ATTACKS • B[A] : Pretend • B  A: Impersonate • B(AServer): Eavesdrop/Replay

  3. CENTRALISED AUTHENTICATION Symmetric Key - YES Public Key - NO

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

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

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

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

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

  9. C IDC || PC || IDV AS • AS Ticket C • C IDC || Ticket V • Ticket = EKV[ IDC || ADC || IDV ] • C : client AS : authentication server • V : server ADC : client address • (ticket only valid if from C) • PC : client password SIMPLE DIALOGUE

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

  11. Once/Logon 1. C IDC || IDTGS AS 2. AS EKC[TicketTGS] C (KC from users password) Once/Service 3. C IDC || IDV || TicketTGSTGS 4. TGS TicketV C Once/Service Session 5. C IDC || TicketV V TicketTGS = EKTGS[IDC || ADC || IDTGS || TS1 || lifetime1] TicketV = EKV[IDC || ADC || IDV || TS2 || lifetime2] MORE SECURE DIALOGUE

  12. Password NOT plaintext instead, pwd confirmed via KC Uses Multiple Service-Granting Tickets One Problem: TicketTGS could be captured Solution: TicketTGS includes timestamp TS and lifetime ADVANTGAGES of MORE SECURE DIALOGUE

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

  14. 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 Kc,TGS

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

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

  17. KERBEROS OVERVIEW

  18. 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. INTER-REALM AUTHENTICATION

  20. KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS • 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

  21. 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(N2) keys V5: Fewer keys

  22. 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)

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

  24. 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 KERBEROS 5 AUTHENTICATION DIALOGUE

  25. Directory – database : network adddress , certificate,…etc Certificate: CA = EKRauth[T,IDA,KUA] (RSA recommended) Used for S/MIME, IPSec, SSL/TLS, and SET X.509 AUTHENTICATION

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

  27. CERTIFICATE DIRECTORY

  28. B TWO CAs A A wishes to obtain B’s public securely via two accesses to the directory. A initially has cert. from X1 B initially has cert. from X2 EKR1[T,ID1,KU2] Cert X2 EKR2[T,IDB,KUB] Cert B CA2(KU2) CA1(KU1) Having X1’s pub. key gives access to X2’s pub. key Having X2’s pub. key gives access to B’s pub. key  X1<<X2>>X2<<B>>

  29. X.509 CA HIERARCHY

  30. 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 CHAIN OF CERTIFICATES

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

  32. 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. X.509 AUTHENTICATION

  34. ENCRYPTION KEY FROM PASSWORD

  35. PCBC MODE

More Related