5. DIFFIEHELLMAN KEY EXCHANGE The Diffie-Hellman key exchange is a public- key technology. It is (by itself) not an encryption algorithm (or signature algorithm).
6. DIFFIE-HELLMAN GROUPS Public key use encryption algorithms to encrypt the data: DES 3DES AES Blowfish DH Group: Used to determine the strength of the key: DH Group 1: 768-bit group DH Group 2: 1024-bit group DH Group 5: 1536-bit group DH Group 14: 2048-bit group DH Group 15: 3072-bit group DH Group 19: 256-bit elliptic curve group DH Group 20: 384-bit elliptic curve group
7. DATA INTEGRITY AND HASHING Hashed message authentication code HMAC is used to perform this hashing function. HMAC Algorithms: HMAC-MD5: 128 bit hashed key. HMAC-SHA1: 160 bit hashed key.
8. AUTHENTICATION Use either: Pre-shared keys: a secret string of text is used on each device to authenticate each other. This string must be pre-agreed upon and identical in each device. This string is then hashed into a digital signature. RSA Digital Signature: a CA is used to apply a verified digital signature.
9. CERTIFICATE AUTHORITY Certificate authority: A client creates a blank or unsigned certificate and sends it to can including the clients ID. This communication secured using DH private/public key exchange. CA computes an encrypted hash. The certificate is now signed with the CAs digital signature and the it sent back to the client. The client then send the signed certificate, along with its keys, to any VPN peers. Vendors: Verisign Godaddy EnTrust
10. IPSEC PROTOCOLS
11. AUTHENTICATION HEADER AH Only provides both authentication and integrity because it doesnt encrypt the packet. It compute a hash value on both the payload and the header of the packet. It will not work through a NATed devices because NATing changes the IP header of a packet during translation.
12. ENCAPSULATION SECURITY PAYLOAD ESP Provides CIA but the hash doesnt include the IP header of the packet ESP work on a NATed devices Add additional header and tail to a packet.
13. TRANSPORT VS TUNNEL MODES Transport mode: No edits on the IP header. Used in securing communication from on device to another. Tunnel mode: the entire packet is hashed or encrypted a temporary IP header is applied to the packet during transit Used to tunnel traffic from one site to another.
14. SECURITY ASSOCIATIONS AND ISAKMP SA is a collection of parameters required to establish a secure session SA is unidirectional, two SA required for a bidirectional communication, a single SA can be used for AH or ESP, but not both, must create two or more SA for each direction if using both AH and ESP Security Association Database ( SAD) , Security Policy Database (SPD) ISAKMP is internet security association and key management protocol, used for establishing security associations and cryptographic keys, only provides the framework for authentication and key exchange, but key exchange independent.
15. INTERNET KEY EXCHANGE (IKE) Used for establishing IPSEC sessions Five variation of an IKE negotiation, two modes (aggressive and main modes) Three authentication methods (pre- shared, public key encryption and public key signature)
16. IKE PHASE 1 Establish the initial tunnel and negotiate and keys are exchanged based on the IKE policy sets. Two Modes: Main Mode & aggressive mode - IKE Policy sets are created to negotiate several parameters: 1- DH group: determine the key length & create it 2- Encryption Algorithms: DES, 3DES, AES 3- Hashing Algorithms: MD5, SHA-1 4- Authentication method: pre-shared key or RSA signature 5- SA lifetime
17. IKE PHASE 2 Establish the IPSEC tunnel IPSEC SA, negotiate parameters for the data traversing that tunnel These parameters are contained in an IPSEC transform set: 1- DH group: determine the key length & create it 2- Encryption Algorithms: DES, 3DES, AES 3- Hashing Algorithms: MD5, SHA-1 4- Authentication method: pre-shared key or RSA signature 5- SA lifetime
18. THE FIVE STEPS OF IPSEC
19. STEP 1- DEFINING INTERESTING TRAFFIC Using ACL
20. STEP 2 - IKE PHASE 1
21. STEP 3 - IKE PHASE 2 The purpose of IKE phase 2 is to negotiate IPSec SAs to set up the IPSec tunnel. IKE phase 2 performs the following functions: Negotiates IPSec SA parameters protected by an existing IKE SA Establishes IPSec security associations Periodically renegotiates IPSec SAs to ensure security Optionally performs an additional Diffie-Hellman exchange IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure tunnel in phase 1. It negotiates a shared IPSec policy, derives shared secret keying material used for the IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces that provide replay protection. The nonces are used to generate new shared secret key material and prevent replay attacks from generating bogus SAs. Quick mode is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires. Base quick mode is used to refresh the keying material used to create the shared secret key based on the keying material derived from the Diffie-Hellman exchange in phase 1.