Enhancing Security: Digital Signatures & Authentication Applications in Kerberos

1. CSCE 815 Network Security Lecture 9 Digital Signatures & Authentication Applications Kerberos February 13, 2003

2. Resources • Stallings Web Site: http://williamstallings.com/ • http://web.mit.edu/kerberos/www/ • http://web.mit.edu/kerberos/www/dialogue.html • http://web.mit.edu/kerberos/www/papers.html • Kohl’s paper “ The Evolution of Kerberos…”

3. http://web.mit.edu/kerberos/www/ • What is Kerberos? • Security Advisories • Kerberos Releases • Kerberos V5 Release 1.2 • Historical releases of MIT krb5 • Getting Kerberos Sources and Binaries from MIT (US and Canada only) • Getting Kerberos Sources from the Crypto Publishing Project • The krb5-current Snapshots (for developers; US, Canada only) • Documentation for the most recent release • Papers about the Kerberos protocol • Frequently Asked Questions • The comp.protocols.kerberos FAQ (at NRL; maintained by Ken Hornstein) • How do the new US export regulations affect Kerberos? • Other Resources • Mailing lists • comp.protocols.kerberos newsgroup • USC/ISI Kerberos Page • Oak Ridge National Laboratory's "How to Kerberize your Site"

4. Digital Signatures • have looked at message authentication • but does not address issues of lack of trust • digital signatures provide the ability to: • verify author, date & time of signature • authenticate message contents • be verified by third parties to resolve disputes • hence include authentication function with additional capabilities

5. Digital Signature Properties • must depend on the message signed • must use information unique to sender • to prevent both forgery and denial • must be relatively easy to produce • must be relatively easy to recognize & verify • be computationally infeasible to forge • with new message for existing digital signature • with fraudulent digital signature for given message • be practical save digital signature in storage

6. Direct Digital Signatures • involve only sender & receiver • assumed receiver has sender’s public-key • digital signature made by sender signing entire message or hash with private-key • can encrypt using receivers public-key • important that sign first then encrypt message & signature • security depends on sender’s private-key

7. Replay Attacks • where a valid signed message is copied and later resent • simple replay • repetition that can be logged • repetition that cannot be detected • backward replay without modification • countermeasures include • use of sequence numbers (generally impractical) • timestamps (needs synchronized clocks) • challenge/response (using unique nonce)

8. Digital Signature Standard (DSS) • US Govt approved signature scheme FIPS 186 • uses the SHA hash algorithm • designed by NIST & NSA in early 90's • DSS is the standard, DSA is the algorithm • a variant on ElGamal and Schnorr schemes • creates a 320 bit signature, but with 512-1024 bit security • security depends on difficulty of computing discrete logarithms

9. DSA Key Generation • have shared global public key values (p, q, g): • a large prime p, with 2L-1< p < 2L • where L= 512 to 1024 bits and is a multiple of 64 • choose q, a 160 bit prime factor of p-1 • choose g = h(p-1)/q • where h is any integer 1<h<p-1, such that h(p-1)/q (mod p) > 1 • users choose private & compute public key: • choose a random number x with x<q • Compute public key y = gx (mod p)

10. DSA Signature Creation • to sign a message M the sender: • generates a random signature key k, k<q • nb. k must be random, be destroyed after use, and never be reused • then computes signature pair: r = (gk(mod p))(mod q) s = (k-1.(SHA(M)+ x.r))(mod q) • sends signature (r,s) with message M

11. DSA Signature Verification • having received M & signature (r,s) • to verify a signature, recipient computes: w = s-1(mod q) u1= (SHA(M).w)(mod q) u2= (r.w)(mod q) v = (gu1.yu2(mod p)) (mod q) • if v=r then signature is verified • see C&NS book web site for details of proof why

12. DSS Signing And Verifying

13. Authentication Protocols • We cannot enter into alliance with neighboring princes until we are acquainted with their designs. • —The Art of War, Sun Tzu • used to convince parties of each others identity and to exchange session keys • may be one-way or mutual • key issues are • confidentiality – to protect session keys • timeliness – to prevent replay attacks

14. Replay Attacks • where a valid signed message is copied and later resent • simple replay • repetition that can be logged • repetition that cannot be detected • backward replay without modification • countermeasures include • use of sequence numbers (generally impractical) • timestamps (needs synchronized clocks) • challenge/response (using unique nonce)

15. Authentication Applications • will consider authentication functions • developed to support application-level authentication & digital signatures • will consider Kerberos – a private-key authentication service • then X.509 directory authentication service

16. KERBEROS • In Greek mythology, a many headed dog, the guardian of the entrance of Hades

17. Threats In a Shared Network • Kerberos developed as part of Project Athena at MIT • Athena – a network of workstations and distributed or centralized servers • Threats in any network sharing resouces • a user may pretend to be another user • A user may change an IP address of a workstation • A user may eavesdrop and use a replay attack for …

18. Approaches to Security in a Network • Rely on workstation to assure the identity of users. Rely on server to enforce security policy on users. • Require workstations authenticate themselves to servers, trust workstations authenticate users. • Require the user prove identity for each service requested. Also servers prove identity to clients.

19. Kerberos • trusted key server system from MIT • provides centralised private-key third-party authentication in a distributed network • allows users access to services distributed through network • without needing to trust all workstations • rather all trust a central authentication server • two versions in use: 4 & 5

