1 / 32

IPsec: AH and ESP - Authentication and Encryption in Network Security

Learn about the authentication header (AH) and encapsulating security payload (ESP) in IPsec, their functions, and the future of IPsec. Get an overview of IKE, its phases, key types, anonymity, and negotiation of cryptographic parameters.

katef
Download Presentation

IPsec: AH and ESP - Authentication and Encryption in Network Security

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 27 Jonathan Katz

  2. IPsec: AH and ESP

  3. AH vs. ESP • Two header types… • Authentication header (AH) • Provides integrity only • Encapsulating security payload (ESP) • Provides encryption and/or integrity • Both provide cryptographic protection of everything beyond the IP headers • AH additionally provides integrity protection of some fields of the IP header

  4. More on AH • AH provides integrity protection on header • But some fields change en route! • Immutable fields included in the integrity check • Mutable but predictable fields are also included in the integrity check • The final value of the field is used

  5. More on AH vs. ESP • ESP can already provide encryption and/or authentication • So why do we need AH? • AH also protects the IP header • Export restrictions • Firewalls need some high-level data to be unencrypted • None of these are compelling…

  6. The future of IPsec? • In the long run, it seems that AH will become obsolete • Better to encrypt everything anyway • No real need for AH • Certain performance disadvantages • AH is complex… • Etc. • IPsec is still evolving

  7. IPsec: IKE

  8. 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) • Supported key types • Public signature keys • Public encryption keys • Symmetric keys

  9. 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 • E.g., different flows between same endpoints • Why not used same key for each? Is there any secure way to do this? • In practice, this anyway rarely happens

  10. Key types • As mentioned earlier… • Why are there two PK options? • Signature-based option • Efficiency (can start protocol knowing only your own public key, then get other side’s key from their certificate) • Legal reasons/export control • Encryption-based option • Can be used to provide anonymity in both directions • Adds tremendously to the complexity of implementation

  11. Anonymity • Protocols can be designed so that identities of the 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 generally known… • Responder: since otherwise it is easy to get anyone’s identity

  12. 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…

  13. IKE phase 1 • Aggressive mode • 3 messages • Main mode • 6 messages • Additional features: • Anonymity • Negotiation of crypto parameters

  14. 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

  15. Main mode • Negotiate crypto algorithms (2 rounds) • Alice and Bob do regular Diffie-Hellman key exchange (2 rounds) • Alice sends encryption of “Alice” plus a proof that she is Alice, using long-term secret keys plus [keys derived from] gab • Bob does similarly…

  16. 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 security suite) must be specified

  17. 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

  18. “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…

  19. Summary of IKE • IKE seems to be overly complex • Will almost certainly be replaced with an updated standard

  20. SSL/TLS

  21. 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”!

  22. 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

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

  24. 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

  25. 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

  26. 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” derived from the master key and fresh nonces

  27. 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

  28. Concluding note • SSL is a success story! • Used widely to authenticate transactions over the web

  29. Course wrap-up

  30. Final exam • Comprehensive • Besides understanding each topic in isolation, try to see the interconnections • I will try to post a summary of topics you need to know

  31. What should you take away from this course (after the final)? • Security mind-set • Not limited to computers/networks! • Security is complex • Draws on many different disciplines • Need to know what you are doing • Security is hard, still evolving • We did not cover the most important present-day attacks: spam, phishing, DDos, viruses, … • Security is fun!

  32. Thank you!

More Related