California State University Sacramento Computer Science Department CSc

California State University, Sacramento Computer Science Department CSc 296 Q Network Security Wed. 7: 00 – 9: 50 PM, RVR 1010 Oct. 5, 2005 CSc 296 Q Network Security Page 1

Secure Protocols r Layer 5 (Application) m Remote Access: SSH, Secure ftp, SCP m WEB: HTTPS, SHTTP m DNS: DNSSec m Email: PGP, GPG, S/MIME, SIMAP, Secure SMTP extension m Authentication: Kerberos, RADIUS r Layer 4 (Transport) m SSL/TLS, SSL VPN m Stunnel r Layer 3 (Network) m IPSec VPN m Security mechanisms in OSPF and BGP r Layer 2 (Data Link) m L 2 TP, PPTP VPN m L 2 F Oct. 5, 2005 CSc 296 Q Network Security Page 2

PGP Oct. 5, 2005 CSc 296 Q Network Security Page 3

PGP (Pretty Good Privacy) r Personal high-security cryptographic software that allows people to exchange messages or files with privacy, authentication, and convenience. r PGP can be used to encrypt and digitally sign files and e-mail m m m Send E-mail securely to a known recipient Digitally sign E-mail so that the recipient(s) can be sure it is from you Strong cryptographic algorithms (IDEA, RSA, SHA-1) r can be used by corporations as well as individuals r Unlike S/MIME, it doesn’t require Public Key Infrastructure r PGP is now on an Internet standards track (RFC 3156) Oct. 5, 2005 CSc 296 Q Network Security Page 4

PGP History r First version developed by Phil Zimmermann and released on the Internet in 1991 m m Original version had his own encryption routine, which was insecure Replaced with IDEA, and RSA r Big legal battle over patents -> Resulted in two versions m US version which uses RSA shareware library m International version based in Norway, PGP-i r Got immediate government attention. m PGP appeared outside of US (naturally). In 1993 he received criminal investigation for “munition” export without license. But it was closed without charge in 1996. (40 -bit+ key is considered weapon) m Since 2000, PGP is no longer considered non-exportable weapon r In 1996, started a company, merged with Via. Crypt , changed name r r to PGP Inc. was purchased by Network Associates in 1998. Zimmerman left NAI in 2001, joining Hush Communications (Hushmail) In 2002, NAI stopped support of PGP. In 2002, ex-PGP members founded PGP Corp. and bought PGP assets from NAI Oct. 5, 2005 CSc 296 Q Network Security Page 5

PGP Services r For Messages m authentication m confidentiality m compression m e-mail compatibility (7 -bit ASCII) m segmentation and reassembly r key management m generation, distribution, and revocation of public/private keys m generation and transport of session keys and IVs Oct. 5, 2005 CSc 296 Q Network Security Page 6

Message Authentication r based on digital signatures r supported algorithms: e. g. , RSA/SHA and DSS/SHA r Process 1. Run your document through hash and generate a fingerprint. 2. Encrypt the fingerprint with your private key. 3. Send the document to the receiver R. 4. R runs the same hash algorithm on it, generates a fingerprint, 5. R decrypts the received signature using your public key 6. R compares the two. If no match, the document has been altered in transmission. Oct. 5, 2005 CSc 296 Q Network Security Page 7

