1

Chapter 8

Panko, Corporate Computer and Network SecurityCopyright 2004 Prentice-Hall

Cryptographic Systems:SSL/TLS, VPNs, and Kerberos

2

Figure 8-1: Cryptographic System

Phase 1:Initial Negotiation

of Security Parameters

Phase 2:Mutual Authentication

Client PCServer

Phase 3:Key Exchange orKey Agreement

Three Initial “Hand-Shaking” Phases

3

Figure 8-1: Cryptographic System

Phase 4:Ongoing Communication with

Message-by-MessageConfidentiality, Authentication,

and Message IntegrityClient PC

Server

The Initial Hand-Shaking Stages are Very BriefAlmost All Messages are Sent During the Ongoing Exchange Phase

4

Figure 8-2: Major Cryptographic Systems

Application

Layer

Transport

Internet

Data Link

Physical

PPTP, L2TP (really only a tunneling system)

Not applicable. No messages are sent at thislayer—only individual bits

IPsec

SSL/TLS

Kerberos

Cryptographic System

5

Figure 8-3: Virtual Private Network (VPN)

VPNServer

ProtectedServer

VPNServer

ProtectedServer

CorporateSite A

CorporateSite B

Internet

RemoteCustomer orSupplier PC

RemoteCorporate PC

RemoteAccess

VPN

RemoteAccess

VPN

Site-to-SiteVPN

6

Virtual Private Network (VPN)

Server

Host-to-Host VPN

Hosts can communicateDirectly with each other

Client-ServerClient-Client

Internet

NewNot in Book

7

Secure Sockets Layer / Transport Layer Security (SSL/TLS)

Protects All Application TrafficThat is SSL/TLS-Aware

SSL/TLS Works at Transport Layer

Applicant(Customer Client)

Verifier(Merchant Server)

8

Figure 8-4: SSL/TLS Operation

Applicant(Customer Client)

Verifier(Merchant Server)

1. Negotiation of Security Options (Brief)

2. Merchant Authenticates Self to CustomerUses a Digital Certificate

Customer Authentication is Optional and Uncommon

9

Figure 8-4: SSL/TLS Operation

Applicant(Customer Client)

Verifier(Merchant Server)

3. Client Generates Random Session KeyClient Sends Key to Server Encrypted

with Public Key Encryption

4. Ongoing Communication with Confidentialityand Merchant Digital Signatures

10

SSL/TLS

Growing rapidly in popularity for remote access Easy to implement

Webservers already implement it Clients already have browsers If only using HTTP, very easy Becoming popular

11

Figure 8-5: Point-to-Point Protocol (PPP) and RADIUS for Dial-Up Remote Access

RADIUSServer

RAS 1

RAS 2

RemoteCorporate PC

RemoteCorporate PC

Public SwitchedTelephoneNetwork

CorporateSite A

2. OK?

1. LoginUsername

And Password

Dial-UpConnection

Dial-UpConnection

2. OK?

RAS = Remote Access Server

12

Figure 8-5: Point-to-Point Protocol (PPP) and RADIUS for Dial-Up Remote Access

RADIUSServer

RAS 1

RAS 2

RemoteCorporate PC

RemoteCorporate PCPublic Switched

TelephoneNetwork

CorporateSite A

3. OK 4. WelcomeDial-Up

Connection

Dial-UpConnection

3. No

4. Refuse

13

Figure 8-6: PPP Authentication

No AuthenticationIs an Option

ClientServer

14

Figure 8-6: PPP Authentication

Password Authentication Protocol (PAP)

Authentication-Request Messages(Send Until Response)

Authentication-Response MessageClientServer

Poor Security: Usernames and PasswordsAre Sent in the ClearAuthenticate Once

15

Figure 8-6: PPP Authentication

CHAP Authentication

Challenge Message

Response MessageHash (Challenge Message + Secret) ClientServer

Server computes hash of challenge message plus secretIf equals the response message, authentication is successful

(Authentication done periodically)

16

Figure 8-6: PPP Authentication

MS-CHAP Authentication

Challenge Message

Response MessageHash (Challenge Message + Password) ClientServer

CHAP, but with password as the secret.Widely used because allows password authentication

Standard on Microsoft Windows clientOnly as secure as password strength

17

Figure 8-6: PPP Authentication

Extensible Authentication Protocol (EAP)

Authenticate

Defer authentication;Will provide more information ClientServer

EAP defers authentication to a later processSuch as RADIUS authentication

18

Figure 8-7: PPP Encryption

