ipsec and ike - university of cincinnatigauss.ececs.uc.edu/courses/c653/lectures/pdf/ipsec.pdf ·...

IPSec and IKE

IPSec and IKE

VPN:

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


But the OS needs to be modified

IPSec and IKE

TCP

IP

...

IPSec

Applications

OS

User



IPSec capable of authenticating but can only tell app the address of source

IPSec and IKE

TCP

IP

...

IPSec

Applications

OS

User



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


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


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):

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 (ESP):

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 IKETunnel Mode (AH):

IPSec and IKE

IPSec and IKETunnel Mode (ESP):

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


DiffieHellman Exchange

g mod p, IDC, crypto prop.

nonceC

a

IPSec and IKE

Client(K)

Server(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)


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


DiffieHellman Exchange

g mod p, IDC, crypto prop.

nonceC

a

IPSec and IKE

Client Server


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


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


crypto choose


IPSec and IKE

Client Server


DiffieHellman exchange

g a mod p, nonce

C

IPSec and IKE

Client Server



g b mod p, nonce

S

IPSec and IKE

Client Server

K = f(g mod p, nonceC, nonce

S)


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


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



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)


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


Shared Secret J

IPSec and IKE

Client Server


crypto choose


Shared Secret J

IPSec and IKE

Client Server


DiffieHellman

Shared Secret J

g mod p, nonceC

a

IPSec and IKE

Client Server


DiffieHellman

Shared Secret J

g mod p, nonceS

b

IPSec and IKE

Client Server


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


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


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

IPSec and IKEPayload, starting fields:

next type of payload(8 bits)

unusedlength of this payload

(8 bits)(16 bits)

IPSec and IKE

ipsec and ike - university of cincinnatigauss.ececs.uc.edu/courses/c653/lectures/pdf/ipsec.pdf ·...

Documents