Digitally Signing in PGP -----BEGIN PGP SIGNED MESSAGE----Hash: SHA 256 Hello everyone! Welcome to CSc 296 Q Network Security Please check the digital signature below. -----BEGIN PGP SIGNATURE----Version: PGP Desktop 9. 0. 2 (Build 2424) i. QEUAw. UBQ 0 OOICGBq. Ghf. RFh 0 AQi. JRgf 3 e 4 NO 10 ZEFlf. LUIwq. UBIz. Lq. YW 8 Vq 0 emh. V Hq. I 9 MYCS 4 Ca 3 k. Ida. OTNk 1 QKTp. WUn. Zmz. O/8 zo. Ql. Dwa 3 d. KH 3/Wog. Ug. TLu. Iwu. S 1 phy 2 uf. G 0 d. GNvoe. KUIYNy. RCQ 28 Y 0 m. S 0 nb 6 r 1 sz. J 2 Cq 7 Es. KYO 9 S 6 e. IAwe. UX 5 SWo. P 1 W 2 kf. Q Pgg. QHjj. Au. XHYxzy 8 a 27 Zgb. G 6 b. VUQYM 7 wp. KL 5 e. Jc. Rj+YLEo 71 V 6 fd. Q 6 z+Yb. Hs 6 CUP zr/1 ie/P 5 Geu 6 u. Vi. LYwvk. JPGh. YBt 4 g. T 3 Atpi 5 a. KCm 1 Wm. No. Wp. CWu. DE 26 x 622 yr. Dt. B En/j. GPy. FSQN 5 D 6 b 4 is 0 UOy. N 6 KAVcr. Wi. ZRv. P 5 QCk 6 r 5 cx. Kttc. L 2 eg =x. XEL *** PGP SIGNATURE VERIFICATION *** -----END PGP SIGNATURE----*** Status: Good Signature *** Signer: Ju-Yeon Jo < joj@ecs. csus. edu> (0 x 5 F 445874) *** Signed: 10/5/2005 1: 26: 08 AM *** Verified: 10/5/2005 1: 27: 17 AM *** BEGIN PGP VERIFIED MESSAGE *** Hello everyone! Welcome to CSc 296 Q Network Security Please check the digital signature below. Oct. 5, 2005 *** END PGP VERIFIED MESSAGE *** CSc 296 Q Network Security Page 8

Message Confidentiality r Symmetric key encryption with a random session key and IV m Session key and IV is encrypted with the public key of the receiver r Supported algorithms m public key: • DSA (1024 bit signing key) • RSA (2048 bit keys are popular, adequate, and interoperable) m secure hash / message digest • MD 5 • SHA-1 m block cipher • • Oct. 5, 2005 IDEA 3 DES CAST-128 AES-128 or AES-256 (not available in older clients) CSc 296 Q Network Security Page 9

Compression r applied after the signature r applied before encryption m compression reduces redundancy makes cryptanalysis harder r supported algorithm: ZIP Oct. 5, 2005 CSc 296 Q Network Security Page 10

PGP vs. Open. PGP (From Wikipedia) Oct. 5, 2005 CSc 296 Q Network Security Page 11

E-mail Compatibility r Encrypted messages and signatures may contain arbitrary octets (binary data) r As most e-mail systems support only ASCII characters, PGP converts an arbitrary binary stream into a stream of printable ASCII characters r radix 64 conversion: m Three Oct. 5, 2005 8 -bit blocks Four 6 -bit blocks CSc 296 Q Network Security Page 12

PGP Key Management Oct. 5, 2005 CSc 296 Q Network Security Page 13

Key Pairs – Public vs. Private r Types of Key – RSA vs DH/DSS r Public key is widely disseminated r Private key is kept secret with passphrase m m Use an actual phrase and not just a single password. passphrases are casesensitive! r Fingerprints r Varying levels of security m 512 -bit lowest. m 2048 -bit very secure Oct. 5, 2005 CSc 296 Q Network Security Page 14

PGP Public Key r You can export your public key from PGPKeys with copy/paste, drag/drop, etc. r Since it’s a public key, you can put it anywhere m email it in plaintext, m put it on a web page, etc. m put it on a “key server” for others to look up m Etc. Oct. 5, 2005 CSc 296 Q Network Security Page 15

Key IDs r a receiver may have several public key / private key pairs m m which private key to use to decrypt the session key? which public key to use to verify a signature? r transmitting the whole receiver’s public key back to the receiver would be wasteful (or sender’s public key in case of signature) r associating a random ID to a public key would result in management burden r PGP key ID: last 64 bits of the fingerprint m unique within a user with very high probability Oct. 5, 2005 CSc 296 Q Network Security Page 16

