1 / 22

CMSC 414 Computer and Network Security Lecture 23

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

demetria-mccray
Download Presentation

CMSC 414 Computer and Network Security Lecture 23

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 responder’s identity is known… • Responder: since otherwise it is easy to get anyone’s 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 Bob’s 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 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

More Related