1 KERBEROS AND X 509 2 Authentication Applications
1 KERBEROS AND X. 509
2 Authentication Applications • developed to support application-level authentication & digital signatures • Kerberos – a private-key authentication service • X. 509 directory authentication service
3 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 out the network • without need to trust all workstations • trust a central authentication server • two versions in use: 4 & 5
4 Kerberos Requirements • Security – no evesdropping by potential opponent • Reliability – support all services and employ distributed server architecture • Transparency – user not aware of authentication service • Scalability – support large number of clients and servers • implemented using an authentication protocol based on Needham-Schroeder – trusted third party authentication service.
5 Why Kerberos is needed ? Problem: No trusted workstation to identify their users correctly in an open distributed environment 3 Threats: Pretending to be another user from the workstation • Sending request from the impersonated workstation • Replay attack to gain service or disrupt operations •
6 Why Kerberos is needed ? Cont. Solution: § Building elaborate authentication protocols at each server § Provides a centralized authentication server to authenticate users to servers and servers to users. § Relies on conventional encryption, making no use of public-key encryption § Two versions: version 4 and 5 § Version 4 makes use of DES
7 Kerberos 4 Overview • a basic third-party authentication scheme • have an Authentication Server (AS) • users initially negotiate with AS to identify themselves • 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
8 A Simple Authentication Dialogue • (1) C -> AS : IDC || PC || IDV • C = client • AS = authentication server • IDC = identifier of user on C • PC = password of user on C • IDV = identifier of server V • C asks user for the password • AS checks that user supplied the right password
9 Message 2 • (2) AS -> C : Ticket • Ticket = E K(V) [IDC || ADC || IDV] • K(V) = secret encryption key shared by AS and V • ADC = network address of C • Ticket cannot be altered by C or an adversary
10 Message 3 • (3) C -> V: IDC || Ticket • Server V decrypts the ticket and checks various fields • ADC in the ticket binds the ticket to the network address of C • However this authentication scheme has problems
31/03/2005 Authentication Applications 11 Kerberos Version 4: Dialog 1 - Simple Pc=password of client c 1 - ID + v D I + Pc et k c i T 2 - 3 - ID c +T icke t Ticket=Ekv[IDc, ADc, IDv] kv=Secret Key between AS and V (Server)
12 Problems • Each time a user needs to access a different service he/she needs to enter their password • Read email several times • Print, mail, or file server • Assume that each ticket can be used only once (otherwise open to replay attacks) • Password sent in the clear
31/03/2005 Authentication Applications 13 Kerberos Version 4 : Dialog 2 -More Secure Once per user logon session 1 - ticket. TGS=EKtgs[IDc, ADc, + c ID 2 - c K E IDtgs, TS 1, Life. Time 1 ] s g t ID ] S G T t e k c i [T v D I + c D I t. TGS+ 3 - Ticke 4 -Ticket. V Once per type of service
31/03/2005 Authentication Applications 14 Kerberos Version 4 : Dialog 2 - More Secure Cont. Once per service session 5 - Ticket. V+ IDc Ticket. V=EKv[IDc, ADc, IDv, Ts 2, Lifetime 2]
15 Authentication Dialogue II • Once per user logon session • (1) C -> AS: IDC || IDTGS • (2) AS -> C: E [Ticket. TGS] • Ticket. TGS is equal to • E K(TGS) K(C) [IDC || ADC || IDTGS || TS 1 || Lifetime 1 ]
16 Explaining the fields • TGS = Ticket-granting server • IDTGS = Identifier of the TGS • Ticket. TGS = Ticket-granting ticket or TGT • TS 1 = timestamp • Lifetime 1 = lifetime for the TGT • K (C) = key derived from user’s password
17 Messages (3) and (4) • Once per type of service • (3) C -> TGS: IDC || IDV || Ticket. TGS • (4) TGS -> C : Ticket. V • Ticket. V is equal to • E K(V) [ IDC || ADC || IDV || TS 2 || Lifetime 2 ] K(V): key shared between V and TGS Is called the service-granting ticket (SGT)
18 Message 5 • Once per service session • (5) C -> V: IDC || Ticket. V • C says to V “I am IDC and have a ticket from the TGS”. Let me in! • Seems secure, but. . • There are problems
19 Problems • Lifetime of the TGT • Short : user is repeatedly asked for their password • Long : open to replay attack • Opponent captures TGT and waits for the user to logoff • Sends message (3) with network address IDC (network address is easy to forge) • Same problem with SGT
20 Solutions • A network service (TGS or server) should be able to verify that • person using the ticket is the same as the person that the ticket was issued to • Remedy : use an authenticator • Server should also authenticate to user • Otherwise can setup a “fake” server • A “fake” tuition payment server and capture the student’s credit card • Remedy : use a challenge-response protocol
Summary of Kerberos Version 4 Authentication Dialogues
Kerberos Version 4 Authentication Dialogue
Kerberos Version 4 Authentication Dialogue
Overview of Kerberos
25 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
Request for Service in Another Realm
27 Request for Service in another realm: et k tic t es TGS u eq cal S R G o 1 rl l. T a o f S loc G r T fo t te e o ick em r T ice v 2 r or e s f mote e r et r o k f est u ic q t e r 7 st e qu e 3 -R 4 -Ticket for remote TGS 5 -Request ticket for remote server 6 -Ticket for remote server
Kerberos Version 5 • developed in mid 1990’s • provides improvements over v 4 • addresses environmental shortcomings • encryption algorithm, network protocol, byte order, ticket lifetime, authentication forwarding, inter-realm authentication • and technical deficiencies • double encryption, non-standard mode of use, session keys, password attacks • specified as Internet standard RFC 1510
29 KERBEROS Version 5 versus Version 4 • Environmental shortcomings of Version 4: • Encryption system dependence: DES • Internet protocol dependence • Ticket lifetime • Authentication forwarding • Inter-realm authentication
30 KERBEROS Version 5 versus Version 4 • Technical deficiencies of Version 4: • Double encryption • PCBC encryption • Session Keys • Password attack
31 New Elements in Kerberos Version 5 • Realm • Indicates realm of the user • Options • Times • From: the desired start time for the ticket • Till: the requested expiration time • Rtime: requested renew-till time • Nonce • A random value to assure the response is fresh
32 Kerberos Version 5 Message Exchange: 1 • To obtain ticket-granting ticket: (1)C AS : Options || IDc || Realmc || IDtgs ||Times || Nonce 1 (2) AS C : Realmc || IDc || Ticket tgs || EKc [ Kc, tgs || IDtgs || Times || Nonce 1 ||| Realm tgs ] Ticket tgs= EKtgs [ Flags || Kc, tgs || Realm c || IDc || ADc || Times]
33 Kerberos Version 5 Message Exchange: 2 • To obtain service-granting ticket : (3)C TGS : Options || IDv || Times || Nonce 2 || Ticket tgs ║ Authenticator c (4)TGS C : Realmc || IDc || Ticket v || EK c, tgs [ Kc, v ║Times|| Nonce 2 || IDv ║ Realm v] Ticket tgs= EKtgs [ Flags || Kc, tgs || Realm c || IDc || ADc || Times] Ticket v : EK v [Kc, , v ║ Realmc || IDc ║ ADc ║ Times ] Authenticator c : EK c, tgs [IDc ║ Realmc ║ TS 1]
34 Kerberos Version 5 Message Exchange: 3 • To obtain service (5) C S : Options || Ticket v|| Authenticator c (6) S C : EK c, v [TS 2|| Subkey || Seq# ] • Ticket v : EK v [Flags || Kc, v || Realmc || IDc || ADc || Times ] • Authenticator c : EK c, v [IDc || Realmc || TS 2 || Subkey|| Seq# ]
35 Kerberos : Strengths • User's passwords are never sent across the network, encrypted or in plain text • Secret keys are only passed across the network in encrypted form • Client and server systems mutually authenticate • It limits the duration of their users' authentication. • Authentications are reusable and durable • Kerberos has been scrutinized by many of the top programmers, cryptologists and security experts in the industry
36 Certificate: • Electronic counterparts to driver licenses, passports • Verifies authenticity of the public key • Prevents impersonation • Enables individuals and organizations to secure business and personal transactions
37 What a certificate includes: • Name of Entity being Certified • Public Key • Name of Certificate Authority • Serial Number • Expiration Date • Digital signature of the issuer • Other information (optional)
38 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
39 X. 509 Certificate format Version Serial number Algorithm Parameters Algorithm identifier Issuer Not before Not after Subject Algorithm Parameter Key Signature Period of validity Notation to define a certificate: CA<<A>>=CA{V, SN, AI, CA, Ta, A, Ap} where Y<<X>>= the certificate of user X issued by certification authority Y Y{I}=the signing of I by Y. It Subject’s consists of I with an enciphered public key hash code appended.
40 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 (v 2+) • subject unique identifier (v 2+) • extension fields (v 3) • signature (of hash of all fields in certificate) • notation CA<<A>> denotes certificate for A signed by CA
X. 509 Certificate Formats 41
42 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
43 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
CA Hierarchy Use 44
45 Certificate Revocation certificates have a period of validity may need to revoke before expiry • • 1. 2. 3. CA’s maintain list of revoked certificates • • • user's private key is compromised user is no longer certified by this CA CA's certificate is compromised the Certificate Revocation List (CRL) users should check certs with CA’s CRL
46 Authentication Procedures • X. 509 includes three alternative authentication procedures: • One-Way Authentication • Two-Way Authentication • Three-Way Authentication • all use public-key signatures
47 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 A 1 -A {ta, ra, B, sgn. Data, KUb[Kab]} Ta-timestamp r. A=nonce B =identity sgn. Data=signed with A’s private key B
48 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 1 -A {ta, ra, B, sgn. Data, KUb[Kab]} A B 2 -B {tb, rb, A, sgn. Data, KUa[Kab]}
49 Three-Way Authentication • 3 messages (A->B, B->A, A->B) which enables above authentication without synchronized clocks 1 - A {ta, ra, B, sgn. Data, KUb[Kab]} A 2 -B {tb, rb, A, sgn. Data, KUa[Kab]} 3 - A{rb} B
50 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
51 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
52 Summary • have considered: • Kerberos trusted key server system • X. 509 authentication and certificates
- Slides: 52
