1

Chapter 8

Copyright 2003 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

3

Figure 8-1: Cryptographic System

Phase 4:Ongoing Communication with

Message-by-MessageConfidentiality, Authentication,

and Message Integrity

Phase 3:Key Exchange orKey Agreement

Client PCServer

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

Figure 8-4: SSL/TLS Operation

Protects All Application TrafficThat is SSL/TLS-Aware

SSL/TLS Works at Transport Layer

Applicant(Customer Client)

Verifier(Merchant Server)

7

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

8

Figure 8-4: SSL/TLS Operation

Applicant(Customer Client)

Verifier(Merchant Server)

3. Client Generates Random Session KeyClient Sends to Server Encrypted

by Public Key Encryption

4. Ongoing Communication with Confidentialityand Merchant Digital Signatures

9

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

2. OK?

1. LoginUsername

And Password

Dial-UpConnection

Dial-UpConnection

10

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

11

Figure 8-6: PPP Authentication

No AuthenticationIs an Option

ClientServer

12

Figure 8-6: PPP Authentication

PAP Authentication

Authentication-Request Messages(Send Until Response)

Authentication-Response MessageClientServer

Poor Security: Usernames and PasswordsAre Sent in the Clear

13

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

14

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

15

Figure 8-6: PPP Authentication

EAP Authentication

Authenticate

Defer authentication;Will provide more information ClientServer

EAP defers authentication to a later processSuch as RADIUS authentication

16

Figure 8-7: PPP Encryption

New PPP Header.Plaintext.

Original PPP Frame.Encrypted.

New PPP Trailer.Plaintext.

17

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)

18

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

19

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

20

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

RADIUSServer

PPTPRAS

ISPPPTP

AccessConcentrator

CorporateSite A

IP Protocol 47 (GRE) Data Connection

TCP Port 1723SupervisoryConnection(Vulnerable)

InternetRemote

CorporatePC

LocalISP Access

(Not Secure)

21

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

New: Not in Book

Direct connection between PCAnd RADIUS Server

22

Figure 8-10: PPTP Encapsulation for Data Frames

Enhanced GeneralRouting

Encapsulation(GRE) Header;

Information AboutEncapsulated

Packet

New IP Header;Protocol=47;

IP DestinationAddress Is That ofRemote Access

Server

EncapsulatedOriginal

IP Packet

23

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.

24

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

25

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

26

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 AddressIs IPsec Server Address

Host IP AddressIs not Revealed

27

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

28

Modes and Protections

ESPConfidentialityAuthenticationIntegrity

AHAuthenticationIntegrity

Transport Mode(End-to-End)

Possible Possible

Tunnel Mode(IPsec Gateway to Gateway)

Possible Possible

29

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

30

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.

31

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

32

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

33

Figure 8-17: Kerberos Authentication System

Applicant (A)

Kerberos ServerKey Distribution Center

(K)

Verifier (V)

Abbreviations:A = ApplicantV = VerifierK = Kerberos Server

34

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.

35

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

Applicant (A)

Kerberos ServerKey Distribution Center

(K)

Verifier (V)

1. Request Ticket 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.

36

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

37

Figure 8-20: Placement of Firewalls and Cryptographic Servers

Internet

InternalHost

CanRead

DecryptedPackets

Firewall

CryptographicServer

Filteredby

Firewall

Open toAttack

InternalHost

CryptographicServer

Firewall

CreatesHoles for

CryptographicSystems

Filtered byFirewall

NotFiltered

byFirewall