Private-key Ring r used to store the public key – private key pairs owned by a given user r essentially a table, where each row contains the following entries: m m m timestamp key ID (indexed) public key encrypted private key user ID (indexed) passphrase hash private key encrypted private key Oct. 5, 2005 CSc 296 Q Network Security Page 17

Public-key Ring r Used to store public keys of other users The ID of the key’s creator (usually name & email address). m The date the key was created & expiration date. m A list of digital signatures provided by people who attest to the key’s authenticity. r Each entry contains: m m m m m timestamp key ID (indexed) public key user ID (indexed) owner trust signature(s) signature trust(s) key legitimacy Oct. 5, 2005 CSc 296 Q Network Security Page 18

Public-key Revocation r why to revoke a public key? m suspected to be compromised (private key got known by someone) m re-keying r the owner issues a revocation certificate … m has a similar format to normal public-key certificates m contains the public key to be revoked m signed with the corresponding private key r and disseminates it as widely and quickly as possible Oct. 5, 2005 CSc 296 Q Network Security Page 19

PGP Trust Problem Oct. 5, 2005 CSc 296 Q Network Security Page 20

PGP: Trust Problems r How do you know a public key is really tied to a person the person it is claimed to be? m no trust path from signer to you m no 3 rd party signatures on key m unreliable 3 rd party signatures on key r don’t rely on PGP key Server m It is not a root Certificate Authority m It means e-mail address works and possesses the private key. But, there is no identity implication, unlike signatures from people r Fake keys exist m e. g. Phil Zimmerman, Bill Gates, … Oct. 5, 2005 CSc 296 Q Network Security Page 21

Obtaining the Key Directly from the Recipient r Get the recipient’s public key, then add it to your public keyring. m Typically they do this by sending an email to you. r But what if someone in the middle gave you a fake key? True PK A Fake PK Evil Genius True Encrypted mail You Phony Encrypted Mail r Call the receiver, and ask to read it back. m Too long? Then use the fingerprint instead(MD 5 hashing) Oct. 5, 2005 CSc 296 Q Network Security Page 22

PGP: Web of Trust r Alice generates a key r Alice gets other PGP users to sign her public key using their private keys r Bob obtains Alice’s public key from somewhere m a keyserver m a web server m directly from Alice r Hopefully, Bob trusts one of the signers of Alice’s key m he can locally sign Alice’s key to signal he has validated it r Bob is free to decide how much to trust Oct. 5, 2005 CSc 296 Q Network Security Page 23

Trust Path Oct. 5, 2005 CSc 296 Q Network Security Page 24

PGP Implementation r PGP, from PGP Corp m Until PGP 8. 0, freeware was available m From 9. 0, 30 -day trial. m PGP Desktop Home 9. 0: $99 r Gnu Privacy Guard (Gnu. PG or GPG) m Free from FSF m Replacement for PGP m Compliant to IETF Open. PGP (RFC 2440) • PGP is interoperable with GPG or other Open. PGP-compliant systems m command line tools r Other implementations m Hushmail, Veridis, Artisoft, Forum, Zendit, … m Very good interoperability Oct. 5, 2005 CSc 296 Q Network Security Page 25

Quiz r True / False m PGP employs X. 509 public key hierarchy m In both PGP and S/MIME, the entire message is encrypted using the recipient’s public key m It is possible to create a fake PGP key and post it m In PGP, a sender can send email only to one receiver at a time. m Radix 64 encoding converts binary data into 7 -bit ASCII by packing • 7 bytes (56 bits) into 8 7 -bit ASCII (56 bits) ? • 3 bytes (24 bits) into 4 6 -bit ASCII (24 bits) ? Oct. 5, 2005 CSc 296 Q Network Security Page 26

Kerberos Chapter 18. 1 Oct. 5, 2005 CSc 296 Q Network Security Page 27

