CS 5950/6030 Network Security Class 32 (M, 11/14/05) Leszek Lilien Department of Computer Science...

CS 5950/6030 Network SecurityClass 32 (M, 11/14/05)

Leszek LilienDepartment of Computer Science

Western Michigan University

Based on Security in Computing. Third Edition by Pfleeger and Pfleeger.Using some slides (as indicated) courtesy of:Prof. Aaron Striegel — at U. of Notre Dame

Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. WashingtonProf. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The

Netherlands

Slides not created by the above authors are © by Leszek T. Lilien, 2005Requests to use original slides for non-profit purposes will be gladly granted upon a written

request.

2

7. Security in Networks...

7.2. Threats in Networks...

7.3. Networks Security Controls...

c) Encryptioni. Link encryption vs. end-to-end (e2e) encryptionii. Virtual private network (VPN)iii. PKI and certificates—PART 1

iii. PKI and certificates—PART 2iv. SSH protocolv. SSL protocol (a.k.a. TLS protocol)vi. IPsec protocol suite—PART 1

Class 31

© by Leszek T. Lilien, 2005

3

PKI and certificates (3) PKI sets up:

1) Certificate authorities (CAs)2) Registration authority

1) Certificate authority (CA) CA can be in-house or external (commercial TTP

= trusted third party) CA is trusted

Entities delegate to CA creation, issuance, acceptance, and revocation of their certificates

CA actions: Managing public key certificates (whole life cycle) Issuing certificates by binding entity’s identity

to its public key Binding is done via CA’s digital signature

Determining expiration dates for certificates Revoking certificates when necessary

By publishing revocation lists© by Leszek T. Lilien, 2005

4

iv. SSH protocol (SSH = Secure SHell)

SSH protocol v.1 and v.2 – provides authenticated and encrypted communication with shell/OS command interpreter

Originally defined for Unix Replaced insecure utilities for remote access

Such as Telnet / rlogin / rsh

Protects against spoofing attacks (falsifying one end of communication, incl. masquerading, sesssion hijacking, MITM) & message modification / falsification

Involves negotiation between local and remote sites

Negotiate which encryption algorithm to use E.g., DES? IDEA? AES?

Negotiate which authentication technique to use E.g., public key? Kerberos?© by Leszek T. Lilien, 2005

5

v. SSL protocol (a.k.a. TLS prot.) (1) SSL protocol (v3) = TLS protocol - interfaces betwen app

(on client C) and TCP/IP protocols to provide server S authentication, optional C authentication, and encrypted communication channel between C and S for a session between C and S

SSL = Secure Sockets Layer / TLS = Transport Layer Security Originally defined by Netscape to protect browser-to-

server communication Simple but effective – most widely used secure

commu-nication protocol on Internet (incl. WWW browsers/servers)

Involves negotiation between C and S Negotiate which encryption suite to use for session

E.g., DES? RC4 w/ 128-bit/40-bit key? RC2? Fortezza? [Bishop] Negotiate which hashing technique to use for session

E.g., SHA1 or MD5?


6

vi. IPsec protocol suite (1) IPsec (IP Security Protocol Suite) = standard for

securing IP communications by encrypting and/or authenticating all IP packets

IPsec is public (published / scrutinized)

By design, protects against threats including: spoofing (incl. session hijacking) / eavesdropping

Choice of ciphers/hash protocols Communicating parties negotiate which ones

to use IPsec defines some ciphers/hash as required in

every IPsec implementaion


7

IPsec protocol suite (4)

Security parameter index (SPI) data structure Resides on each host H running IPsec Used to select 1 of n SAs that exist on H

Different SAs for concurrent communications with different remote Hs

Fundamental IPsec data structures / protocols1) AH = authentication header / AH protocol

For authentication-only IPsec service: Authenticates S (sender )

2) ESP = encapsulated security payload / ESP protocol

For encryption-only IPsec serviceOR For combined encryption/authentication

IPsec service© by Leszek T. Lilien, 2005

8

IPsec protocol suite (5)

IPsec can be used for various crypto sessions: VPN e2e (incl. app 2 app) For network mgmt (e.g., for routing)

IPsec scenario TCP layer passes conventional TCP Header & Data

down to IP layer IP layer calls upon IPsec to encapsulate conventional

