Internet Security CSCE 813 IPsec Reading l

Internet Security CSCE 813 IPsec

Reading l 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 CSCE 813 - Farkas 2

IPSec Overview l l l IPSec can be added to either IPv 4 or IPv 6 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 813 - Farkas 3

Internet Key Exchange

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

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 813 - Farkas 6

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

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

Diffie-Hellman Key Exchange Prior agreement of two parameters: g and p l A selects random integer a, B selects random integer b l Protocol l A ga mod p B gb mod p Alice, Bob compute gab mod p not known to anyone else CSCE 813 - Farkas 9

Problems with DH No information about identities l Subject to a man-in-the-middle type attack l Computationally extensive: vulnerable to a clogging attack l – 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 813 - Farkas 10

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) l Ensure that the responder is stateless until initiator produced at least 2 messages l – 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 813 - Farkas 11

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

Key Exchange Identities: not secret l Derived key: PFS l Two modes: – Main mode: 5 messages, protects IDs – Aggressive mode: 3 messages, does not protect IDs l Multiple variations, see The OAKLEY Key Determination Protocol, http: //tools. ietf. org/html/rfc 2412 l CSCE 813 - Farkas 13

Aggressive Oakley Example I R: CKYI , OK_KEYX , GRP , gx , EHAO , NIDP, IDI , IDR , NI , SKI[ IDI || IDR || NI || GRP || gx || EHAO] R I: CKYR , CKYI , OK_KEYX , GRP , gy , EHAS , NIDP, IDR , IDI , NR , NI , SKR[ IDR || IDI || NR || NI || GRP || gx || gy || EHAS] I R: CKYI , CKYR, OK_KEYX , GRP , gx , EHAS, NIDP , IDI , IDR , SKI[ IDI || IDR || NI || NR || GRP || gx || gy || EHAS] – – – – CKYI: I’s cookie OK_KEYX: key exchange message type GRP: DH group, gx, gy: public key of init. and resp. , gxy: 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, SKI[X] CSCE 813 - Farkas 14

ISAKMP l Defines procedures and packet formats to – Establish – Negotiate – Modify – Delete security associations CSCE 813 - Farkas 15

ISAKMP Header Format Initiator cookie ISAKMP header Responder cookie Next payload Mj ver Mn Ver Exchange type Flags Message ID Length Next payload Reserved Payload length payload CSCE 813 - Farkas Generic payload header 16

Payload Types l l l 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 813 - Farkas 17

Base Exchange l l 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; IDI; AUTH 4. R I : KE; IDR; AUTH 1 -2: cookies + SA establish; nonce: replay protection 3 -4: key materials and IDs CSCE 813 - Farkas 18

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

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

Aggressive Exchange l l l Minimize number of exchanges Does not provide ID protection Protocol: 1. 2. 3. I R : SA; KE; NONCE; IDI R I : SA; KE; NONCE; IDR; AUTH 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 813 - Farkas 21

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

Next Class: Transport layer security CSCE 813 - Farkas 23