KERBEROS

Introduction trusted key server system from MIT.Part of project Athena (MIT).Developed in mid 1980s. 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 Kerberos versions: – First publicly released v4 in widespread use, but there are some security flaws – v5 is the most recent version, more complicated

What is KERBEROS ? A computer network authentication protocol Provides a centralized authentication server to authenticate users to servers and servers to users in a secure manner Relies on conventional encryption, making no use of public-key encryption Prevents eavesdropping or replay attack Two versions: version 4 and 5 Version 4 makes use of DES Version 5 supports any encryption alg.(authentication)

Why Kerberos? Sending usernames and passwords in the clear jeopardizes the security of the network. Each time a password is sent in the clear, there is a chance for interception. To be able to access all my resources from anywhere on the network. Don’t want to be entering password to authenticate myself for each access to a network service. Time comsuming Insecure

Why Kerberos? Problem: A workstation can not be trusted 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

Why Kerberos? Solution: – Building elaborate authentication protocols at each server – A centralized authentication server (Kerberos)

How Does it Work? 1. Authenticate 2.Receive TGT Using TGT 1.Request Service Ticket 2.Receive Service Ticket 3.Get Service

Authentication Service (AS) Ticket Granting Service (TGS) (KDC) Kerberos client AppServ 1. Request a ticket for TGS 2. Return TGT to client 3. Send TGT and request for ticket to AppServ 4. Return ticket for AppServ 5. Send session ticket to AppServ 6. (Optional) Send confirmation of identity to client Domain Authentication and Resource Access

Kerberos 4 Overview

Kerberos: The Version 4 Authentication Dialog 1- IDc + IDtgs +TS1 2- EKc [Kc.tgs,IDtgs,TS2, LIFETIME 2, TICKET tgs] KERBEROS Once per user logon session TICKETtgs=EKtgs [Kc.tgs, IDc,ADc,IDtgs,TS2, LIFETIME2 ]

Kerberos: The Version 4 Authentication Dialog Cont. KERBEROS 3- TICKETtgs + AUTHENc + IDv 4-EKc.tgs[ Kc.v,IDv,TS4,TICKETv] Once per type of service TICKETtgs=EKtgs [Kc.tgs,IDc,ADc,IDtgs, TS2, LIFETIME2 ] AUTHENc=EKc.tgs[IDc,ADc,TS3] TICKETv=EKv[Kc.v, IDc, ADc, IDv, TS4, LIFETIME4 ]

Kerberos: The Version 4 Authentication Dialog Cont. 5- TICKETv+ AUTHENc Once per service session TICKETv=EKv [Kv.c, IDc, ADc, IDv, TS4, LIFETIME4] AUTHENc=EKc.v [IDc,ADc,TS5] 6- EKc.v[TS5+1]

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

Inter-realm Authentication Kerberos server in each realm shares a secret key with other realms. It requires – Kerberos server in one realm should trust the one in other realm to authenticate its users – The second also trusts the Kerberos server in the first realm

Inter-realm Authentication For scalability it’s advantageous to divide the network into realms each with its own AS and TGS Realms registered with Remote TGS, RTGS. Access service will now require – User request for RTGS from TGS, – User request for Service from RTGS

Request for Service in another realm 1-Request ticket for local TGS 2-Ticket for local TGS 5-Request ticket for remote server 6-Ticket for remote server 3-Request ticket for remote TGS 4-Ticket for remote TGS 7-request for remote service

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

Compare Version 4 and Version 5 i.e. Environmental shortcomings and Technical deficiencies of Ver. 4

X.509 AUTHENTICATION SERVICE

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

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)

Certificate Authorities Trusted entity which issue and manage certificates for a population of public-private key-pair holders. A digital certificate is issued by a CA and is signed with CA’s private key.

Who are the Certificate Authorities? VeriSign GTE CyberTrust Entrust IBM CertCo USPS / Cylink

X.509 Authentication Service part of X.500 directory service standards – Server or distributed servers maintaining some user 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 introduced in 1988 uses public-key crypto & digital signatures – algorithms not standardised, but RSA recommended – Digital signature - use of hash function

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 > denotes certificate for A signed by CA where Y >= the certificate of user X issued by certification authority Y Y{I}=the signing of I by Y. It consists of I with an enciphered hash code appended.

X.509 Certificates

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

Certificate revocation

Securely Obtain a Public Key Scenario: – A has obtained a certificate from the CA X1 – B has obtained a certificate from the CA X2 – A can read the B’s certificate but cannot verify it. Solution: X1 X2 > – A obtains the certificate of X2 signed by X1 from directory.  obtain trusted copy of X2’s public key – A goes back to directory and obtain the certificate of B signed by X2.  obtain B’s public key securely

X.509 CA Hierarchy A acquires B certificate using chain: X >W > V >Y > Z > B acquires A certificate using chain: Z >Y >V >W > X >

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

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 t A = timestamp,r A = nonce (unique within expiration time), ID B =B's identity,sgnData = information (guaranteed authenticity and integrity),K ab = optional session key

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

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