TCP Header & Data into ESP (encapsulated security payload)

Fig. 7-28, p. 441 IP layer adds IP Header IP layer passes packet down to physical layer Physical layer adds Physical Header & Physical

Trailer© by Leszek T. Lilien, 2005

9

End of Class 31


10

7. Security in Networks...

7.2. Threats in Networks...

7.3. Networks Security Controls...

c) Encryptioni. Link encryption vs. end-to-end (e2e) encryptionii. Virtual private network (VPN)iii. PKI and certificates—PART 1

iii. PKI and certificates—PART 2iv. SSH protocolv. SSL protocol (a.k.a. TLS protocol)vi. IPsec protocol suite—PART 1

vi. IPsec protocol suite—PART 2iii. Signed codeiv. Encrypted e-mail

d) Message content integrity controlsi. Error correcting codesii. Cryptographic checksum

e) Strong authenticationi. One-time passwordsii. Challenge-response systemsiii. Digital distributed authenticationiv. Kerberos

Class 31


Class 32

11

[---SKIP---] IPsec protocol suite (6)

ESP structure – includes more than just TCP Header & Data Fig. 7-29, p. 441

„authenticated” — portion authenticated by IPsec with Authentication Data (Auth. Data = kind of signature)

„encrypted” — portion encrypted by IPsec Fields within ESP:

1) SPI (unencrypted) – index for security association to be used for this pkt

2) Sequence Number (unencrypted) – sequential number, prevents pkt replay attacks

3) Payload Data – (part of) data passed fr. TCP Layer4) Padding / Padding Length – padding necessary

to inflate pkt to required fixed size (e.g., size required by block cipher used for encryption)

5) Next Header – type of data in Payload Data field6) OPTIONAL: Authentication Data (unencrypted) –

authenticates all above fields


12

IPsec protocol suite (7) ISAKMP (Internet Security Association Key

Management Protocol) = key mgmt protocol for IPsec Key mgmt is always a critical element in crypto apps

ISAKMP is simple, flexible, scalable Distinct key for each IPsec security association (SA)

In IPsec, ISAKMP implemented via IKE (ISAKMP Key Exchange)

IKE properties Provides ways to agree on protocols, cipher and

authentication algorithms, keys E.g., agree as follows: protocol = EPS, cipher = triple

DES; authentication alg. = SHA-1; key used for session Provides ways to manage protocols, cipher and

authentication algorithms, keys Uses key exchange protocol based on Diffie-

Hellman scheme


13

[---SKIP---] IPsec protocol suite (8)

IKE key exchange scenario (using Diffie-Hellman scheme) X and Y know number g X and Y choose large primes x and y, respectively X send gx to Y / Y send gy to X X calculates (gy)x / Y calculates (gx)y

Since (gy)x = (gx)y => X and Y share secret Actual calculation is mod(n) — a bit more complex

X and Y exchange identities & certificates Certificates authenticate identities

X and Y derive shared crypto key X and Y enter security association

=> they establish session

IKE key exchange is very efficient Can be done in 2 messages if w/o authentication Can be done in 4 messages if w/ authentication


14

vii. Signed code Problem: malicious active code

E.g., malicious code on a web site for downloads Partial solution: code signed by TTP (trusted third party)

TTP appends digital signature to piece of code PKI can be used by prospective code users to

validate signature

Still code security not guaranteed E.g., March 2001 mistake of Verisign (CA)

Erronously issued two code-signing certificates to impostors masquerading as Microsoft employees

Verisign detected mistake after almost 2 months Customers who didn’t validate certificate (by

checking Verisign’s certificate revocation list) could still trust bad certificates


15

[---SKIP---] viii. Encrypted e-mail E-mail msgs – like a postard that everybody who

handles it between S and R can readPeople use envelopes for confidentiality (C in C-I-A)

We can „envelope” e-mail msgs by encrypting them

Encryption protects C and can protect I

Encryption is easy, establishing good key mgmt is difficult

2 basic key mgmt approaches:1) Hierarchical certificate-based PKI solution

E.g., S/MIME

2) Use of flat, individual-to-individual key exchange E.g., PGP

E-mail security (incl. PGP and S/MIME) will be discussed soon


16

[---SKIP---] e) Msg content integrity controls (1)

Content integrity verification provided „for free” with encryption

