CMSC 414
Computer and Network Security
Lecture 23
Jonathan Katz
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…?
– In theory, can run phase 1 once, followed by
multiple executions of phase 2
– In practice, this rarely happens
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 if not
authenticated somehow…
 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
SSL/TLS
Brief history…
 SSLv2 deployed in Netscape 1.1 (1995)
 Microsoft improved upon it…
 Netscape deployed SSLv3
– Most commonly deployed
 IETF introduced TLS
– Similar, but incompatible…
 Here, we just say “SSL”!
Broad overview
 SSL runs on top of TCP, in a user-level
process
– Recall, does not require changes to the OS
– Using TCP rather than UDP simplifies things
• Recall, this opens a potential DoS attack
Basic protocol flow
 Alice (client) sends “hello”, supported
crypto, and nonce RA
 Bob (server) sends a certificate, selects
crypto, and sends nonce RB
 Alice encrypts S with Bob’s public key
– Alice/Bob derive key(s) from RA, RB, S
– Must be careful about which encryption scheme
is used!
Basic flow, continued…
 They each authenticate the initial handshake
using the shared key(s)
 The keys are used to encrypt/authenticate
all subsequent communication
– Separate keys shared for encryption and
authentication in each direction
– Also for IVs… (but this is a flaw!)
– Sequence numbers used to prevent replay
Note…
 As described, SSL only provides only one-
way authentication (server-to-client)
– Not generally common for clients to have
public keys
 Can do mutual authentication over SSL
using, e.g., a password
– SSL also allows for clients to have public keys
Session resumption
 Because it was designed with http traffic in
mind, one “session” can be used to derive
many secure “connections”
– Server assigns a session_id and stores that
along with the master secret key; sends
session_id to client during handshake protocol
– “Connection keys” can be derived from the
master key (assumes the client remembers it)
and fresh nonces
– Can always re-derive a master key (expensive!)
Some attacks (and fixes)
 Man-in-the-middle can downgrade the
acceptable crypto in Alice’s first message
– One of the problems with negotiating crypto…
– Fixed by authenticating handshake phase
 An adversary could also close a connection
early (TCP close_connection_request was
not integrity-protected)
– Fixed by adding “finish” message which is
authenticated