New PPP Header.Plaintext.

Original PPP Frame.Encrypted.

New PPP Trailer.Plaintext.

19

Figure 8-7: PPP Encryption

IETF Specifies DES and 3DES for PPP encryption

Microsoft uses Microsoft Point-to-Point Encryption (MPPE) for its remote access servers

Increasingly, AES is being incorporated into PPP products

20

Figure 8-8: PPP on Direct Links and Internets

Connection over Direct Link

PPP Provides End-to-End Link

PPP Frame

Verifier(Server)

Applicant(Client)

21

Figure 8-8: PPP on Direct Links and Internets

Connection over Internet

PPP Frame inIP Packet

PPPLimitedto First

Data Link(Network)

Verifier(Server)

Applicant(Client)

RouterRouter

The PPP frame is encapsulated in an IP packet.This is the opposite of the normal practice

The packet is carried in a separateFrame in each network along the route

22

Figure 8-8: PPP on Direct Links and Internets

Note:

Tunneling Places the PPP Frame in an IP Packet, Which Delivers the Frame.

To the Receiver, Appears to be a Direct Link.

Allows organization to continue using existing PPP-based security such as encryption and authentication

23

Figure 8-9: Point-to-Point Tunneling Protocol (PPTP)

RADIUSServer

PPTPRAS

ISPPPTP

AccessConcentrator

CorporateSite A

IP Protocol 47 (GRE) Data Connection

TCP Port 1723SupervisoryConnection(Vulnerable)

InternetRemote

CorporatePC

LocalISP Access

(Not Secure)

GRE = Generic Routing Encapsulation

24

Figure 8-9: Point-to-Point Tunneling Protocol (PPP)

RADIUSServer

PPTPRAS

CorporateSite A

IP Protocol 47 (GRE) Data Connection

TCP Port 1723SupervisoryConnection(Vulnerable)

InternetRemote

CorporatePC

Direct connection between PC and RAS

25

Figure 8-10: PPTP Encapsulation for Data Frames

Enhanced GenericRouting

Encapsulation(GRE) Header;

Information AboutEncapsulated

Packet

New IP Header;Protocol=47;

IP DestinationAddress Is That ofRemote Access

Server

EncapsulatedOriginal Frame

26

Figure 8-11: Layer 2 Tunneling Protocol (L2TP)

InternalServer

L2TPRAS

DSL AccessMultiplexer(DSLAM)with L2TP

ClientRunning

PPP

Carrier Network

LocalNetwork

L2TP Tunnel DSL

Note: L2TP does not provide security. It provides only tunneling.L2TP recommends the use of IPsec for security.

27

Figure 8-12: IPsec Operation: Tunnel and Transport Modes

Secure Connection

Secure onthe Internet

Transport Mode

SiteNetwork

SiteNetwork

Securityin Site

Network

Securityin Site

Network

ExtraSoftwareRequired

ExtraSoftwareRequired

28

Figure 8-12: IPsec Operation: Tunnel and Transport Modes

TunneledConnection

Secure onthe Internet

Tunnel Mode

SiteNetwork

SiteNetwork

NoSecurityin Site

Network

NoSecurityin Site

Network

NoExtra

Software

NoExtra

Software

IPsecServer

IPsecServer

29

Figure 8-12: IPsec Operation: Tunnel and Transport Modes

Transport Mode

Orig. IPHdr

IPsecHdr

Protected PacketData Field

Destination IP AddressIs Actual Address;

Vulnerable to Scanning

Tunnel Mode

New IPHdr

IPsecHdr

ProtectedOriginal Packet

Destination IP Address isIPsec Gateway Address

Host IP AddressIs not Revealed

30

Figure 8-13: IPsec ESP and AH Protection

IPHeader

ESPHeader

ProtectedESP

Trailer

IPHeader

AuthenticationHeader

Protected

Confidentiality

Authentication and Message Integrity

Authentication and Message IntegrityNo Confidentiality

Protocol = 50

Protocol = 51

EncapsulatingSecurityPayload

AuthenticationHeader

31

Modes and Protections

ESPConfidentialityAuthenticationIntegrity

AHAuthenticationIntegrity

Transport Mode(End-to-End)

Possible Possible

Tunnel Mode(IPsec Gateway to Gateway)

Possible Possible

32

Figure 8-14: IPsec Security Associations

IPsec Policy Server

2. Security Association (SA)for Transmissions from A to B

3. Security Association (SA)For Transmission from B to A

(Can Be Different ThanA to B SA)

Party A Party B