20. Kerberos Requirements • first published report identified its requirements as: • security • reliability • transparency • scalability

21. Kerberos 4 Overview • a basic third-party authentication scheme • have an Authentication Server (AS) • users initially negotiate with AS to identify self • AS provides a non-corruptible authentication credential (ticket granting ticket TGT) • have a Ticket Granting server (TGS) • users subsequently request access to other services from TGS on basis of users TGT

22. Kerberos Version 4 • Terms: • C = Client • AS = authentication server • V = server • IDc = identifier of user on C • IDv = identifier of V • Pc = password of user on C • ADc= network address of C • Kv= secret encryption key shared by AS an V • TS = timestamp • || = concatenation

23. A Simple Authentication Dialogue C AS: IDc ||Pc || IDv AS  C: Ticket C  V: IDc || Ticket Ticket = EKv[IDc ||Pc || IDv]

24. Version 4 Authentication Dialogue • Problems: • Lifetime associated with the ticket-granting ticket • If too short  repeatedly asked for password • If too long  greater opportunity to replay • The threat is that an opponent will steal the ticket and use it before it expires

25. Version 4 Authentication Dialogue • Authentication Service Exhange: To obtain Ticket-Granting Ticket C AS: IDc || IDtgs ||TS1 AS  C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs] Ticket-Granting Service Echange: To obtain Service-Granting Ticket (3) C  TGS: IDv ||Tickettgs ||Authenticatorc (4) TGS  C: EKc [Kc,¨v|| IDv || TS4 || Ticketv] Client/Server Authentication Exhange: To Obtain Service (5) C  V: Ticketv || Authenticatorc (6) V  C: EKc,v[TS5 +1]

26. Kerberos 4 Overview Fig 4.1

27. Kerberos Realms • a Kerberos environment consists of: • a Kerberos server • a number of clients, all registered with server • application servers, sharing keys with server • this is termed a realm • typically a single administrative domain • if have multiple realms, their Kerberos servers must share keys and trust

28. Request for Service in Another Realm

29. Kerberos Version 5 • developed in mid 1990’s • provides improvements over v4 • addresses environmental shortcomings • encryption algorithm, network protocol, byte order, ticket lifetime, authentication forwarding, interrealm authorization • and technical deficiencies • double encryption, non-std mode of use, session keys, password attacks • specified as Internet standard RFC 1510

30. X.509 Authentication Service • part of CCITT X.500 directory service standards • distributed servers maintaining some info database • defines framework for authentication services • directory may store public-key certificates • with public key of user • signed by certification authority • also defines authentication protocols • uses public-key crypto & digital signatures • algorithms not standardised, but RSA recommended

31. X.509 Certificates • issued by a Certification Authority (CA), containing: • version (1, 2, or 3) • serial number (unique within CA) identifying certificate • signature algorithm identifier • issuer X.500 name (CA) • period of validity (from - to dates) • subject X.500 name (name of owner) • subject public-key info (algorithm, parameters, key) • issuer unique identifier (v2+) • subject unique identifier (v2+) • extension fields (v3) • signature (of hash of all fields in certificate) • notation CA<<A>> denotes certificate for A signed by CA

32. X.509 Certificates

33. Obtaining a Certificate • any user with access to CA can get any certificate from it • only the CA can modify a certificate • because cannot be forged, certificates can be placed in a public directory

34. CA Hierarchy • if both users share a common CA then they are assumed to know its public key • otherwise CA's must form a hierarchy • use certificates linking members of hierarchy to validate other CA's • each CA has certificates for clients (forward) and parent (backward) • each client trusts parents certificates • enable verification of any certificate from one CA by users of all other CAs in hierarchy

35. CA Hierarchy Use

36. Certificate Revocation • certificates have a period of validity • may need to revoke before expiry, eg: • user's private key is compromised • user is no longer certified by this CA • CA's certificate is compromised • CA’s maintain list of revoked certificates • the Certificate Revocation List (CRL) • users should check certs with CA’s CRL

37. Authentication Procedures • X.509 includes three alternative authentication procedures: • One-Way Authentication • Two-Way Authentication • Three-Way Authentication • all use public-key signatures

38. One-Way Authentication • 1 message ( A->B) used to establish • the identity of A and that message is from A • message was intended for B • integrity & originality of message • message must include timestamp, nonce, B's identity and is signed by A

39. Two-Way Authentication • 2 messages (A->B, B->A) which also establishes in addition: • the identity of B and that reply is from B • that reply is intended for A • integrity & originality of reply • reply includes original nonce from A, also timestamp and nonce from B

40. Three-Way Authentication • 3 messages (A->B, B->A, A->B) which enables above authentication without synchronized clocks • has reply from A back to B containing signed copy of nonce from B • means that timestamps need not be checked or relied upon

41. X.509 Version 3 • has been recognised that additional information is needed in a certificate • email/URL, policy details, usage constraints • rather than explicitly naming new fields defined a general extension method • extensions consist of: • extension identifier • criticality indicator • extension value

42. Certificate Extensions • key and policy information • convey info about subject & issuer keys, plus indicators of certificate policy • certificate subject and issuer attributes • support alternative names, in alternative formats for certificate subject and/or issuer • certificate path constraints • allow constraints on use of certificates by other CA’s

43. Summary • have considered: • Kerberos trusted key server system • X.509 authentication and certificates