1. CMSC 414 Computer (and Network) Security Lecture 25 Jonathan Katz

2. Security in what layer?  Depends on the purpose… –What information needs to be protected? –What is the attack model? –Who shares keys in advance? –Should the user be involved?  E.g., a network-layer protocol cannot authenticate two end-users to each other  Also affects efficiency, ease of deployment

3. Example: SSL vs. IPSec  SSL sits “on top of” the transport layer (e.g., TCP) –The OS does not have to be changed –Easy to modify applications to use SSL, if desired –If SSL rejects a packet that is accepted by TCP, then the connection must be closed! Potential denial of service attack

4. Example: SSL vs. IPSec  IPSec sits “on top of” the network layer –Need to modify OS –All applications now “protected” by default, without requiring any change to applications or actions on behalf of users –Can only authenticate IP addresses, not users

5. Take home message…  Best solution involves changes at both the OS and applications layers –The “best” solution is not to run SSL and IPSec! –Would have been better to design system with security in mind from the beginning… –(Keep in mind for future systems…)

6. Example protocols…  We will look at –IPSec (and IKE, if time) –SSL –PGP (if time)

7. IPSec: AH and ESP

8. Overview  IPSec consists of two components –AH/ESP Used once a key is established (either using IKE or out-of-band) –IKE Can be used to establish a key

9. Security associations (SAs)  An SA is a crypto-protected connection –One SA in each direction…  At each end, the SA contains a key, the identity of the other party, the sequence number, and crypto parameters  IPSec header indicates which SA to use –Chosen by destination –Won’t go into more detail…

10. More on SAs…  Parties will maintain a database of SAs for currently-open connections –Used both to send and receive packets

11. AH vs. ESP  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

12. Anti-replay  All authenticated communication includes a sequence number  This prevents replay attacks –Note that this is not entirely trivial since IP may deliver packets out of order…

13. Tunnel vs. transport mode  Transport mode: add IPSec information between IP header and rest of packet –IP header | IPSec | packet –Most logical when IPSec used end-to-end

14. Tunnel vs. transport mode  Tunnel mode: keep original IP packet intact; add new header information –New IP header | IPSec | old header | packet –Can be used when IPSec is applied at intermediate point along path (e.g., for firewall- to-firewall traffic) E.g., change source/destination info… –Results in slightly longer packet –Note that data may be encrypted multiple times

15. Issues…  NATs –If address translation is done, the integrity check will fail due to changes address/port information!  Firewalls –Problem if data used for decision-making is encrypted end-to-end –Arguments pro and con as to whether this data should be encrypted or not

16. More on AH  AH provides integrity protection on header –But some fields change en route!  Only immutable fields are included in the integrity check  Mutable but predictable fields are also included in the integrity check –E.g., for source routing… –The final value of the field is used

17. More on AH vs. ESP  Recall that ESP provides 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…

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

19. IPSec: IKE

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

21. 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…? –No good answer

22. IKE phase 1  Aggressive mode –3 messages  Main mode –6 messages –Additional features: Anonymity Negotiation of crypto parameters

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

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

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

26. 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…  Also makes for more complicated implementations

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

28. Aggressive mode  Alice sends g a, “Alice”, crypto algorithms –Note that choices are restricted by this message  Bob sends g b, 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

29. 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 g ab  Bob does similarly…

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

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