Transcript IPsec - Computer Science - Western Michigan University

CS 5950/6030 Network Security
Class 32 (M, 11/14/05)
Leszek Lilien
Department 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. Washington
Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The Netherlands
Slides not created by the above authors are © by Leszek T. Lilien, 2005
Requests to use original slides for non-profit purposes will be gladly granted upon a written request.
© by Leszek T. Lilien, 2005
7. Security in Networks
...
7.2. Threats in Networks
...
7.3. Networks Security Controls
...
c)
Encryption
i.
Link encryption vs. end-to-end (e2e) encryption
ii. Virtual private network (VPN)
iii. PKI and certificates—PART 1
Class
31
2
iii.
iv.
v.
vi.
PKI and certificates—PART 2
SSH protocol
SSL protocol (a.k.a. TLS protocol)
IPsec protocol suite—PART 1
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

By publishing revocation lists
Determining expiration dates for certificates
Revoking certificates when necessary
3 © by Leszek T. Lilien, 2005
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?
4 © by Leszek T. Lilien, 2005
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

Simple but effective – most widely used secure communication protocol on Internet (incl. WWW browsers/servers)


Originally defined by Netscape to protect browser-to-server
communication
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?
5 © by Leszek T. Lilien, 2005
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
6 © by Leszek T. Lilien, 2005
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 / protocols
1) AH = authentication header / AH protocol
 For authentication-only IPsec service:

Authenticates S (sender )
2) ESP = encapsulated security payload / ESP protocol
 For encryption-only IPsec service
OR
 For combined encryption/authentication
IPsec service
7 © by Leszek T. Lilien, 2005
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
8 © by Leszek T. Lilien, 2005
End of Class 31
9 © by Leszek T. Lilien, 2005
© by Leszek T. Lilien, 2005
7. Security in Networks
...
7.2. Threats in Networks
...
7.3. Networks Security Controls
...
c) Encryption
i.
Link encryption vs. end-to-end (e2e) encryption
ii. Virtual private network (VPN)
iii. PKI and certificates—PART 1
Class
31
iii.
iv.
v.
vi.
Class
32
vi. IPsec protocol suite—PART 2
iii. Signed code
iv. Encrypted e-mail
Message content integrity controls
i.
Error correcting codes
ii. Cryptographic checksum
Strong authentication
i.
One-time passwords
ii. Challenge-response systems
iii. Digital distributed authentication
iv. Kerberos
d)
e)
10
PKI and certificates—PART 2
SSH protocol
SSL protocol (a.k.a. TLS protocol)
IPsec protocol suite—PART 1
[---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 Layer
4) Padding / Padding Length – padding necessary to
inflate pkt to required fixed size (e.g., size required by
block cipher used for encryption)
11
© by Leszek T. Lilien, 2005
5) Next Header – type of data in Payload Data field
6) OPTIONAL: Authentication Data (unencrypted) –
authenticates all above fields
IPsec protocol suite (7)
ISAKMP (Internet Security Association Key Management
Protocol) = key mgmt protocol for IPsec


In IPsec, ISAKMP implemented via IKE (ISAKMP Key
Exchange)

IKE properties
 Provides ways to agree on protocols, cipher and
authentication algorithms, keys



12
Key mgmt is always a critical element in crypto apps
ISAKMP is simple, flexible, scalable
Distinct key for each IPsec security association (SA)



© by Leszek T. Lilien, 2005
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 DiffieHellman scheme
[---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

13
© by Leszek T. Lilien, 2005


Can be done in 2 messages if w/o authentication
Can be done in 4 messages if w/ authentication
vii. Signed code
14
© by Leszek T. Lilien, 2005

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
[---SKIP---] viii. Encrypted e-mail

E-mail msgs – like a postard that everybody who handles it
between S and R can read
People 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


15
E.g., PGP
E-mail security (incl. PGP and S/MIME) will be discussed
soon
© by Leszek T. Lilien, 2005
[---SKIP---] e) Msg content integrity
controls (1)
© by Leszek T. Lilien, 2005
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



