Transcript IPsec

IPsec
• IPsec (IP security)
• Security for transmission over IP
networks
– The Internet
– Internal corporate IP networks
– IP packets sent over public switched data
networks (PSDN)
Local
Network
Internet
Local
Network
IPsec
• Why do we need IPsec?
– IP has no security
– Add security to create a virtual private
network (VPN) (Chapter 9) to give secure
communication over the Internet or another
IP network
Local
Network
Internet
Local
Network
IPsec
• Genesis
– Being created by the Internet Engineering Task
Force
– For both IP version 4 and IP version 6
IPsec
• Two Modes of operation
• Tunnel Mode
– IPsec server at each site
– Secures messages going through the Internet
Local
Network
Secure Communication
Internet
Local
Network
IPsec
Server
IPsec
• Tunnel Mode
– Hosts operate in their usual way
• Tunnel mode IPsec is transparent to the hosts
– No security within the site networks
Local
Network
Secure Communication
Internet
Local
Network
IPsec
Server
IPsec
• Two Modes of operation
• Transport Mode
– End-to-end security between the hosts
– Security within site networks as well
– Requires hosts to implement IPsecLocal
Local
Network
Secure Communication
Internet
Network
IPsec
• Transport Mode
– Adds a security header to IP packet
– After the main IP header
– Source and destination addresses of hosts can
be learned by interceptor
– Only the original data field is protected
Original
IP Header
Transport
Security
Header
Protected
Original Data Field
IPsec
• Tunnel Mode
– Adds a security header before the original IP
header
– Has IP addresses of the source and
destination IPsec servers only, not those of
the source and destination hosts
– Protects the main IP header
Tunnel
Security
Header
Protected
Original
IP Header
Protected
Original Data Field
IPsec
• Can combine the two modes
– Transport mode for end-to-end security
– Plus tunnel mode to hide the IP addresses of
the source and destination hosts during
passage through the Internet
Local
Network
Tunnel Mode
Internet
Local
Network
Transport Mode
IPsec
• Two forms of protection
• Encapsulating Security Protocol (ESP) security
provides confidentiality as well as authentication
• Authentication Header (AH) security provides
authentication but not confidentiality
– Useful where encryption is forbidden by law
– Provides slightly better authentication by providing
authentication over a slightly larger part of the message,
but this is rarely decisive
IPsec
• Modes and protection methods can be
applied in any combination
Tunnel
Mode
Transport
Mode
ESP
Supported Supported
AH
Supported Supported
IPsec
• Security Associations (SAs) are agreements
between two hosts or two IPsec servers,
depending on the mode
• “Contracts” for how security will be
performed
• Negotiated
• Governs subsequent transmissions
Host A
Negotiate
Security Association
Host B
IPsec
• Security Associations (SAs) can be
asymmetrical
– Different strengths in the two directions
– For instance, clients and servers may have
different security needs
SA for messages
From A to B
Host A
Host B
SA for messages
From B to A
IPsec
Policies may limit what SAs can be
negotiated
– To ensure that adequately strong SAs for the
organization’s threats
– Gives uniformity to negotiation decisions
Host A
Security Association
Negotiations Limited
By Policies
Host B
IPsec
• First, two parties negotiate IKE (Internet
Key Exchange) Security Associations
– IKE is not IPsec-specific
– Can be used in other security protocols
Host A
Communication
Governed by
IKE SA
Host B
IPsec
• Under the protection of communication
governed by this IKE SA, negotiate IPsecspecific security associations
Host A
Communication
Governed by
IKE SA
IPsec SA Negotiation
Host B
IPsec
• Process of Creating IKE SAs (and other SAs)
– Negotiate security parameters within policy
limitations
– Authenticate the parties using SA-agreed methods
– Exchange a symmetric session key using SA-agreed
method
– Communicate securely with confidentiality, messageby-message authentication, and message integrity
using SA-agreed method
IPsec
• IPsec has mandatory security algorithms
– Uses them as defaults if no other algorithm is
negotiated
– Other algorithms may be negotiated
– But these mandatory algorithms MUST be
supported
IPsec
• Diffie-Hellman Key Agreement
– To agree upon a symmetric session key to be
used for confidentiality during this session
– Also does authentication (not discussed)
Party A
Party B
IPsec
• Diffie-Hellman Key Agreement
– Each party sends the other a nonce (random
number)
– The nonces will almost certainly be different
– Nonces are not sent confidentially
Nonce B
Party A
Party B
Nonce A
IPsec
• Diffie-Hellman Key Agreement
– From the different nonces, each party will be
able to compute the same symmetric session
key for subsequent use
– No exchange of the key; instead, agreement on
the key
Symmetric Key
Party A
Symmetric Key
From nonces,
independently compute
same symmetric
session key
Party B
IPsec
• Mandatory algorithm for confidentiality is
DES-CBC
– DES with Cipher Block Chaining
– An extension of DES (Data Encryption
Standard)
– Straight DES always gives the same ciphertext
for the same plaintext and key
– This allows certain types of attacks to guess
passwords
IPsec
• DES-CBC (DES Cipher Block Chaining)
– DES works in blocks of 64 bits
– DES-CBC begins with 64-bit plaintext to be
encrypted
– Combines with the ciphertext output from the
previous block (cipher block chaining)
Plaintext
Block
+
Previous
Ciphertext
Block
Cipher
Block
Chaining
Block
To be
Encrypted
IPsec
• DES-CBC
– Encrypts the plaintext block plus previous
ciphertext block to give ciphertext for the
current block
– This gives different ciphertexts for the same
plaintext and key on different occasions
Block
To be
Encrypted
DES Encryption
Ciphertext
For Block
IPsec
• Adding Plaintext and Ciphertext together in
DES-CBC
– The bits are XORed
– The result is 1 if one bit (but not both) is 1
• 1 XOR 0 = 1
• 0 XOR 1 = 1
– The result is 0 if both bits are 1 or 0
• 1 XOR 1 = 0
• 0 XOR 0 = 0
IPsec
• Adding Plaintext and Ciphertext together in
DES-CBC
–
–
–
–
The bits are XORed
If the ciphertext is
And the plaintext is
The result is
111000 …
101010 …
010010 …
IPsec
• HMAC
– key-Hashed Message Authentication Code
– Mandatory IKE message-by-message
authentication and message integrity algorithm
– Not a digital signature
– HMAC does not use public key encryption
– So it is faster than digital signature
authentication, which uses public key
encryption
IPsec
• HMAC
– Begins with original plaintext
– Adds a secret HMAC key that only the
communicating partners know
• It is a shared secret
• Usually different from the symmetric key used to
send the entire message confidentiality
Original
Plaintext
HMAC
Key
IPsec
• HMAC
– Hashes the combination with MD5 or SHA1
– This gives the HMAC
– Get different HMACs with different HMAC
keys
Original
Plaintext
HMAC
Key
Hashing
HMAC
IPsec
• HMAC
–
–
–
–
The HMAC is added to the original plaintext
Gives authentication and message integrity
HMAC is similar to digital signature
However, hashes instead of using public key
encryption, so processing is faster
HMAC
Original
Plaintext
• HMAC
IPsec
– Receiver again hashes plaintext message plus
shared secret HMAC key
– If the same as transmitted HMAC, sender is
authenticated because the sender knows the
shared secret HMAC key
Transmitted Transmitted Original
HMAC
Plaintext
Transmitted Original HMAC
Plaintext
Key
Hashing
Computed
HMAC
IPsec
• IPsec only uses symmetric key encryption and
hashing, which are very fast
• Avoids public key encryption, which is very slow
– Diffie-Hellman key exchange instead of sending
session key encrypted with receiver’s public key
– HMAC instead of digital signatures
• This allows IPsec to be fairly fast, reducing host or
IPsec security server costs