CMSC 414 Computer and Network Security Lecture 23
-
Upload
demetria-mccray -
Category
Documents
-
view
41 -
download
0
description
Transcript of CMSC 414 Computer and Network Security Lecture 23
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
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