16
E.g., changing a bit of data in packet
Threats to msg content integrity
1) Malicious modification that changes content
in a meaningful way
2) 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
EASIER
TO
PREVENT
OR
DETECT
[---SKIP---]

Msg content integrity controls (2)
Msg content integrity controls #1: DETECT
Error 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

Can also stop some malicious attacks

17
© by Leszek T. Lilien, 2005
Does not matter whether accidentally „meaningful” or not
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
[---SKIP---]


Msg content integrity controls (3)
[OPTIONAL] Msg content integrity controls #2: PREVENT
or DETECT
Cryptographic checksum / msg digest / hash
 To prevent or malicious attacks on data — As discussed
before („Intro to Cryptology” section)
Can also detect malicious errors
Can also detect nonmalicious errors
Note that attacker can modify:
 Modify only data bits
 Modify error prevention/detection mechanism
18 © by Leszek T. Lilien, 2005
f) Strong authentication


Networked environments as well as both ends of
communication need authentication
Strong authentication controls include:
i. One-time passwords
ii. Challenge-response systems
iii. Digital distributed authentication
iv. Kerberos authentication system
19 © by Leszek T. Lilien, 2005
[---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 list
OR
 User has password token (PT)
= device to randomly generate new pwd (e.g.) every
minute
E.g., SecureID device from Security Dynamics – random # every
minute
20
© by Leszek T. Lilien, 2005
[---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 OTP
1) Attacker can steal/find PT (device)
2) One-minute window of vulnerability
 Wiretapper can reuse password for one minute

21
If PT generates new pwd once per minute
© by Leszek T. Lilien, 2005
[---SKIP---] ii. Challenge-response
systems

Challenge-response systems solve OTP problems
1) 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
22 © by Leszek T. Lilien, 2005
[---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 HewlettPackard (2002)
[Wikipedia]
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
23 © by Leszek T. Lilien, 2005
[---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
24 © by Leszek T. Lilien, 2005
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)
25 © by Leszek T. Lilien, 2005
Kerberos authentication system (2)

User’s Step 1: Establishing session w/ Kerberos — Fig. 730, p. 448
 U’s workstat’n sends U’s identity to Kerberos server (KS)
 KS verifies that U is authorized
 KS sends 2 msgs:
U
U
1) Msg to U, which contains: E(ST-GS
+ TT-GS
, pwd)
U
 ST-GS
— U’s session key for session with T-GS
U
 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)


U
2) Msg to T-GS, which contains: ST-GS and U’s identity
(encrypted under key shared by KS and T-GS)
U
 ST-GS
— T-GS’s session key for session with U (same
as U’s session key for session with T-GS)

U
U
If U’s workstation can decrypt E(ST-GS
T
+ T-GS , pwd) using
its pwd, then U’s authentication succeeds
26 © by Leszek T. Lilien, 2005
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:
U
E(„request R for U’s ticket for accessing F” , ST-GS)
U
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...
27 © by Leszek T. Lilien, 2005
Kerberos authentication system (4)
...continued...

If verified OK, T-GS returns to U message encrypted
U
under ST-GS
, which contains:
1) U’s session key for session with F (really: with F’s file
U
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 is
 U’s authenticated identity (T-GS knows that ST-GS
U’s key —and nobody else’s— because KS sent to T-GS
U
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 = SFU (same
as U’s session key for session with F)
 Ticket expiration date
28 © by Leszek T. Lilien, 2005
Kerberos authentication system (5)

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

Limited period of ticket validity (disables some long-term

Prevents replay attacks (each user’s request stamped with

Mutual authentication (user can be assured of server’s
mediated by T-GS, which knows requester’s identity; this identity
known based on authentication performed initiallly by Kerb. server)
attacks—e.g., brute force cryptanalysis)
time of request; unreasonably old requests rejected by request
servers)
authenticity by requesting server’s authenticating response)
29 © by Leszek T. Lilien, 2005
Kerberos authentication system (6)

Weaknesses of Kerberos system
 Requires continuous availability of trusted ticketgranting 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)
30 © by Leszek T. Lilien, 2005
End of Class 32
31 © by Leszek T. Lilien, 2005