1 / 34

KERBEROS

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

berk-santana
Download Presentation

KERBEROS

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. KERBEROS

  2. 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

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

  4. 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

  5. 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

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

  7. How Does it Work? • Authenticate • Receive TGT • Using TGT • Request Service Ticket • Receive Service Ticket • Get Service

  8. 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

  9. Kerberos 4 Overview

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

  11. KERBEROS Kerberos: The Version 4 Authentication Dialog Cont. 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 ] 3- TICKETtgs + AUTHENc + IDv 4-EKc.tgs[ Kc.v,IDv,TS4,TICKETv]

  12. 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]

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

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

  19. X.509 AUTHENTICATION SERVICE

  20. 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

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

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

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

  24. 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

  25. 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.

  26. X.509 Certificates

  27. 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

  28. Certificate revocation

  29. 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

  30. 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>>

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

  32. 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

  33. 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

  34. 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

More Related