1. List ofAllowableSecurity

Associations

1. List ofAllowableSecurity

Associations

33

Figure 8-15: Establishing IPsec Security Associations Using IKE

Internet Key ExchangeSecurity Association

UDP Port 500

Party A Party B

IPsec SAsFirst establish IKE association andprotected session

Then create IPsec SAs within theProtection of the IKE session.

34

IPsec Defaults

When SA agreement cannot be reached, the two parties will use these defaults: Diffie-Hellman Key Agreement

DES-CBC

HMAC for Message-by-Message Authentication

35

Figure 8-16: Key-Hashed Message Authentication Codes (HMACs)

Shared Key

HMAC

HMAC

Original Plaintext

Original Plaintext

Key-Hashed Message Authentication Code (HMAC)

Appended to Plaintext Before Transmission

Hashing with MD5, SHA1, etc.

Note: There is noencryption; onlyhashing

36

Figure 8-16: Key-Hashed Message Authentication Codes (HMACs)

Shared Key

Computed HMAC

Received Original Plaintext

Hashing with same algorithm.

Receiver Redoes the HMAC ComputationOn the Received Plaintext

Received HMAC

If computed and received HMACs are the same,The sender must know the key and so is authenticated

Note that HMAC provides no nonrepudiation.

37

Figure 8-17: Kerberos Authentication System

Applicant (A)

Kerberos ServerKey Distribution Center

(K)

Verifier (V)

Abbreviations:A = ApplicantV = VerifierK = Kerberos Server

38

Figure 8-17: Kerberos Authentication System

Applicant (A)

Kerberos ServerKey Distribution Center

(K)

Verifier (V)

1. Request forTicket-Granting

Ticket

2. Response:TGT*

Key nA**

*TGT (Ticket-GrantingTicket) is encrypted in away that only K can decrypt. Containsinformation that Kwill read later.

**Key nA (NetworkLogin Key for A) isencrypted with A’sMaster Key (Key mA).In future interactionswith K, A will use nAto limit the masterkey’s exposure.

39

Figure 8-18: Kerberos Ticket-Granting Service: Part 1

Applicant (A)

Kerberos ServerKey Distribution Center

(K)

Verifier (V)

1. Request ServiceTicket for V; TGT;

Authenticator*encrypted with

Key nA

2. Response:Key AV** encrypted

with Key nA;Service Ticket

*Authenticator is A’sIP address, user name,and time stamp. Thisauthenticator is encryptedwith Key nA to prove thatA sent it.

**Key AV is a symmetric session key that A will usewith V.

40

Figure 8-19: Kerberos Ticket-Granting Service: Part 2

Applicant (A)

Kerberos ServerKey Distribution Center

(K)

Verifier (V)

*Authenticator (Auth) encrypted with Key AV.

**Service Ticket containsKey AV encrypted with theVerifier’s master key, Key mV.

3. Request for Connection:Auth*; Service Ticket**

4. V decrypts Service Ticket;Uses Key AV to test Auth

5. Ongoing Communication with Key AV

41

Figure 8-20: Placement of Firewalls and Cryptographic Servers

Dilemma

Firewalls must examine packet contents

But a growing percentage of packets are being encrypted to prevent eavesdroppers from reading them

Firewalls cannot filter encrypted packets without decrypting them

42

Figure 8-20: Placement of Firewalls and Cryptographic Servers

Internet

InternalHost

CryptographicServer

Firewall

Firewall CreatesHoles for

CryptographicSystems

Filtered byFirewall

NotFiltered

byFirewall

Some firewallspass through encrypted

packets in VPNs.

Cryptographic serverComes after the firewall.

No filtering can be doneby the firewall.

43

Figure 8-20: Placement of Firewalls and Cryptographic Servers

Internet

InternalHost

CanRead

DecryptedPackets

Firewall

CryptographicServer

Filteredby

Firewall

Open toAttack

Alternatively,the cryptographic server

can be placedbefore the firewall.

The firewall can filterthe decrypted packets

This leaves thecryptographic server

open to attack

If the firewall is takenover, the hacker

can read everything

44

The Market Situation

SSL/TLS is becoming very popular for remote access VPN service Works automatically for HTTP

Other applications are harder Some applications can be “webified”—each

output output can be incorporated as a webpage For other applications, a small program can be

downloaded to the client to add features Non-HTTP applications are very time consuming

to manage

45

The Market Situation

IPsec is Popular for Site-to-Site Networking In tunnel mode, no need to install software on

individual clients and servers

Transparent to applications