Internet Security CSCE 813 IPsec

CSCE Farkas2 Reading Today: – Oppliger: IPSec: Chapter 14 – Stalllings: Network Security Essentials, 3 rd edition, Chapter 6 Related readings (not required) – IPSec Architecture RFC 2401 – ISAKMP RFC 2408 – IKE RFC 2409 – HMAC RFC 2104

IPSec Overview IPSec can be added to either IPv4 or IPv6 Supported functionalities: authentication, confidentiality, and key management Scope of authentication: entire packet (tunnel mode) or entire packet minus the IP header (transport mode) Confidentiality: can be supported in either mode. Flexible Key Management CSCE Farkas3

Internet Key Exchange

CSCE Farkas5 IKE Goal: create security association between 2 hosts Two phases: – 1st phase establishes security association (IKE-SA) for the 2nd phase Always by authenticated Diffie-Hellman (expensive) – 2nd phase uses IKE-SA to create actual SAs to be used by AH and ESP Use keys derived in the 1st phase to avoid DH exchange Operates only in “quick” mode –To create a fresh key, hash old DH value and new nonces

CSCE Farkas6 Properties What properties are needed? – Authentication – Secrecy – Forward Secrecy (Perfect FS) – Prevent replay of old key material – Prevent denial of service – Protect identities from eavesdroppers

CSCE Farkas7 Key Management in IPSec Manual key management System administrator manually configures each system with its own keys – not scalable Automated key management On-demand creation of keys for the SAs – scalable for large, distributed systems

CSCE Farkas8 Internet Key Exchange ISAKMP/Oakley – Oakley key determination protocol Based on Diffie-Hellman Added security (e.g., authentication) Does not dictated specific format – ISAKMP – Internet Security Association and Key Management Protocol Framework for key management Specific protocol support (format, negotiation, etc.)

CSCE Farkas9 Diffie-Hellman Key Exchange Prior agreement of two parameters: g and p A selects random integer a, B selects random integer b Protocol g a mod p g b mod p A B Alice, Bob compute g ab mod p not known to anyone else

CSCE Farkas10 Problems with DH No information about identities Subject to a man-in-the-middle type attack Computationally extensive: vulnerable to a clogging attack – Attacker sends fake DH messages to a victim from a forged IP address – Victim starts performing modular exponentiations to compute a secret key – Victim can be blocked with useless work

CSCE Farkas11 Added Security Features of Oakley Cookie exchange: thwart clogging attacks – Properties: depends on specific parties, impossible to anyone else to generate cookies, fast – hash(src IP addr, dst IP addr, src UDP port, dst UDP port, local secret) Ensure that the responder is stateless until initiator produced at least 2 messages – Responder’s state (IP addresses and ports) is stored in an un- forgeable cookie and sent to initiator – After initiator responds, cookie is regenerated and compared with the cookie returned by the initiator – The cost is 2 extra messages in each execution

CSCE Farkas12 Added Security Features of Oakley Nonces: detect replay attacks Authenticates the DH exchange – Digital signatures, public key encryption, or symmetric key encryption Support negotiation of the global parameters for the DH exchange – DH groups: global parameters and identity of algorithms

Key Exchange Identities: not secret Derived key: PFS Two modes: – Main mode: 5 messages, protects IDs – Aggressive mode: 3 messages, does not protect IDs Multiple variations, see The OAKLEY Key Determination Protocol, CSCE Farkas13

CSCE Farkas14 Aggressive Oakley Example – CKY I : I’s cookie – OK_KEYX: key exchange message type – GRP: DH group, g x, g y : public key of init. and resp., g xy : session key – EHAO/EHAS: encryption, hash, authentication alg. offered/selected – NIDP: indicates encryption is not used for remainder of this message – N: nonce, ID: identifier, – S KI [X] I  R: CKY I,OK_KEYX, GRP, g x, EHAO, NIDP, ID I, ID R, N I, S KI [ ID I || ID R || N I || GRP || g x || EHAO] R  I: CKY R, CKY I, OK_KEYX, GRP, g y, EHAS, NIDP, ID R, ID I, N R, N I, S KR [ ID R || ID I || N R || N I || GRP || g x || g y || EHAS] I  R: CKY I, CKY R, OK_KEYX, GRP, g x, EHAS, NIDP, ID I, ID R, S KI [ ID I || ID R || N I || N R || GRP || g x || g y || EHAS]

CSCE Farkas15 ISAKMP Defines procedures and packet formats to – Establish – Negotiate – Modify – Delete security associations

CSCE Farkas16 ISAKMP Header Format Next payload Mj ver Mn Ver Exchange type Flags Message ID Length Initiator cookie Responder cookie Next payload ReservedPayload length payload ISAKMP header Generic payload header

CSCE Farkas17 Payload Types Security Association (SA) Proposal (P) – info used during SA negotiation, e.g., protocol type, sender’s SPI, # of transforms Transform (T) – defines the security transform to be used, transform # (ids the payload), transform id (specific transforms) Key exchange (KE) – key exchange techniques Identification (ID) – identity of the communicating peers Certificate (CR) – public-key certificate (X.509. Kerberos, etc.) Hash (HASH) Signature (SIG) Nonce (NONCE) Notification (N) Delete (D)

CSCE Farkas18 Base Exchange Allows key exchange and authentication material to be transmitted together Minimizes number of exchanges Does not provide ID protection Protocol: 1. I  R : SA; NONCE 2. R  I : SA; NONCE 3. I  R : KE; ID I ; AUTH 4. R  I : KE; ID R ; AUTH 1-2: cookies + SA establish; nonce: replay protection 3-4: key materials and IDs

CSCE Farkas19 Identity Protection Exchange Expands the Base exchange to protect user IDs. Protocol: 1. I  R : SA 2. R  I : SA 3. I  R : KE; NONCE 4. R  I : KE; NONCE 5. I  R : ID I ; AUTH 6. R  I : ID R ; AUTH 1-2: establish SA 3-4: key exchange + replay protection 5-6: authentication + optional certificate

CSCE Farkas20 Authentication Only Exchange Perform mutual authentication without key exchange Protocol: 1. I  R : SA; NONCE 2. R  I : SA; NONCE; ID R ; AUTH 3. I  R : ID I ; AUTH 1-2: establish SA + responder send his/her ID + authenticate the msg. 3: I’s authenticated ID

CSCE Farkas21 Aggressive Exchange Minimize number of exchanges Does not provide ID protection Protocol: 1. I  R : SA; KE; NONCE; ID I 2. R  I : SA; KE; NONCE; ID R ; AUTH 3. I  R : AUTH 1:I proposes an SA + begins key exchange + I’s ID. 2: R indicates acceptance of SA + completes key exchange + authentication 3: Authentication

CSCE Farkas22 Informational Exchange One-way transmittal of information for SA management Error or status notification – Invalid payload type, invalid protocol ID, payload malformed, authentication failed, invalid signature, etc. – Connected, responder-lifetime, replay status, initial contact Protocol 1. I  R : N/D

CSCE Farkas23 Next Class: Transport layer security