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? Authenticate Receive TGT Using TGT Request Service Ticket Receive Service Ticket Get Service

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

Kerberos 4 Overview Stallings Fig 14.1. Discuss in relation to Table 14.1 which details message exchanges.

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

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

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

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 3-Request ticket for remote TGS 7-request for remote service 4-Ticket for remote TGS 5-Request ticket for remote server 6-Ticket for remote server

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 31/03/2005 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 is the Internationally accepted standard for how to construct a public key certificate, and is becoming widely used. It has gone through several versions. It is used by S/MIME secure email, SSL/TLS secure Internet links (eg for secure web).

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 where Y<<X>>= 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. The X.509 certificate is the heart of the standard. There are 3 versions, with successively more info in the certificate - must be v2 if either unique identifier field exists, must be v3 if any extensions are used.

X.509 Certificates Stallings Fig 14.3

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 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> X2<<B>> 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>>W<<V>>V<<Y>>Y<<Z>> Z<<B>> B acquires A certificate using chain: Z<<Y>>Y<<V>>V<<W>>W<<X>> X<<A>>

Authentication Procedures X.509 includes three alternative authentication procedures: One-Way Authentication Two-Way Authentication Three-Way Authentication all use public-key signatures The X.509 standard specifies the authentication protocols that can be used when obtaining and using certificates. 1-way for unidirectional messages (like email), 2-way for interactive sessions when timestamps are used, 3-way for interactive sessions with no need for timestamps (and hence synchronised clocks).

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 tA = timestamp,rA = nonce (unique within expiration time), IDB=B's identity,sgnData = information (guaranteed authenticity and integrity),Kab = 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