IPSec and IKE - University of Cincinnatigauss.ececs.uc.edu/Courses/c653/lectures/PDF/ipsec.pdf ·...
Transcript of IPSec and IKE - University of Cincinnatigauss.ececs.uc.edu/Courses/c653/lectures/PDF/ipsec.pdf ·...
IPSec and IKE1. Standard for realtime communication security • confidentiality • message integrity2. Negotiate Security Associations (crypto protected conn) • cryptographic protocol • key size3. Other features • data compression, if any • type of error checking • how sender indicates it is finished sending • how the receiving device indicates it has received msg4. Establish and exchange session keys based on above5. Used to support virtual private networks
IPSec and IKE
IPSec and IKELayer 3.5 implementation: applications do not have to be changed to use it all applications automatically useit whether they like it or not.
IPSec and IKE
TCP
IP
...
IPSec
Applications
OS
User
IPSec and IKELayer 3.5 implementation: applications do not have to be changed to use it all applications automatically useit whether they like it or not.
But the OS needs to be modified
IPSec and IKE
TCP
IP
...
IPSec
Applications
OS
User
IPSec and IKELayer 3.5 implementation: applications do not have to be changed to use it all applications automatically useit whether they like it or not.
But the OS needs to be modified
IPSec capable of authenticating but can only tell app the address of source
IPSec and IKE
TCP
IP
...
IPSec
Applications
OS
User
IPSec and IKELayer 3.5 implementation: applications do not have to be changed to use it all applications automatically useit whether they like it or not.
But the OS needs to be modified
IPSec capable of authenticating but can only tell app the address of source
Operates like a firewall encrypts has policies authenticates address to app
IPSec and IKE
TCP
IP
...
IPSec
Applications
OS
User
IPSec and IKEPerfect Forward Secrecy: attacker cannot decrypt even ifthe entire session is recorded and attacker breaks into both partiesand finds their secrets (uses session keys).
IPSec and IKE
IPSec and IKEPerfect Forward Secrecy: attacker cannot decrypt even ifthe entire session is recorded and attacker breaks into both partiesand finds their secrets (uses session keys).
Denial of Service Protection: lock out with repeatedauthentication attempts. Uses cookies: unpredictablenumbers sent to IP address with expectation of return if no return then connection is stopped. Uses statelesscookies so that no one has to remember where the cookiescame from ( hash(IP address, some secret)).
IPSec and IKE
IPSec and IKEPerfect Forward Secrecy: attacker cannot decrypt even ifthe entire session is recorded and attacker breaks into both partiesand finds their secrets (uses session keys).
Denial of Service Protection: lock out with repeatedauthentication attempts. Uses cookies: unpredictablenumbers sent to IP address with expectation of return if no return then connection is stopped. Uses statelesscookies so that no one has to remember where the cookiescame from ( hash(IP address, some secret)).
Endpoint Identifier Hiding: prevent target node fromknowing the source of a packet. Uses DiffieHellman to get a key then authentication information is sent encrypted.
IPSec and IKE
IPSec and IKELive Partner Reassurance: prevent replay attacks. Canchange secret DiffieHellman a,b but that is expensive,alternative: use a nonce as part of the session key.
IPSec and IKE
IPSec and IKELive Partner Reassurance: prevent replay attacks. Canchange secret DiffieHellman a,b but that is expensive,alternative: use a nonce as part of the session key.
Data Stream Protection: individual packets are selfcontained so they can be encrypted and integrity protected independently. Decryption can easily be offloaded to other software or hardware.
IPSec and IKE
IPSec and IKESecurity Association: • A cryptographically protected connection • Each end has ≥ one key, sequence number, identity of other end • Each end has crypto services used: integrity only, encryption+integrity, crypto algorithms • Unidirectional two connections needed for 2way operation • Details of an SA are kept in a database • IPSec header has a Security Parameter Index (SPI) field that identifies the SA allowing the sender to look up necessary info in the sender's SA database. • SPI value is chosen by the receiver. • An SA is defined by an SPI and destination address (if receiver is involved in a multicast, it may not have chosen the SA – the destination address is a group address in the case of multicast)
IPSec and IKE
IPSec and IKESecurity Association Database: • Transmitter checks receiver's address to see how to transmit (database entry provides the SPI, key, crypto algorithms, etc.) • When receiving a packet, SPI of the packet is used to find the SA entry giving the receiver the key, sequence # etc.
IPSec and IKE
IPSec and IKESecurity Association Database: • Transmitter checks receiver's address to see how to transmit (database entry provides the SPI, key, crypto algorithms, etc.) • When receiving a packet, SPI of the packet is used to find the SA entry giving the receiver the key, sequence # etc.
Security Policy Database: • Which packets are to be dropped completely • Which should be forwarded or accepted without IPSec protection • Which should be forwarded or accepted with IPSec protection & which type of protection (encrypt, integrity) • Decisions based on ports, source addr, dest addr, protocol type or any other fields in the packet header.
IPSec and IKE
IPSec and IKEAuthentication Header (AH): • Message integrity protection only (Message Authentication) • IPSec computes a HMAC checksum over nearly all the fields of the IP packet, and stores it in a new AH header
• Can protect some IP header fields and all AH fields
IPSec and IKE
next header(8 bits)payload length (size of AH header)
unused(8 bits)
(16 bits)SPI (Security Parameter Index)(32 bits)
sequence number (detect replayed packet)(32 bits)authentication data (MD5 or SHA1 hash)(N32 bits)
... rest of packet ...
... IP header ...
IPSec and IKEAuthentication Header (AH):
next header(8 bits)payload length
unused(8 bits)
(16 bits)Security Parameter Index(32 bits)
sequence number(32 bits)authentication data
next header: same as protocol field in IPv4 – says IP layer is protectedpayload length: size of AH header in 32 bit chunks, not counting first 64sequence number: assigned by AH and used so that AH can recognizereplayed packets and discard them.
IPSec and IKE
(N32 bits)
IPSec and IKEAuthentication Header (AH):
next header(8 bits)payload length
unused(8 bits)
(16 bits)Security Parameter Index(32 bits)
sequence number(32 bits)authentication data
next header: same as protocol field in IPv4 – says IP layer is protectedpayload length: size of AH header in 32 bit chunks, not counting first 64sequence number: assigned by AH and used so that AH can recognizereplayed packets and discard them.
AH protects immutable and mutable but pedictable fields. For example,source computes AH knowing destination address even though nextaddress is address of next hop. All AH fields are protected.
IPSec and IKE
(N32 bits)
IPSec and IKEIPv4 Header:
version header length(4 bits) (4 bits)type of service (priority/quality)
length of header plus data in this fragment(8 bits)
(16 bits)packet id(16 bits) flags (3 bits)frag offset time to live (hops)(13 bits) (8 bits)protocol checksum (hdr only)
source addr dest addroptions
(8 bits) (16 bits)(32 bits) (32 bits)
IPSec and IKE
protocol: 0x32 = ESP 0x33 = AH
mutable fields: type of service, flags, frag offset, hops, checksummutable but predictable: dest addr
fields in yellow are integrity protected (included in hash)others are not
IPSec and IKEEncapsulating Security Payload (ESP): • Provides integrity and/or encryption • Only protects information after the IP header (HMAC for ESP header and payload) • Typical encryption algorithms used: DES, 3DES, Blowfish, AES
IPSec and IKE
IPSec and IKEEncapsulating Security Payload (ESP): • Provides integrity and/or encryption • Only protects information after the IP header (HMAC for ESP header and payload) • Typical encryption algorithms used: DES, 3DES, Blowfish, AES
There is nothing in the packet that says it's encrypted so firewalls may get stuck if they need to check ports, for example, because they cannot reliably get that info only the sender and receiver know whether the ESP packets are encrypted
IPSec and IKE
IPSec and IKEEncapsulating Security Payload header (ESP):
Security Parameter Index(32 bits)
padding
initialization vector(32 bits)
TCP header + payload (data)
sequence number
authentication data
sequence number: for detecting replay attacksinitialization vector: depends on the encryption scheme (CBC)padding: depends on the crypto algorithm used, allows block encryption algorithms room for multiples of their blocksizepadding length: size of the padding field
next header/protocol typepadding length
(8 bits)(8 bits)
IPSec and IKE
header
trailer
encryption
integrity
IPSec and IKETransport Mode: 1. IPSec info between IP header and rest of packet 2. Applied endtoend, authentication, encryption, or both
IP Header
IP Header
Rest of Packet
Rest of PacketIPSec
IPSec and IKE
IPSec and IKETransport Mode (AH): the IP header is modified only slightly after validation, the IPSec header is stripped away the original protocol field is restored in the IP header thus, the packet is restored to its original state and can be delivered
IPSec and IKE
IPSec and IKETransport Mode (AH): AH is incompatible with Network Address Translation (map range of private addresses to/from small set of public addresses) and Port Address Translation (map multiple private addresses to single external address, ports are assigned)
IPSec and IKE
IPSec and IKETransport Mode: 1. IPSec info between IP header and rest of packet 2. Applied endtoend, authentication, encryption, or both
Tunnel Mode: 1. Keep original IP packet intact, add new IP header and IPSec information (AH or ESP) 2. Firewalltofirewall, endtofirewall, encrypt header & payload
IP Header
IP Header
Rest of Packet
Rest of PacketIPSec
IP Header
IP Header
Rest of Packet
Rest of PacketIPSecNew IP Header
IPSec and IKE
IPSec and IKEAH vs. ESP AH does not support NAT or PAT
AH does not encrypt hence port information at level 4 is available to firewalls for screening, filtering, etc. ESP may be used in integrityonly mode but only the endpoints know whether encryption was used so intermediate firewalls cannot know the port information reliably (SAs are unknown to them) However, people object to firewalls needing to use port information AH integrity protects IP header fields but this could be accomplished by ESP in tunnel mode AHonly might be approved for export more readily but vendors have been able to export ESPbased IPSec systems Ipv6 proponents see AH as a way to force/encourage people to adopt Ipv6 IPSec is a mandatory feature of Ipv6
IPSec and IKE
IPSec and IKEAH vs. ESP The authentication data in AH appears before the data it authenticates The authentication data in ESP appears after the data it authenticates
Hence, in AH, the data must be buffered to allow the HMAC to be computed and added to the AH header.
But, AH packets tend to be smaller (vs. ESP in integrityonly mode) because there is no need to pad.
IPSec and IKE
IPSec and IKEAH vs. ESP International Engineering Task Force meeting held just before AH and ESP were finalized:
Microsoft rep: “AH is useless given the existence of ESP, cluttered up the spec, and couldn't be implemented efficiently because the HMAC is in front of the data it authenticates.”
IPSec and IKE
Network Security: Private Communication is a Public World, 2nd Ed., Kaufman, Perlman, Speciner Page 438
IPSec and IKEAH vs. ESP International Engineering Task Force meeting held just before AH and ESP were finalized:
Microsoft rep: “AH is useless given the existence of ESP, cluttered up the spec, and couldn't be implemented efficiently because the HMAC is in front of the data it authenticates.”
Then everyone in the room looked around at each other and thought:
Hmmm...he's right, and we hate AH, but if it annoys Microsoft let's leave it in since we hate Microsoft more than we hate AH
IPSec and IKE
Network Security: Private Communication is a Public World, 2nd Ed., Kaufman, Perlman, Speciner Page 438
IPSec and IKEFirewalls IETF people do not like firewalls because they can make it difficult to deploy new applications and they may break some existing applications.
Argue against firewalls: security is strongest if it is endtoend
IPSec encrypts information that SysAdmins would like to use to filter packets, determine whether data is email or telnet, etc.
But IPSec has not encouraged the disappearance of firewalls and reliance on firewalls has not encouraged the disuse of IPSec Maybe there should be more cooperation between protocol designers and SysAdmins?
Aside: attackers can spoof protocols anyway, so are firewalls really that secure?
IPSec and IKE
IPSec and IKEInternet Key Exchange: Protocol for doing mutual authentication and establishing a shared secret key to create an IPSec SA.
Uses: long term keys (public signatureonly keys, preshared secret keys, public encryption keys)
Pieces: ISAKMP (Internet Security Association and Key Management Protocol) framework (OAKLEY implementation) IKE (Internet Key Exchange) defines fields, chooses options of ISAKMP DOI (Domain of Interpretation) specifies particular use of ISAKMP
IPSec and IKE
IPSec and IKEInternet Key Exchange Phases:
Phase 1: Does mutual authentication and establishes session keys based on identities such as names, and secrets Phase 2: SAs are established between two entities
Reason for two phases: Different SAs may be established for different traffic flows. There might be security weaknesses if two different flows used the same key. Phase 1 need be done once, phase 2 uses the same phase 1 session key to generate multiple SAs. Phase 1 relies on (slower) publickey cryptography, phase 2 relies on (faster) secret keys – hence sessionkeys are made quickly
IPSec and IKE
IPSec and IKEPossible Security Problem: (encryption w/o integrity)
C can decrypt packet sent by A to B • Record packet from A to B and packet from C to D • Splice encrypted part with srcdst from C to D onto A to B packet • Forward packet to Firewall 2, Firewall decrypts, sends result to D
Firewall 1(encrypts)
Firewall 2(decrypts)
A C B D
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server share a secret K
Client(K)
Server(K)
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server share a secret K
DiffieHellman Exchange
g mod p, IDC, crypto prop.
nonceC
a
IPSec and IKE
Client(K)
Server(K)
IPSec and IKEInternet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server share a secret K
DiffieHellman Exchangeproof (Server) might be hash of K and nonce
C
g mod p, IDS, cypto choice
proof(Server), nonceS
b
IPSec and IKE
Client(K)
Server(K)
IPSec and IKEInternet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server share a secret K
proof(Client)
IPSec and IKE
Client(K)
Server(K)
DiffieHellman Exchangeproof (Client) might be hash of K and nonce
S
IPSec and IKEInternet Key Exchange Phase 1: Aggressive Mode Problems:
1. Someone other than Server can send a refusal back to Client and Client cannot tell if it is fake (such a message should be sent encrypted).
2. Identities of the client and server are revealed
3. Reflection attack avoided by making sure Server does not accept its nonce from Client in second exchange
4. Replay avoided due to the use of a nonce both ways Allows using the same a and b exponents for many exchanges as nonces are included in the key computation
5. Man in the middle avoided due to mutual authentication
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server do not share a secret
Client Server
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server do not share a secret
DiffieHellman Exchange
g mod p, IDC, crypto prop.
nonceC
a
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server do not share a secret
DiffieHellman ExchangeCertificate
S proves identity of Server to Client (sign nonce
C?)
g mod p, IDS, cypto choice
CertificateS, nonce
S
b
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Aggressive Mode: Accomplishes mutual authentication in three messages – Client and Server do not share a secret
CertificateC
IPSec and IKE
Client Server
DiffieHellman ExchangeCertificate
C proves identity of Client to Server (sign nonce
S?)
IPSec and IKEInternet Key Exchange Phase 1: Main Mode: Accomplishes mutual authentication in six msgs. Includes ability to hide endpoint identifiers from eavesdroppers and flexibility in negotiating crypto algorithms
crypto proposal
Parameter negotiation
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Main Mode: Accomplishes mutual authentication in six msgs. Includes ability to hide endpoint identifiers from eavesdroppers and flexibility in negotiating crypto algorithms
crypto choose
Parameter negotiation
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Main Mode: Accomplishes mutual authentication in six msgs. Includes ability to hide endpoint identifiers from eavesdroppers and flexibility in negotiating crypto algorithms
DiffieHellman exchange
g a mod p, nonce
C
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Main Mode: Accomplishes mutual authentication in six msgs. Includes ability to hide endpoint identifiers from eavesdroppers and flexibility in negotiating crypto algorithms
DiffieHellman exchange
g b mod p, nonce
S
IPSec and IKE
Client Server
K = f(g mod p, nonceC, nonce
S)
IPSec and IKEInternet Key Exchange Phase 1: Main Mode: Accomplishes mutual authentication in six msgs. Includes ability to hide endpoint identifiers from eavesdroppers and flexibility in negotiating crypto algorithms
authenticate, encryptednonces allow same DiffieHellman private value for many transactionsproof of ID: signature on a hash of ID, DH values, nonces, crypto choices
K{ID, proof of ID,[cert]}
ab
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Main Mode: Accomplishes mutual authentication in six msgs. Includes ability to hide endpoint identifiers from eavesdroppers and flexibility in negotiating crypto algorithms
authenticate, encrypted
K{ID, proof of ID,[cert]}
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Proof of Identity: Some hash of the key associated with the identity, the DiffieHellman values, nonces, cryptographic choices, and cookies.
Problem: choice of cryptographic suite by server is not encrypted. A maninthemiddle might actually replace a good choice with a poor (crackable) choice then decrypt and impersonate server from then on.
Stateless cookies? No, must remember crypto proposals they are included in the hash used in the proof of identity sender could repeat this info later in the handshake, but IPSec does not allow this
Duplicate connection identifiers? Possible to have two connections with the same crypto parameters
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 1: Regarding key types: Phase 1 might be based on a publickey pair for encryption, publickey pair for signing, or preshared secret.
A more recent possibility is encrypting a randomly chosen secret key with the other side's public key and using that to encrypt all remaining fields.
Hence there are 8 choices for Phase 1 handshakes: 4 authentication methods (main + aggressive modes)
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 1: Crypto Parameters: 1. Encryption algorithm (DES, 3DES, IDEA) 2. Hash algorithm (MD5, SHA) 3. Authentication method (RSA signature, DSS...) 4. DiffieHellman group ((g,p), elliptic curves)
Any combination is allowed – could result in more than 100 crypto suite choices in the proposal.
Optionally, an expiration time/date can be specified in the proposal
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 1: Certificates: Client or Server can ask the other side for a certificate.
If they do not know the other side's public key they cannot use the protocol.
If certificates are sent in first two messages then identities are revealed.
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 1: Main Mode Revised: requires a single private key operation on either side.
crypto proposal
Parameter negotiationStarts out as before
IPSec and IKE
Client Server
Internet Key Exchange Phase 1: Main Mode Revised:
crypto choose
Parameter negotiationNo change yet
IPSec and IKEIPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Main Mode Revised:
Cookie: a fast hash over the IP source and destination addresses, the UDP source and destination ports, random number Stateless: if a secret is used in place of the random number
DiffieHellman exchangeServer uses private key to decrypt nonce
C then determines K1
then decrypts ID, and everything else
K1{g mod p},K1{ID}, K1{[certificate]},ServerPublicKey{nonce
C}
a
K1 = hash(nonceC, cookie
C)
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Main Mode Revised:
DiffieHellman exchange
K2 = hash(nonceS , cookie
S)
K2{g mod p},K2{ID},ClientPublicKey{nonce
S}
b
IPSec and IKE
Client Server
K = f(gab mod p, nonces, cookies)
IPSec and IKEInternet Key Exchange Phase 1: Main Mode Revised:
authenticate, encrypted
K{proof of ID}
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Shared Secret Main Mode: Only required protocol. Requires Client and Server to already share a secret intended for laptops trying to get into a firewall at work while on the road?
crypto proposal
Parameter negotiation
Shared Secret J
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Shared Secret Main Mode: Only required protocol. Requires Client and Server to already share a secret intended for laptops trying to get into a firewall at work while on the road?
crypto choose
Parameter negotiation
Shared Secret J
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Shared Secret Main Mode: Only required protocol. Requires Client and Server to already share a secret intended for laptops trying to get into a firewall at work while on the road?
DiffieHellman
Shared Secret J
g mod p, nonceC
a
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Shared Secret Main Mode: Only required protocol. Requires Client and Server to already share a secret intended for laptops trying to get into a firewall at work while on the road?
DiffieHellman
Shared Secret J
g mod p, nonceS
b
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Shared Secret Main Mode: Only required protocol. Requires Client and Server to already share a secret intended for laptops trying to get into a firewall at work while on the road?
authentication
Shared Secret J
K=f(J,g mod p, nons, coks)ab
K{ID, proof(ID)}
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Shared Secret Main Mode: Only required protocol. Requires Client and Server to already share a secret intended for laptops trying to get into a firewall at work while on the road?
authentication
Shared Secret J
K=f(J,g mod p, nons, coks)ab
K{ID, proof(ID)}
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 1: Problems: 1. Identities must be IP addresses so cannot seriously be used in road warrior application
2. Client sends identity in message 5 encrypted with key K which is a function of shared secret J. Server cannot decrypt that message to find out who the Client is unless it knows J. But that means Server must know who the Client is in the first place! This is why identities are IP addresses.
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 1: Problems: 1. Identities must be IP addresses so cannot seriously be used in road warrior application
2. Client sends identity in message 5 encrypted with key K which is a function of shared secret J. Server cannot decrypt that message to find out who the Client is unless it knows J. But that means Server must know who the Client is in the first place! This is why identities are IP addresses.
Fix: Do not make K a function of J. OK since J is included in the hash which is proof of identity.
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 1: Negotiating Cryptographic Parameters: encryption algorithm: DES, 3DES, IDEA hash: MD5, SHA authentication method: presharedkeys, RSA signing, RSA encryption, DSS DiffieHellman type: p,g
Session Keys: Two established: integrity, encryption for protecting the last phase 1 transaction (both directions) and all the phase 2 transactions
Keys are: hashes of DiffieHellman values, nonces, cookies,..
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 2: Setting up IPSec SAs: All messages are encrypted with Phase 1 SA's encryption key K1 and integrity protected with phase 1 SA's integrity key K2.
Phase 1 SA
X, Y, CP, traffic, SPI1,nonce
C, [ga mod p]
X is a pair of cookies from phase 1Y is a 32 bit number chosen to distinguish this setup from others that may be setup simultaneously in phase 1.X and Y are unencrypted. (vulnerable to replay)
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 2: Setting up IPSec SAs: All messages are encrypted with Phase 1 SA's encryption key K1 and integrity protected with phase 1 SA's integrity key K2.
Phase 1 SA
X, Y, CP, traffic, SPI1,nonce
C, [ga mod p]
Rest of message: authenticator using K2, crypto parameters,optional DiffieHellman values, optionally a description of traffic.
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 2: Setting up IPSec SAs: All messages are encrypted with Phase 1 SA's encryption key K1 and integrity protected with phase 1 SA's integrity key K2.
Phase 1 SA
Encryption: Initialization vector is the final ciphertext block oflast message of phase 1 hashed with Y.
IPSec and IKE
Client ServerX, Y, CP, traffic, SPI1,
nonceC, [ga mod p]
IPSec and IKEInternet Key Exchange Phase 2: Setting up IPSec SAs:
Phase 1 SA
X, Y, CPA, traffic, SPI2,nonce
S, [gb mod p]
Encryption: Initialization vector is the final ciphertext block oflast message of previous phase 2 message hashed with Y.
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 2: Setting up IPSec SAs:
Phase 1 SA
X, Y, ack
Encryption: Initialization vector is the final ciphertext block oflast message of previous phase 2 message hashed with Y.
IPSec and IKE
Client Server
IPSec and IKEInternet Key Exchange Phase 2: Problems: 1. It is vulnerable to replay: a. Since Y is "random" instead of based on a sequence #, to detect a replay attack one must remember all Y's generated. b. Headers and session keys are the same in both directions so attacker can replay easily. 2. Vulnerable to reflection attack.
IPSec and IKE
IPSec and IKEInternet Key Exchange Phase 2: Problems: 1. It is vulnerable to replay: a. Since Y is "random" instead of based on a sequence #, to detect a replay attack one must remember all Y's generated. b. Headers and session keys are the same in both directions so attacker can replay easily. 2. Vulnerable to reflection attack.
Fix: Use different keys in different directions or by reversing the order of the cookies so the recipient's cookie appears first. Use sequence numbers instead of message IDs.
IPSec and IKE
IPSec and IKEISAKMP/IKE Encoding: Messages have a fixed header followed by a sequence of payloads. Each payload starts with "type of next payload" and "length of this payload".
Payload types: end, SA, proposed SPI, crypto choices, DiffieHellman values, certificate, certificate request, hash (checksum), signature, nonce, notification, delete, vendor ID.
IPSec and IKE
IPSec and IKEFixed Header:
initiator's cookie(64 bits)responder's cookienext payload type
(64 bits)(8 bits)
exchange type(32 bits)message ID(80 bits)
message lengthflags
(64 bits)
version
exchange type: base adds extra message to aggresive mode, allows DH negot. identity protection (main mode) authentication only (not used by IKE) aggressive informationalflags: encrypted, commit, authentication only (set only during phase 2),messageID: differentiates messages with same phase 1 SA
IPSec and IKE