CMSC 414
Computer (and Network) Security
Lecture 25
Jonathan Katz
Security in what layer?
 Depends on the purpose…
– What information needs to be protected?
– What is the attack model?
– Who shares keys in advance?
– Should the user be involved?
 E.g., a network-layer protocol cannot
authenticate two end-users to each other
 Also affects efficiency, ease of deployment
Example: SSL vs. IPSec
 SSL sits “on top of” the transport layer (e.g.,
TCP)
– The OS does not have to be changed
– Easy to modify applications to use SSL, if
desired
– If SSL rejects a packet that is accepted by TCP,
then the connection must be closed!
• Potential denial of service attack
Example: SSL vs. IPSec
 IPSec sits “on top of” the network layer
– Need to modify OS
– All applications now “protected” by default,
without requiring any change to applications or
actions on behalf of users
– Can only authenticate IP addresses, not users
Take home message…
 Best solution involves changes at both the
OS and applications layers
– The “best” solution is not to run SSL and
IPSec!
– Would have been better to design system with
security in mind from the beginning…
– (Keep in mind for future systems…)
Example protocols…
 We will look at
– IPSec (and IKE, if time)
– SSL
– PGP (if time)
IPSec: AH and ESP
Overview
 IPSec consists of two components
– AH/ESP
• Used once a key is established (either using IKE or
out-of-band)
– IKE
• Can be used to establish a key
Security associations (SAs)
 An SA is a crypto-protected connection
– One SA in each direction…
 At each end, the SA contains a key, the
identity of the other party, the sequence
number, and crypto parameters
 IPSec header indicates which SA to use
– Chosen by destination
– Won’t go into more detail…
More on SAs…
 Parties will maintain a database of SAs for
currently-open connections
– Used both to send and receive packets
AH vs. ESP
 Authentication header (AH)
– Provides integrity only
 Encapsulating security payload (ESP)
– Provides encryption and/or integrity
 Both provide cryptographic protection of
everything beyond the IP headers
– AH additionally provides integrity protection of
some fields of the IP header
Anti-replay
 All authenticated communication includes a
sequence number
 This prevents replay attacks
– Note that this is not entirely trivial since IP may
deliver packets out of order…
Tunnel vs. transport mode
 Transport mode: add IPSec information
between IP header and rest of packet
– IP header | IPSec | packet
– Most logical when IPSec used end-to-end
Tunnel vs. transport mode
 Tunnel mode: keep original IP packet intact;
add new header information
– New IP header | IPSec | old header | packet
– Can be used when IPSec is applied at
intermediate point along path (e.g., for firewallto-firewall traffic)
• E.g., change source/destination info…
– Results in slightly longer packet
– Note that data may be encrypted multiple times
Issues…
 NATs
– If address translation is done, the integrity
check will fail due to changes address/port
information!
 Firewalls
– Problem if data used for decision-making is
encrypted end-to-end
– Arguments pro and con as to whether this data
should be encrypted or not
More on AH
 AH provides integrity protection on header
– But some fields change en route!
 Only immutable fields are included in the
integrity check
 Mutable but predictable fields are also
included in the integrity check
– E.g., for source routing…
– The final value of the field is used
More on AH vs. ESP
 Recall that ESP provides encryption and/or
authentication
 So why do we need AH?
– AH also protects the IP header
– Export restrictions
– Firewalls need some high-level data to be
unencrypted
 None of these are compelling…
The future of IPSec?
 In the long run, it seems that AH will
become obsolete
–
–
–
–
–
Better to encrypt everything anyway
No real need for AH
Certain performance disadvantages
AH is complex…
Etc.
 IPSec is still evolving
IPSec: IKE
Overview of IKE
 IKE provides mutual authentication, establishes
shared key, and creates SA
 Assumes a long-term shared key, and uses this to
establish a session key (as well as to provide
authentication)
 Key types
– Public signature keys
– Public encryption keys
– Symmetric keys
IKE phases
 Phase 1: long-term keys used to derive a
session key (and provide authentication)
 Phase 2: session key used to derive SAs
 Why…?
– No good answer
IKE phase 1
 Aggressive mode
– 3 messages
 Main mode
– 6 messages
– Additional features:
• Anonymity
• Negotiation of crypto parameters
Anonymity
 Protocols can be designed so that identities
of parties are hidden from eavesdroppers
– Even while providing authentication!
 Can also protect anonymity of one side
against active attacks
– Whom to protect?
• Initiator: since responder’s identity is known…
• Responder: since otherwise it is easy to get anyone’s
identity
Key types
 As mentioned earlier…
 Why are there two PK options?
– Signature-based option
• Escrow
• Legal reasons
– Encryption-based option
• Can be used to provide anonymity in both directions
 Adds tremendously to the complexity
Crypto parameters…
 Choice of:
– Encryption method (DES, 3DES, …)
– Hash function (MD5, SHA-1, …)
– Authentication method (e.g., key type, etc.)
– Diffie-Hellman group (e.g., (g, p), etc.)
 A complete set of protocols (a suite) must
be specified
Negotiating parameters
 Many protocols allow parties to negotiate
cryptographic algorithms and parameters
– Allows users to migrate to stronger crypto;
increases inter-operability (somewhat)
 But, opens up a potential attack…
 Also makes for more complicated
implementations
Phase 1 session keys
 Two session keys are defined in phase 1
– One each for encryption/authentication
 These keys are used to protect the final
phase 1 messages as well as all phase 2
messages
 These keys are derived from the DH key
using hashing
– Details in the book…
Aggressive mode
 Alice sends ga, “Alice”, crypto algorithms
– Note that choices are restricted by this message
 Bob sends gb, choice of crypto algorithm,
“proof” that he is really Bob
– If Bob does not support any of the suggested
algorithms, he simply does not reply
– Note that there is no way to authenticate a
refusal, since no session key yet established
 Alice sends “proof” that she is Alice
Main mode
 Negotiate crypto algorithms (2 rounds)
 Alice and Bob do anonymous Diffie-
Hellman key exchange (2 rounds)
 Alice sends “Alice” plus a proof that she is
Alice, all encrypted using gab
 Bob does similarly…
“Proofs” of identity
 Depend on which type of long-term shared
key is being used
 Similar (in spirit) to the authentication
protocols discussed in class
– Details in book…
Summary of IKE
 IKE seems to be overly complex
 Will almost certainly be replaced with an
updated standard