CMSC 414Computer 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