Since can’t perform meaningful data modification w/o decrypting it

But attacker can modify encrypted data to make it useless E.g., changing a bit of data in packet

Threats to msg content integrity1) Malicious modification that changes content

in a meaningful way2) Nonmalicious modification that changes content

in a way that is not necessarily meaningful 3) Malicious modification that changes content

in a way that is not meaningful

NOTE: Different cases than in text! Encryption can solve the toughest case: Case (1)

above


EASIERTO PREVENTOR DETECT

17

[---SKIP---] Msg content integrity controls (2)

Msg content integrity controls #1: DETECTError detection and error correction codes

As discussed before („Intro to Cryptology” section) Simplest error detection code: even/odd parity check More complex error detection codes:

Hash codes or Huffman codes Some detect multiple bit errors

Some also pinpoint which bits are incorrect For detecting/correcting nonmalicious changes

Does not matter whether accidentally „meaningful” or not Can also stop some malicious attacks

Again does not matter whether msg changes „meaningful” or not

E.g., attackers not knowing which code used => can’t fool it E.g., attacker manipulating 2 bits & thinking that we have

2–bit correction code fails if we have 3-bit correction code More complex error detection codes can stop tougher

attackers


18

[---SKIP---] Msg content integrity controls (3)

[OPTIONAL] Msg content integrity controls #2: PREVENT or DETECTCryptographic checksum / msg digest / hash

To prevent or malicious attacks on data — As discussed before („Intro to Cryptology” section)

Can also detect malicious errorsCan also detect nonmalicious errors

Note that attacker can modify: Modify only data bits Modify error prevention/detection mechanism


19

f) Strong authentication Networked environments as well as both ends of

communication need authentication

Strong authentication controls include:i. One-time passwordsii. Challenge-response systemsiii. Digital distributed authenticationiv. Kerberos authentication system


20

[---SKIP---] i. One-time passwords (1)

One-time password (OTP) method Controls wiretapping and spoofing

Prevents reuse of pwd captured by wiretapper Strong authentication prevents spoofing (incl.

masquerading, session hijacking, MITM) Each password used only once

„Thrown away” after use

OTP uses secretly maintained pwd listOR User has password token (PT)

= device to randomly generate new pwd (e.g.) every minuteE.g., SecureID device from Security Dynamics – random # every minute © by Leszek T. Lilien, 2005

21

[---SKIP---] One-time passwords (2)

Pwd generation for user U is based on time synchronization with PT of this particular user U

Pwd changed in sync by both U’s PT and system authenticating U

PTs of different users produce different pwd sequences

Problems with OTP1) Attacker can steal/find PT (device)

2) One-minute window of vulnerability Wiretapper can reuse password for one minute

If PT generates new pwd once per minute


22

[---SKIP---] ii. Challenge-response systems

Challenge-response systems solve OTP problems1) Solve problem of stolen/lost password tokens (PTs)

Solution: PT requires a PIN Even if stolen by attacker, PIN protects „responses”

2) Solve problem of window of vulnerability Solution: New challenge for each use

Does not matter whether new use within one minute window or not

Challenge-response systems can be viewed as more sophisticated version of OTP

Problem: Neither OTP or C-RS protect user from rogue system


23

[---SKIP---] iii. Digital distributed authentication (1)

„Digital” from „Digital Equipment Corporation” (DEC) Once a powerful computer company

Acquired (1998) by Compaq, which subsequently merged with Hewlett-Packard (2002)

As of 2004 their product lines were still produced under HP name

In 1980s DEC recognized need for authentication of nonhuman entities in distributed environment

E.g., mutual authentication of user query processor and DB manager (process)

Goals of Digital distributed authentication: Prevent server impersonation (e.g., DB mgr

impersonation) Prevent interception/modific. of msgs between

entities Prevent replay of previous authentication


[Wikipedia]

24

[---SKIP---] Digital distributed authentication (2)

Architecture of Digital distributed authentication (1989):

Each server S has KPRIV-S

Corresponding KPUB-S available to any process that might need authenticated channel to S

A to B communication uses KPUB-B

B to A communication uses KPUB-A

A and B use sequence #s to msg replay

B can establish secret (symmetric) session key K for communication with A by:

Selecting key K Sending E(K, KPUB-A) to A From now on, A and B can exchange data

