CMSC 414 Computer and Network Security Lecture 23

1
CMSC 414Computer and Network SecurityLecture 23

• Jonathan Katz

2
IPsec IKE
3
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

4
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

5
IKE phase 1

• Aggressive mode
• 3 messages
• Main mode
• 6 messages
• Additional features
• Anonymity
• Negotiation of crypto parameters

6
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 responders identity is known
• Responder since otherwise it is easy to get
  anyones identity

7
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

8
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

9
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

10
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

11
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

12
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

13
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

14
Summary of IKE

• IKE seems to be overly complex
• Will almost certainly be replaced with an updated
  standard

15
SSL/TLS
16
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!

17
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

18
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 Bobs public key
• Alice/Bob derive key(s) from RA, RB, S
• Must be careful about which encryption scheme is
  used!

19
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

20
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

21
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!)

22
Some attacks (and fixes)

• Man-in-the-middle can downgrade the acceptable
  crypto in Alices 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