Transcript Cryptographic System

Cryptographic Systems:
SSL/TLS, VPNs, and Kerberos
Chapter 8
Panko, Corporate Computer and Network Security
Copyright 2004 Prentice-Hall
1
Figure 8-1: Cryptographic System
Three Initial “Hand-Shaking” Phases
Phase 1:
Initial Negotiation
of Security Parameters
Client PC
Phase 2:
Mutual Authentication
Server
Phase 3:
Key Exchange or
Key Agreement
2
Figure 8-1: Cryptographic System
Phase 4:
Ongoing Communication with
Message-by-Message
Confidentiality, Authentication,
and Message Integrity
Client PC
Server
The Initial Hand-Shaking Stages are Very Brief
Almost All Messages are Sent During the Ongoing Exchange Phase
3
Figure 8-2: Major Cryptographic
Systems
Layer
Cryptographic System
Application
Kerberos
Transport
SSL/TLS
Internet
IPsec
Data Link
PPTP, L2TP (really only a tunneling system)
Physical
Not applicable. No messages are sent at this
layer—only individual bits
4
Figure 8-3: Virtual Private Network (VPN)
Site-to-Site
VPN
Protected VPN
Server Server
Internet
Corporate
Site A
Remote
Customer or
Supplier PC
VPN Protected
Server Server
Corporate
Site B
Remote
Access
VPN
Remote
Access
VPN
Remote
Corporate PC
5
Virtual Private Network (VPN)
Server
New
Not in Book
Internet
Host-to-Host VPN
Hosts can communicate
Directly with each other
Client-Server
Client-Client
6
Secure Sockets Layer / Transport Layer
Security (SSL/TLS)
Applicant
(Customer Client)
Verifier
(Merchant Server)
Protects All Application Traffic
That is SSL/TLS-Aware
SSL/TLS Works at Transport Layer
7
Figure 8-4: SSL/TLS Operation
Applicant
(Customer Client)
Verifier
(Merchant Server)
1. Negotiation of Security Options (Brief)
2. Merchant Authenticates Self to Customer
Uses 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 Key
Client Sends Key to Server Encrypted
with Public Key Encryption
4. Ongoing Communication with Confidentiality
and Merchant Digital Signatures
9
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
10
Figure 8-5: Point-to-Point Protocol (PPP) and
RADIUS for Dial-Up Remote Access
Public Switched
Telephone
Network
2. OK?
RADIUS
Server
RAS 1
1. Login
Username
And Password
Remote
Corporate PC
Dial-Up
Connection
Remote
Corporate PC
2. OK?
Corporate
Site A
RAS 2
RAS = Remote Access Server
Dial-Up
Connection
11
Figure 8-5: Point-to-Point Protocol (PPP) and
RADIUS for Dial-Up Remote Access
Remote
Corporate PC
3. OK
RADIUS
Server
4. Welcome
RAS 1
3. No
Corporate
Site A
RAS 2
Public Switched
Telephone
Network
4. Refuse
Dial-Up
Connection
Remote
Corporate PC
Dial-Up
Connection
12
Figure 8-6: PPP Authentication
No Authentication
Is an Option
Server
Client
13
Figure 8-6: PPP Authentication
Password Authentication Protocol (PAP)
Authentication-Request Messages
(Send Until Response)
Authentication-Response Message
Server
Client
Poor Security: Usernames and Passwords
Are Sent in the Clear
Authenticate Once
14
Figure 8-6: PPP Authentication
CHAP Authentication
Challenge Message
Server
Response Message
Hash (Challenge Message + Secret)
Client
Server computes hash of challenge message plus secret
If equals the response message, authentication is successful
(Authentication done periodically)
15
Figure 8-6: PPP Authentication
MS-CHAP Authentication
Challenge Message
Server
Response Message
Hash (Challenge Message + Password)
Client
CHAP, but with password as the secret.
Widely used because allows password authentication
Standard on Microsoft Windows client
Only as secure as password strength
16
Figure 8-6: PPP Authentication
Extensible Authentication Protocol (EAP)
Authenticate
Server
Defer authentication;
Will provide more information
Client
EAP defers authentication to a later process
Such as RADIUS authentication
17
Figure 8-7: PPP Encryption
New PPP Trailer.
Plaintext.
Original PPP Frame.
Encrypted.
New PPP Header.
Plaintext.
18
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
19
Figure 8-8: PPP on Direct Links and
Internets
PPP Frame
Connection over Direct Link
PPP Provides End-to-End Link
Applicant
(Client)
Verifier
(Server)
20
Figure 8-8: PPP on Direct Links and
Internets
PPP Frame in
IP Packet
Applicant
(Client)
PPP
Limited
to First
Data Link
(Network)
Verifier
(Server)
Connection over Internet
Router
Router
The PPP frame is encapsulated in an IP packet.
This is the opposite of the normal practice
The packet is carried in a separate
Frame in each network along the route
21
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
22
Figure 8-9: Point-to-Point Tunneling
Protocol (PPTP)
IP Protocol 47 (GRE) Data Connection
Local
ISP Access
(Not Secure)
RADIUS
Server
PPTP
RAS
Corporate
Site A
Internet
TCP Port 1723
Supervisory
Connection
(Vulnerable)
GRE = Generic Routing Encapsulation
ISP
PPTP
Access
Concentrator
Remote
Corporate
PC
23
Figure 8-9: Point-to-Point Tunneling
Protocol (PPP)
Direct connection between PC and RAS
IP Protocol 47 (GRE) Data Connection
RADIUS
Server
PPTP
RAS
Corporate
Site A
Internet
TCP Port 1723
Supervisory
Connection
(Vulnerable)
Remote
Corporate
PC
24
Figure 8-10: PPTP Encapsulation for
Data Frames
Encapsulated
Original Frame
Enhanced Generic
Routing
Encapsulation
(GRE) Header;
Information About
Encapsulated
Packet
New IP Header;
Protocol=47;
IP Destination
Address Is That of
Remote Access
Server
25
Figure 8-11: Layer 2 Tunneling Protocol
(L2TP)
Internal
Server
DSL Access
Multiplexer
(DSLAM)
with L2TP
L2TP
RAS
L2TP Tunnel
Local
Network
Client
Running
PPP
DSL
Carrier Network
Note: L2TP does not provide security. It provides only tunneling.
L2TP recommends the use of IPsec for security.
26
Figure 8-12: IPsec Operation: Tunnel
and Transport Modes
Transport Mode
Site
Network
Extra
Software
Required
Security
in Site
Network
Secure Connection
Secure on
the Internet
Site
Network
Security
in Site
Network
Extra
Software
Required
27
Figure 8-12: IPsec Operation: Tunnel
and Transport Modes
Tunnel Mode
Site
Network
No
Extra
Software
IPsec
Server
No
Security
in Site
Network
Tunneled
Connection
Secure on
the Internet
IPsec
Server
Site
Network
No
Security
in Site
Network
No
Extra
Software
28
Figure 8-12: IPsec Operation: Tunnel
and Transport Modes
Transport Mode
Destination IP Address
Is Actual Address;
Vulnerable to Scanning
Orig. IP
Hdr
IPsec
Hdr
Protected Packet
Data Field
IPsec
Hdr
Protected
Original Packet
Tunnel Mode
Destination IP Address is
IPsec Gateway Address
Host IP Address
Is not Revealed
New IP
Hdr
29
Figure 8-13: IPsec ESP and AH
Protection
Confidentiality
Encapsulating
Security
Payload
IP
Header
Protocol = 50
ESP
Header
Protected
ESP
Trailer
Authentication and Message Integrity
Protocol = 51
Authentication
Header
IP
Header
Authentication
Header
Protected
Authentication and Message Integrity
No Confidentiality
30
Modes and Protections
ESP
Confidentiality
Authentication
Integrity
AH
Authentication
Integrity
Possible
Possible
Tunnel Mode
Possible
(IPsec Gateway to
Gateway)
Possible
Transport Mode
(End-to-End)
31
Figure 8-14: IPsec Security
Associations
2. Security Association (SA)
for Transmissions from A to B
Party A
3. Security Association (SA)
For Transmission from B to A
(Can Be Different Than
A to B SA)
Party B
1. List of
Allowable
Security
Associations
1. List of
Allowable
Security
Associations
IPsec Policy Server
32
Figure 8-15: Establishing IPsec
Security Associations Using IKE
Internet Key Exchange
Security Association
UDP Port 500
Party A
Party B
IPsec SAs
First establish IKE association and
protected session
Then create IPsec SAs within the
Protection of the IKE session.
33
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
34
Figure 8-16: Key-Hashed Message
Authentication Codes (HMACs)
Shared Key
Original Plaintext
Hashing with MD5, SHA1, etc.
HMAC
Key-Hashed Message Authentication Code (HMAC)
Appended to Plaintext Before Transmission
HMAC
Original Plaintext
Note: There is no
encryption; only
hashing
35
Figure 8-16: Key-Hashed Message
Authentication Codes (HMACs)
Receiver Redoes the HMAC Computation
On the Received Plaintext
Shared Key
Received Original Plaintext
Hashing with same algorithm.
Computed HMAC
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.
36
Figure 8-17: Kerberos Authentication
System
Kerberos Server
Key Distribution Center
(K)
Abbreviations:
A = Applicant
V = Verifier
K = Kerberos Server
Applicant (A)
Verifier (V)
37
Figure 8-17: Kerberos Authentication
System
Kerberos Server
Key Distribution Center
(K)
1. Request for
Ticket-Granting
Ticket
2. Response:
TGT*
Key nA**
Applicant (A)
*TGT (Ticket-Granting
Ticket) is encrypted in a
way that only K can
decrypt. Contains
information that K
will read later.
**Key nA (Network
Login Key for A) is
encrypted with A’s
Master Key (Key mA).
In future interactions
with K, A will use nA
Verifier (V)
to limit the master
key’s exposure.
38
Figure 8-18: Kerberos Ticket-Granting
Service: Part 1
Kerberos Server
Key Distribution Center
(K)
1. Request Service
Ticket for V; TGT;
Authenticator*
encrypted with
Key nA
2. Response:
Key AV** encrypted
with Key nA;
Service Ticket
Applicant (A)
*Authenticator is A’s
IP address, user name,
and time stamp. This
authenticator is encrypted
with Key nA to prove that
A sent it.
**Key AV is a
symmetric session
key that A will use
with V.
Verifier (V)
39
Figure 8-19: Kerberos Ticket-Granting
Service: Part 2
*Authenticator (Auth)
encrypted with Key AV.
Kerberos Server
Key Distribution Center
(K)
**Service Ticket contains
Key AV encrypted with the
Verifier’s master key, Key mV.
3. Request for Connection:
Auth*; Service Ticket**
5. Ongoing Communication with Key AV
Applicant (A)
Verifier (V)
4. V decrypts Service Ticket;
Uses Key AV to test Auth
40
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
41
Figure 8-20: Placement of Firewalls
and Cryptographic Servers
Not
Filtered
by
Firewall
Internet
Some firewalls
pass through encrypted
packets in VPNs.
Cryptographic server
Comes after the firewall.
No filtering can be done
by the firewall.
Firewall
Cryptographic
Server
Filtered by
Firewall
Firewall Creates
Holes for
Cryptographic
Systems
Internal
Host
42
Figure 8-20: Placement of Firewalls
and Cryptographic Servers
Filtered
by
Firewall
Internet
Cryptographic
Firewall Server
Internal
Host
Can
Read
Decrypted
Packets
Open to
Attack
Alternatively,
the cryptographic server
can be placed
before the firewall.
The firewall can filter
the decrypted packets
This leaves the
cryptographic server
open to attack
If the firewall is taken
over, the hacker
can read everything
43
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
44
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
45