1. ECE 454/CS 594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2011 1

2. IPsec: IKE Photuris and SKIP PHASE 1 IKE PHASE 2 IKE

3. Security Association Issues How is SA established? ◦ How do parties negotiate a common set of cryptographic algorithms and keys to use? More than one SA can apply to a packet! ◦ E.g., end-to-end authentication (AH) and additional encryption (ESP) on the public part of the network

4. IKE: Internet Key Exchange Purpose ◦ Mutual Authentication ◦ Shared Secret Establishment ◦ Crypto Algorithms Negotiation ◦ Security Association Establishment

5. IPsec Key Management Data transmitted needs to be secured ◦ IPsec SA, session keys, AH or ESP Messages for establishing IPsec SA need to be secured ◦ IKE SA, negotiated secret Negotiation for establishing IKE SA need to be authenticated ◦ Pre-shared secret key ◦ Public/private keys

6. Review: Cookies Clogging attacks ◦ An opponent forges the source address of a legitimate user and send a public Diffie-Hellman key to the victim; The victim then performs a modular exponentiation to compute the secret key; Repeated messages of this type can clog the victim’s system with useless work. First proposed in Photuris; Cookie ◦ A number chosen by responder; When receiving a request from S, send the cookie to S in clear; start the processing after the cookie comes back from the initiator. Stateless cookies ◦ The responder does not have to remember (store) the cookies he sent out; The cookie is a function of the IP address and a secret known to the responder

7. A Stateless Cookie Protocol

8. Photuris

9. Features of Photuris Denial of service protection: ◦ Stateless cookie C B in message 2 Signed Diffie-Hellman exchange ◦ Signature on the previous message in message 5 and 6 Identity hiding ◦ Anonymous Diffie-Hellman ◦ Identities are encrypted in message 5 and 6 (for active man-in-the-middle, the initiator’s identity is revealed, but not the responder)

10. SKIP uses long term Diffie-Hellman public keys ◦ Alice finds Bob’s public key (g B mod p ) via a certificate from Bob or a directory. Bob finds Alice’s public key (g A mod p ). Then they will have a common secret (g AB mod p). Data encryption ◦ Long term common secret should not be used to encrypt data. Instead each message has a SKIP header where the long term secret is used to encrypt a short-term data encryption key, which is used to encrypt the message. SKIP: Simple Key Management for Internet Protocols

11. IKE Phases Phase One ◦ Mutual authentication ◦ Session key establishment ◦ ISAKMP SA/IKE SA Phase Two ◦ Negotiating IPsec SAs (AH, ESP)

12. Why two phases? ISAKMP would be used by other protocols to set up SAs, not only to set up IPsec SAs. Phase 1 exchange is relatively expensive. ISAKMP/IKE SA has a longer timeout period. It can be used to negotiate multiple phase 2 IPsec SAs, which reduces the usage of pre-shared secret or private key.

13. Phase 1 IKE Two modes Aggressive mode ◦ 3 messages ◦ Mutual authentication ◦ Session key establishment Main Mode ◦ 6 messages ◦ Mutual authentication ◦ Session key establishment ◦ Hiding endpoint identity ◦ Negotiating cryptographic algorithms

14. Phase 1: Aggressive Mode

15. Phase 1: Main Mode

16. Negotiating Cryptographic Parameters Encryption algorithm (e.g., DES, 3DES, IDEA) Hash algorithm (e.g., MD5, SHA) Authentication method (e.g., pre-shared keys, RSA public key signature, DSS, RSA public key encryption) Diffie-Hellman group (e.g., g and p)

17. Crypto Proposals Alice sends Bob a list of proposals, each consisting of an encryption algorithm, a hash algorithm, authentication method, and a Diffie- Hellman group. Bob replies one as the accepted proposal. The parameters in the proposal are used in Phase 1 and Phase 2 (IKE SA), with hash algorithm used for various purposes.

18. Key Types Mutual authentication based on ◦ Pre-shared secret key ◦ Public encryption key  Original protocol design  Improved Protocol design ◦ Public signature key

19. Cookie Issues IKE is stateful, starting from the first message. ◦ Alice’s crypto proposal is in the identity proof ◦ ISAKMP requires randomly chosen cookies Identifier:

20. Session Keys After Diffie-Hellman key exchange, each side knows g xy mod p Encryption key and Integrity key for the rest of IKE SA Keys for IPSec SAs

21. Session Keys Pseudo Random function – prf(key, data), e.g., CBC residue, HMAC SKEYID ◦ For signature public keys, prf(nonces, g xy ) ◦ For encryption public keys, prf(hash(nonces), cookies) ◦ For pre-shared secret keys, prf(pre-shared secret key, nonces) SKEYID_d: secret bits used to create other keys ◦ prf(SKEYID, g xy | cookies | 0) SKEYID_a: the integrity protection key ◦ prf(SKEYID, SKEYID_d | g xy | cookies | 1) SKEYID_e: the encryption key ◦ prf(SKEYID, SKEYID_d | g xy | cookies | 2)

22. Proof of Identity Proof of the key associated with the identity ◦ pre-shared secret key ◦ private encryption key ◦ private signature key Integrity-check on the previous messages, such as identity, Diffie-Hellman values, nonce, Alice’s crypto proposal, and the cookies.

23. Proof of Identity (Cont’d) Alice’s proof of identity ◦ prf ( SKEYID, g x | g y | cookies | Alice’s initial proposals | Alice’s identity ) Bob’s proof of identity ◦ prf ( SKEYID, g x | g y | cookies | Alice’s initial proposal | Bob’s identity )

24. IKE phase 1 protocols 8 phase-1 protocols ◦ 2 modes ◦ 4 types of keys Common features ◦ Message 1 starts with Alice’s cookie ◦ All other messages start with (initiator cookie, responder cookie), which serves as the IKE connection identifier

25. Phase 1: Public Signature Keys, Main Mode

26. Phase 1: Public Signature Keys, Aggressive Mode

27. Phase 1: Public Encryption Keys, Main Mode, Original

28. Phase 1: Public Encryption Keys, Aggressive Mode, Original

29. Phase 1: Public Encryption Keys, Main Mode, Revised

30. Phase 1: Public Encryption Keys, Aggressive Mode, Revised

31. Phase 1: Pre-Shared Secret Keys, Main Mode

32. Phase 1: Pre-Shared Secret Keys, Aggressive Mode

33. Phase 2, Quick Mode Establish IPSec SAs (e.g., ESP and/or AH) ◦ Crypto parameters ◦ Diffie-Hellman numbers (optional) ◦ Traffic type (optional) All messages (except X,Y) encrypted and integrity protected

34. Reading Assignment [Kaufman] Chapter 18