Kerberos http: //web. mit. edu/kerberos Cer·ber·us (sûr’bər-əs) noun Greek & Roman Mythology. A three-headed dog guarding the entrance to Hades Oct. 5, 2005 CSc 296 Q Network Security Page 28

Issues in Network Authentication r Attacks m An attacker may pretend to be another user m An attacker can eavesdrop and perform a replay attack m An attacker can change source address r Key Management m How do you deliver a key? m Coping with key pair explosion = n*(n-1)/2 Oct. 5, 2005 CSc 296 Q Network Security Page 29

Kerberos r Network authentication protocol m Authenticates the identity of users attempting to log on to a network and encrypts their communications through secret-key cryptography m provides centralized third-party authentication in a distributed network (all trust a central authentication server) m allows users access to services distributed through network r Prevents eavesdropping or replay attack and ensures data integrity r RFC 1510 - The Kerberos Network Authentication Service (V 5) r Where are two other heads? (Accounting, Audit, never implemented) Oct. 5, 2005 CSc 296 Q Network Security Page 30

History of Kerberos r Designed at MIT to protect network services provided by Project Athena m m m Project Athena: a joint project of MIT, Digital Equipment Corporation, and IBM, launched in 1983, and ran through June 30, 1991. Creating a computing environment that would scale up to 10, 000 networked workstations and accommodate heterogeneous hardware. Spawned many technologies such as X Window System, Kerberos, Instant messaging, etc. r Versions m Version 1 -3: internal to MIT m Version 4: 1987 m Version 5: 1993 (RFC 1510) r Like PGP, it was considered munition and banned from export (until ~2000). A non-US implementation existed. Oct. 5, 2005 CSc 296 Q Network Security Page 31

Kerberos Concepts r Requires a trusted third party m Trusted server known as Key Distribution Center (KDC) stores the secret keys m Each entity on the network shares a secret key known only to itself and to Kerberos • This secret passwords are not transmitted over network m Knowledge of this key serves to prove an entity's identity • Political problem: KDC can access everyone’s secret key r Mutual authentication (Both user and server) r Timestamp instead of nonces to prevent replay attack r Builds on symmetric key cryptography m Originally only secret keys, but now use public key Oct. 5, 2005 CSc 296 Q Network Security Page 32

Kerberos Cryptography r Kerberos uses symmetric encryption and MACs. r Specifically, Version 5 (as in RFC 1510) uses DES combined with one of MD 4, MD 5, or a CRC (not recommended). r Release 1. 2 of Kerberos Version 5 allows triple DES (3 DES) in CBC-mode. Oct. 5, 2005 CSc 296 Q Network Security Page 33

Key Distribution Center (KDC) r Authentication Server (AS) m mutual authentication with client at login based on long-term key m gives client ticket granting ticket (TGT) and short-term key. r Ticket Granting Server (TGS) m mutual authentication with client based on short -term key and ticket granting ticket. m TGS then issues tickets giving clients access to further servers demanding authentication Oct. 5, 2005 CSc 296 Q Network Security Page 34

Kerberos Terminology r Client m user or a program r Application server (S) m any computer running services (telnet, ftp, etc) r Tickets m Kerberos data structures that can be safely sent across a network that, when valid, prove to its recipient the authorization of the client to use the recipients services Oct. 5, 2005 CSc 296 Q Network Security Page 35

Kerberos Protocol Overview AS TGS (authentication server) 1 2 C (client) (ticketgranting server) 3 1. 2. 3. 4. 5. 6. TGT Request Encrypted TGT Ticket Request, TGT Encrypted Ticket Service 4 5 S (server) 6 Oct. 5, 2005 CSc 296 Q Network Security Page 36

Security Protocol Notation r Notations m Set of individuals: A, B, C…. m Server: S m Keys: K m Timestamp: T m Nonce: N m Lifetime: L r Subscripts m Symmetric key: With two subscripts (KAB) m Public Key: With one subscript (KA) m Private Key: Inverse of the public key (K A-1) r Text m Clear text: X with no { } m Encrypted text: within the { } m Concatenation: || Oct. 5, 2005 CSc 296 Q Network Security Page 37

