Internet Security Internet Security CSCE 813CSCE 813
IPsecIPsec
CSCE 813 - Farkas 2
ReadingReading
Today: – Oppliger: IPSec: Chapter 14– Stalllings: Network Security Essentials, 3rd
edition, Chapter 6Related readings (not required)– IPSec Architecture RFC 2401– ISAKMP RFC 2408– IKE RFC 2409– HMAC RFC 2104
IPSec OverviewIPSec 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 813 - Farkas 3
Internet Key ExchangeInternet Key Exchange
CSCE 813 - Farkas 5
IKEIKE 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 813 - Farkas 6
PropertiesProperties
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 7
Key Management in Key Management in IPSecIPSec
Manual key managementSystem 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 813 - Farkas 8
Internet Key ExchangeInternet 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 813 - Farkas 9
Diffie-Hellman Key ExchangeDiffie-Hellman Key Exchange
Prior agreement of two parameters: g and p A selects random integer a, B selects random integer b Protocol
ga mod p
gb mod p
A B
Alice, Bob compute gab mod p not known to anyone else
CSCE 813 - Farkas 10
Problems with DHProblems 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 813 - Farkas 11
Added Security Added Security Features of OakleyFeatures 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 813 - Farkas 12
Added Security Features of Added Security Features of OakleyOakley
Nonces: detect replay attacksAuthenticates 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 ExchangeKey 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, http://tools.ietf.org/html/rfc2412
CSCE 813 - Farkas 13
CSCE 813 - Farkas 14
Aggressive Oakley Aggressive Oakley ExampleExample
– 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]
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]
CSCE 813 - Farkas 15
ISAKMP ISAKMP
Defines procedures and packet formats to– Establish – Negotiate– Modify– Delete
security associations
CSCE 813 - Farkas 16
ISAKMP Header FormatISAKMP Header Format
Nextpayload
Mjver
MnVer
Exchangetype
Flags
Message ID
Length
Initiator cookie
Responder cookie
Nextpayload
Reserved Payload length
payload
ISAKMP header
Generic payload header
CSCE 813 - Farkas 17
Payload TypesPayload 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 813 - Farkas 18
Base ExchangeBase 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; 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 19
Identity Protection ExchangeIdentity Protection Exchange
Expands the Base exchange to protect user IDs. Protocol:
1. I R : SA2. R I : SA3. I R : KE; NONCE4. R I : KE; NONCE5. I R : IDI; AUTH6. R I : IDR; AUTH
1-2: establish SA3-4: key exchange + replay protection5-6: authentication + optional certificate
CSCE 813 - Farkas 20
Authentication Only Authentication Only ExchangeExchange
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 21
Aggressive ExchangeAggressive Exchange
Minimize number of exchanges Does not provide ID protection Protocol:
1. I R : SA; KE; NONCE; IDI
2. R I : SA; KE; NONCE; IDR; AUTH3. I R : AUTH
1:I proposes an SA + begins key exchange + I’s ID. 2: R indicates acceptance of SA + completes key exchange + authentication3: Authentication
CSCE 813 - Farkas 22
Informational Informational ExchangeExchange
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 813 - Farkas 23
Next Class: Next Class:
Transport layer securityTransport layer security