encrypted with K© by Leszek T. Lilien, 2005

25

iv. Kerberos authentication system (1)

Kerberos – system for authentication between intelligent processes in distributed systems (incl. C-S authentication)

[K. = guard dog in Hades (Greek mythology)] Developed at MIT (1988+)

Design goal: Enable systems to withstand attacks in distributed

systems

Basic idea of Kerberos: Central server provides tickets to requesting app

Ticket is authenticated, non-forgeable, non-replayable token=> Implemented as encrypted data structure naming user U and service for which U has access permission (also contains time value, control info)


26

Kerberos authentication system (2) User’s Step 1: Establishing session w/ Kerberos — Fig. 7-

30, p. 448 U’s workstat’n sends U’s identity to Kerberos server

(KS) KS verifies that U is authorized KS sends 2 msgs:

1) Msg to U, which contains: E(ST-GS + TT-GS , pwd) ST-GS — U’s session key for session with T-GS TT-GS — U’s ticket for T-GS

Enables U to request service from T-GS pwd — user’s pwd (Note: used as encryption key by KS)

2) Msg to T-GS, which contains: ST-GS and U’s identity (encrypted under key shared by KS and T-GS) ST-GS — T-GS’s session key for session with U (same

as U’s session key for session with T-GS)

If U’s workstation can decrypt E(ST-GS + TT-GS , pwd) using its pwd, then U’s authentication succeeds


U

U

U

U

U U

U U

27

Kerberos authentication system (3)

Note: KS stores users’ pwds => no need to pass pwds over network between U’s workstation and KS

Security advantage!

User’s Step 2: Access services of distributed system — e.g., access file F — Fig. 7-31, p. 448

Using U’s ticket for T-GS (received fr. KS in Step 1), U sends to T-GS:

E(„request R for U’s ticket for accessing F” , ST-GS)

Note: ST-GS (U’s session key for session with T-GS obtained fr. KS

in Step 1) is used to encrypt R T-GS verifies U’s access permission

...continued...© by Leszek T. Lilien, 2005

U

U

28

Kerberos authentication system (4)...continued...

If verified OK, T-GS returns to U message encrypted under ST-GS, which contains:

1) U’s session key for session with F (really: with F’s file server) = SF

2) U’s ticket for accessing F Ticket is encrypted under secret key („T-GS—F

key”) known only to T-GS and F’s file server Ticket contains:

U’s authenticated identity (T-GS knows that ST-

GS is U’s key —and nobody else’s— because KS sent to T-GS ST-GS and U’s identity tied together in Step 1)

Identification of file F Access rights (e.g., read permission) F’s session key for F’s session with U = SF

(same as U’s session key for session with F) Ticket expiration date


U

U

U

U

U

29


Strenghts of Kerberos system No pwds communicated over network (sent only

once by user to Kerberos server & sent outside the network, e.g., in letter)

Crypto protection against spoofing (each access request mediated by T-GS, which knows requester’s identity; this identity known based on authentication performed initiallly by Kerb. server)

Limited period of ticket validity (disables some long-term attacks—e.g., brute force cryptanalysis)

Prevents replay attacks (each user’s request stamped with time of request; unreasonably old requests rejected by request servers)

Mutual authentication (user can be assured of server’s authenticity by requesting server’s authenticating response)


30


Weaknesses of Kerberos system Requires continuous availability of trusted ticket-

granting server (T-GS) Server S’ authenticity requires trust between T-GS

& S Requires timely transactions (too quick ticket

expiration will result in rejecting legitimate requests) Subverted workstation can replay user pwds Pwd guessing works (attacker can send initial —Step 1—

authentication request to Kerberos server, receive response, try to decrypt response by guessing at pwd)

Kerberos does not scale well (due to system size might need > 1 KS and/or T-GS server; coordination and security problems if more than one KS and/or more than one T-GS is needed; cf. Fig. 7-32, p.450)

Use of Kerberos requires compatibility of all apps in a given computing environment (to date few apps are compatible with Kerberos; modifying apps to make them compatible is not feasible)


31

End of Class 32


CS 5950/6030 Network Security Class 32 (M, 11/14/05) Leszek Lilien Department of Computer Science...

Documents

Transcript of CS 5950/6030 Network Security Class 32 (M, 11/14/05) Leszek Lilien Department of Computer Science...