Security Protocol Notation. Examples r A-> B: {X}KAB m A sends a message to B consisting of a plain text X encrypted under shared key KAB r B->A: {NB}K m B sends a message to A consisting of B’s Nonce encrypted using A’s public key A Oct. 5, 2005 CSc 296 Q Network Security Page 38

Keys in Kerberos r KAS, TGS is a long-term secret key shared by AS and r r TGS. KAS, C is a long-term secret key shared by AS and C. KTGS, S is a long-term secret key shared by TGS and S. KC, TGS is a secret short-term key shared by C and TGS. KC, S is a secret session key shared by C and S. Oct. 5, 2005 CSc 296 Q Network Security Page 39

Kerberos Messages (not complete) 1. C AS : TGS || from || to || NC 2. AS C : {KC, TGS||L 1||C||from||to}KAS, TGS|| {KC, TGS||NC||from||to||TGS}KAS, C (Ticket Granting Ticket for the TGS) 3. C TGS: S||from||to||N’C || {KC, TGS||L 1||C||from||to}KAS, TGS || {C||T 1}KC, TGS 4. TGS C: {KC, S||L 2||C||from||to}KTGS, S || {KC, S|| N’C||from||to||S}KC, TGS (Ticket for the server S) 5. C S: {KC, S||L 2||C||from||to}KTGS, S || {C||T 2}KC, S 6. S C : {T 2}KC, S Oct. 5, 2005 CSc 296 Q Network Security Session keys given by the servers Page 40

Client-AS (1 & 2) r Client and AS use long-term key KAS, C to mutually authenticate each other, derive a short-term key KC, TGS and a ticket granting ticket. r These allow Client to talk to TGS in next step. r This ticket includes short-term key KC, TGS and ticket lifetime encrypted under long-term key KAS, TGS. r Default lifetime is 10 hours, determines length of session before re-authentication required. Oct. 5, 2005 CSc 296 Q Network Security Page 41

Client-TGS (3 & 4) r Client and TGS use short-term key KC, TGS to mutually authenticate each other, derive a session key KC, S and a ticket (session granting ticket, service ticket, real ticket…). r These allow client to talk to Server in next step. r Step 3: m Client contacts TGS with a request to access server S along with TGT obtained in step 2 and a timestamp authenticating himself to TGS. r Between step 3 and 4 m TGS checks validity and lifetime of TGT and extracts its copy of the short-term key KC, TGS can now check timestamp to authenticate client. r Step 4: m If OK, TGS issues a session key KC, S and ticket to Client. Default lifetime is 5 minutes. Client nonce N’C also sent to Client, encrypted under KC, TGS, allowing Client to authenticate TGS. Oct. 5, 2005 CSc 296 Q Network Security Page 42

Client-Server (5 & 6) r Client C and Server S use session key KC, S and ticket to mutually authenticate each other. r Success grants Client access to server, session key can be used to secure remainder of Client-Server session. r Step 5: m Client presents ticket along with message authenticating himself to S. r Between step 5 and 6 m S checks validity and lifetime of ticket and extracts its copy of session key KC, S. S can now authenticate Client by checking timestamp. r Step 6 m If OK, S grants access to Client. Optionally, S sends Client a timestamp allowing authentication of S to Client. Oct. 5, 2005 CSc 296 Q Network Security Page 43

Kerberos Messages (repeated) 1. C AS : TGS || from || to || NC 2. AS C : {KC, TGS||L 1||C||from||to}KAS, TGS|| {KC, TGS||NC||from||to||TGS}KAS, C (Ticket Granting Ticket for the TGS) 3. C TGS: S||from||to||N’C || {KC, TGS||L 1||C||from||to}KAS, TGS || {C||T 1}KC, TGS 4. TGS C: {KC, S||L 2||C||from||to}KTGS, S || {KC, S|| N’C||from||to||S}KC, TGS (Ticket for the server S) 5. C S: {KC, S||L 2||C||from||to}KTGS, S || {C||T 2}KC, S 6. S C : {T 2}KC, S Oct. 5, 2005 CSc 296 Q Network Security Session keys given by the servers Page 44

