Cybersecurity - Ch04 INFS307 PDF

CYBERSECURITY Rabie A. Ramadan CYBERSECURITY 2 ACM TURING AWARD Peter Naur won the 2005 ACM A.M. Turing Award for his work on defining the Algol 60 programming language In particular, his role as editor of the influential "Report on the Algorithmic Language Algol 60" with its pi...

CYBERSECURITY Rabie A. Ramadan CYBERSECURITY 2 ACM TURING AWARD Peter Naur won the 2005 ACM A.M. Turing Award for his work on defining the Algol 60 programming language In particular, his role as editor of the influential "Report on the Algorithmic Language Algol 60" with its pioneering use of BNF was recognized http://www.naur.com/ 3 Application Level Authentication 4 WHY APPLICATION-LEVEL SECURITY?  Open Environment  Clients Access Services  Restrict Access to Authorized Users  Workstation Can’t Be Trusted  Impersonate a Workstation (Spoof)  Eavesdrop and Replay  Firewalls Don’t Always Do It 5  KERBEROS MIT – 1988 – Project Athena Protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. Client and server can also encrypt all of their communications to assure privacy and data integrity as 6  KERBEROS Cerberus was a three-headed hound who patrolled the shore of the river Styx (Hades), devouring both living intruders and fugitive ghosts. For Hercules' twelfth task, he was to bring Cerberus up from the underworld without any weapons 7  PIONEERING WORK OF FAMOUS MIT PROFESSOR 8  KERBEROS Provides a centralized authentication server – authenticate users to servers and servers to users Relies exclusively on conventional encryption Version 4 & Version 5 (RFC 1510) 9  KERBEROS REQUIREMENTS Secure – no masquerading Reliable – distributed server architecture Transparent – user unaware authentication is taking place Scalable – supports large number of clients and servers 10  SIMPLE CLIENT AUTHENTICATION Obvious risk: impersonation Server needs to confirm identity of each client – NOT scalable Use an authentication server (AS)  Knows password of all users 11  SIMPLE KERBEROS IDC || PC || IDV AS User logs on and requests access to (2) (1) server V C Ticket Client module requests user (3) IDC || Ticket password V Sends message to the AS with user’s ID, Ticket = EKV[IDC || ADC || IDV] server’s ID and user’s password 12  SIMPLE KERBEROS IDC || PC || IDV AS checks database to AS see if user has supplied (1) (2) the proper password and is permitted to C Ticket access server V (3) If authentic, then IDC || Ticket creates a ticket V containing user’s ID, network address, asn Ticket = EKV[IDC || ADC || IDV] server’s ID 13  SIMPLE KERBEROS IDC || PC || IDV AS Ticket is encrypted using the secret key (2) (1) shared by the AS and C the server V Ticket Send ticket back to C (3) IDC || Ticket Because the ticket is V encrypted, it cannot be altered by C or an Ticket = EKV[IDC || ADC || IDV] attacker 14  SIMPLE KERBEROS C can now apply to V for IDC || PC || IDV service AS C sends message to V (1) (2) with user’s ID and the ticket C Ticket Server’s IDV is included so (3) that the server can verify IDC || Ticket it has decrypted the V ticket properly Ticket is encrypted to Ticket = EKV[IDC || ADC || IDV] prevent capture or forgery 15 SIMPLE KERBEROS IDC || PC || IDV V decrypts the ticket and AS verifies that the user IDC in the ticket is the same (1) (2) as in the message C Ticket ADC in the message guarantees it came from (3) IDC || Ticket original requesting workstation V Finally, V grants the Ticket = EKV[IDC || ADC || IDV] requested service 16...BUT THERE’S A PROBLEM, JON! How many passwords do The password you want me is in the clear! to enter? 17  TICKET GRANTING SERVER (TGS) A TGS issues tickets to users who have been authenticated to the AS User first requests a ticket granting ticket, Tickettgs, from the AS and saves it in the client’s workstation A client requesting services applies to the TGS using the ticket to authenticate itself TGS then grants a ticket, TicketV, for the particular service Client saves this and uses it each time a service is requested 18  SIMPLE KERBEROS W/TGS IDC || IDtgs AS Client requests a ticket granting ticket (2) (1) on behalf of user C EKC[Tickettgs] Sends user’s ID and Ticket V (3) (5) the ID of the TGS IDC || TicketV (4) Indicates request for V TGS service TGS IDC || IDV|| Tickettgs Tickettgs=EKtgs[IDC||ADC||IDtgs||TS1||Lifetime1] TicketV=EKV[IDC||ADC||IDV||TS2||Lifetime2] 19  SIMPLE KERBEROS W/TGS IDC || IDtgs AS AS responds with a ticket that is (2) (1) encrypted with a key C from user’s password Ticket EKC[Tickettgs] (5) V (3) IDC || TicketV (4) V TGS IDC || IDV|| Tickettgs Tickettgs=EKtgs[IDC||ADC||IDtgs||TS1||Lifetime1] TicketV=EKV[IDC||ADC||IDV||TS2||Lifetime2] 20  SIMPLE KERBEROS W/TGS IDC || IDtgs AS Client prompts user for password, generates key (2) (1) and decrypts message C EKC[Tickettgs] Ticket is recovered! Ticket V (3) (5) No need to transmit IDC || TicketV (4) password in plaintext V Ticket(tgs) is reusable TGS IDC || IDV|| Tickettgs Tickettgs=EKtgs[IDC||ADC||IDtgs||TS1||Lifetime1] TicketV=EKV[IDC||ADC||IDV||TS2||Lifetime2] 21  SIMPLE KERBEROS W/TGS IDC || IDtgs AS Client requests a service granting ticket (1) (2) Sends message to TGS C EKC[Tickettgs] containing user’s ID, Ticket V (3) (5) ID of the desired IDC || TicketV service and the ticket (4) V granting ticket TGS IDC || IDV|| Tickettgs Tickettgs=EKtgs[IDC||ADC||IDtgs||TS1||Lifetime1] TicketV=EKV[IDC||ADC||IDV||TS2||Lifetime2] 22  SIMPLE KERBEROS W/TGS IDC || IDtgs TGS decrypts the AS incoming ticket and (2) looks for presence of (1) its ID TicketV C EKC[Tickettgs] Checks lifetime and (5) (3) authenticates the user IDC || TicketV (4) If user permitted V IDC || IDV|| Tickettgs access, sends service TGS granting ticket Tickettgs=EKtgs[IDC||ADC||IDtgs||TS1||Lifetime1] TicketV=EKV[IDC||ADC||IDV||TS2||Lifetime2] 23  SIMPLE KERBEROS W/TGS IDC || IDtgs Client requests access AS to service on behalf of (2) (1) the user C E [Ticket ] Sends user’s ID and Ticket KC tgs V (3) (5) service granting ticket ID || Ticket (4) C This can happen V V repeatedly without TGS ID || ID || Ticket C V prompting for tgs tgs Ktgs C C password Ticket =E [ID ||AD ||ID ||TS ||Lifetime ] tgs 1 1 TicketV=EKV[IDC||ADC||IDV||TS2||Lifetime2] 24  VERSION 4 AUTHENTICATION Problems:  Lifetime associated with the ticket granting ticket – too short, repeated password prompting; too long, vulnerable to capture  Server authentication to user – false server could act as a real server 25 VERSION 4 AUTHENTICATION Session Key – this is included in the encrypted message, KC,tgs and KC,V Authenticator – encrypted with the session key it includes the user ID and address of the client and a timestamp. It is used only once – short lifetime 03/06/06 Hofstra University – Network Security Course, 26 CSC290A OVERVIEW OF KERBEROS 27 KERBEROS REALMS A realm is a collect of clients and servers under single administration such that  Kerberos server has the user ID and hashed password of all participating users in its database (all users registered with Kerberos)  Kerberos server shares a secret key with each server (all servers registered with Kerberos) 28  KERBEROS REALMS Users in one realm may need access to servers in another realm Kerberos server in each interoperating realm shares a secret key with the server in the other realm (Kerberos servers are registered with each other) The Kerberos server in one realm must trust the Kerberos server in the other realm to authenticate its 29 REQUESTING SERVICE IN ANOTHER REALM 30  KERBEROS REALMS Doesn’t scale well to many realms Given N realms, there must be N(N-1)/2 secure key exchanges between each of the Kerberos servers 31 KERBEROS VERSION 5 Specified in RFC 1510 – 1993 Does not depend on DES - can use any encryption technique Arbitrary ticket lifetime – start and end time Authentication forwarding Interrealm authentication – eliminates N2 order of K-to-K relationships 32  KERBEROS VERSION 5 Number of new improvements: Session keys – client and server can negotiate a subsession key, used only for one connection Password attacks – preauthentication mechanism Ticket flags – expanded functionality 33 NOT TOO SHABBY, HUH! 03/06/06 HOFSTRA UNIVERSITY – NETWORK 34 SECURITY COURSE, CSC290A  X.509 AUTHENTICATION SERVICE X.509 is part of X.500 series which defines a directory service 1988, V2-1993, V3-1995 Based on public-key cryptography and digital signatures Defines a framework for the provision of authentication services Repository of public key certificates Used in S/MIME, IPSec, SSL and SET 35  CERTIFICATES Each certificate contains the public key of a user and is signed with the private key of a trusted certification authority A certificate is associated with each user It’s the heart of the X.509 scheme 36  CERTIFICATE NOTATION Y{I} = the signing of I by Y CA = CA {V, SN, AI, CA, TA, A, AP} certificate of user A issued encrypted hash code by certification authority CA 37  CERTIFICATE CHARACTERISTICS If you have the public key of the CA, you can recover the user public key that was certified Only the certificate authority can modify the certificate Placed in a directory without special protection 38  CERTIFICATE CHARACTERISTICS If all users subscribe to the same CA, then there is common trust of that CA User can transmit his certificate directly to others Assured messages are secure from eavesdropping and unforgeable Not all users can subscribe to the same CA 39  CHAIN OF CERTIFICATES certificates for each CA are maintained in the directory CA forward certificate Hierarchy reverse certificates 40  REVOCATION OF CERTIFICATES Certificates have a period of validity Certificates can also be revoked because:  user’s key is compromised  user no longer certified by CA  CA’s certificate is assumed to be compromised CA maintains a list of revoked 41  CERTIFICATE REVOCATION LIST (CRL) 42  AUTHENTICATION PROCEDURES X.509 includes three authentication procedures making use of public key signatures Intended for a variety of applications Assumes two parties know each other’s public key 43  TWO WAY AUTHENTICATION A{tA, rA, B, sgnData, EKUB[Kab]} A B{tB, rB, A, rA, sgnData, EKUA[Kba]} B nonce from A – validates reply Establishes the identity of B and that the reply message was generated by B The message was intended for A Establishes the integrity and originality of the reply Both parties verify the identity of the other 44  THREE WAY AUTHENTICATION A{tA, rA, B, sgnData, EKUB[Kab]} A B{tB, rB, A, rA, sgnData, EKUA[Kba]} B A{rB} Final message from A to B is included, with a signed copy of the nonce rB No need for timestamps; each sides echoes back a nonce to prevent replay Used when no synchronized clocks available 45 X.509 VERSION 3 REQUIREMENTS Subject field needs to convey more information about the key owner Subject field needs more info for applications: IP address, URL Indicate security policy information (IPSec) Set constraints on certificate applicability – limit damage from faulty CA Identify separately different keys used by the same owner at different times – key life cycle management 46 X.509 VERSION 3 EXTENSIONS Added optional extensions rather than fixed fields {extension id, criticality indicator, extension value} Three main categories:  Key and policy information – EDI only  Certificate subject and issuer attributes – alternative names  Certification Path Constraints - restrictions 47 IMPORTANT URLS http://web.mit.edu/kerberos/www/ Information about Kerberos, including the FAQs, papers and documents and pointers to commercial product sites http://www.ietf.org/html.charters/pkix-charter.html Information from the IETF about X.509 http://www.verisign.com/ One of the leading commercial vendors of X.509 http://csrc.nist.gov/pki/ Good source of info on PKI and other crypto subjects 48 IMPORTANT URLS http://http://primes.utm.edu/ Prime Number research, records, and resources. Checkout “Prime Curios!” - a collection of curiosities, wonders and trivia related to prime numbers. http://www.certicom.com/ Lots of material on elliptic curve cryptography. 49  HOMEWORK Read Chapter Four 50 HAVE A NICE WEEK!!! 51