Authentication in Kerberos r How do they know they are talking to the right entity? 1. C to AS: implicit – C can only decrypt {KC, TGS||NC||from||to||TGS}KAS, C if he has KAS, C. AS to C: encrypted nonce sent by C: {…||NC||…}KAS, C 2. 3. 4. 5. 6. C to TGS: C’s identity: {C||T 1}KC, TGS to C: encrypted nonce sent by C: {…||N’C||…}KC, TGS C to S: C’s identity: {C||T 2}KC, S S to C: timestamp: {T 2}KC, S Oct. 5, 2005 CSc 296 Q Network Security Page 45

Kerberos 4 Overview Fig 4. 1 Summary Oct. 5, 2005 CSc 296 Q Network Security Page 46

Kerberos Realms r Single user/team managing one KDC is not desirable or practical m Solved by logically subdividing the large organization network into distinct realms r A Realm m a Kerberos environment consists of: • a Kerberos server • a number of clients, all registered with server • application servers, sharing keys with server m typically Oct. 5, 2005 a single administrative domain CSc 296 Q Network Security Page 47

Authentication Across Realms r Authentication across realms is complicated r Each organization wishing to run a Kerberos server establishes its own "realm". r By establishing "inter-realm" keys, the administrators of two realms can allow a client authenticated in the local realm to use its authentication remotely Oct. 5, 2005 CSc 296 Q Network Security Page 48

Kerberos Benefits r Benefits m No password transmitted on the network m (The initial password? By secure channel) m Protection against spoofing • Only the user can decrypt the ticket with her secret key m Each ticket has finite lifetime m Timestamps to prevent replay attack m Mutual authentication r Kerberos has been extensively studied in the cryptography community, and held up well Oct. 5, 2005 CSc 296 Q Network Security Page 49

Kerberos Weaknesses r KDC’s security is super critical m Must guard at all cost! r Availability and reliability r Only user-to-host authentication, not host-to-host r Trusted relationship between TGS and every server r Password Attack m Client-AS long-term key usually based on password entered by user: vulnerable to dictionary attacks r Time stamping m All parties must have secure and (loosely) synchronized clocks Oct. 5, 2005 CSc 296 Q Network Security Page 50

Kerberos Weaknesses r Ticket and session key cache m In multi-ser environment, cached session key can be used to impersonate a user r Requires timely transaction: during the lifetime of a ticket, replay attack possible. m If too short repeatedly asks for password m If too long greater opportunity for replay attack r Poor scalability problem m Solved by hierarchical authentication structure • E. g. , Department KDC – University KDC - regional KDC • Only the regional KDCs form complete mesh Oct. 5, 2005 CSc 296 Q Network Security Page 51

Implementation r TCP/UDP Port 88, 750 r Implementation from MIT freely available r Kerberos is integrated into many versions of Unix r Apple's MAC OS X r Windows 2000, XP, Server 2003 uses variants of Kerberos as their default authentication method m Proprietary Oct. 5, 2005 and not compatible CSc 296 Q Network Security Page 52

Quiz r Are the long-term shared passwords transmitted r r through the network? TGT is encrypted with client’s shared key Interpretation? m B->A: {NB}K The clients authenticate the servers, but not vice versa. What ticket is this? (ticket granting ticket or the final ticket) {KC, S||L 2||C||from||to}KTGS, S AB r r Oct. 5, 2005 CSc 296 Q Network Security Page 53

Next Topics r Network Attacks and Defense m Hacking procedure, tools, methods m Related to Chapter 5 and 6 r Firewall m Chapter 9, 10, 11 r IDS m Chapter 15 Oct. 5, 2005 CSc 296 Q Network Security Page 54