coen 350 ipsec, ssl, ssh,. communication security decision: what layer? implemented at application...

COEN 350

IPSec, SSL, SSH,

Communication Security

Decision: What Layer? Implemented at application level

Application change OS does not change

Implemented at TCP/IP level OS changes Applications do not change

Communication Security Session Key Establishment

Threat: Session Hijacking Counter-measure: Encryption

Use Session key for each session Session key needs to be unpredictable

Implementation of SSL used time, process id, parent process id to concoct session key

Attacker could narrow search space to about 30b of key.

Both partners should contribute to session key Threat: Packet replay

Counter-measure: Sequence number

Communication Security Perfect Forward Security

Threat: Eavesdropper captures traffic. Eavesdropper later acquires master key for both

communicants. PFS: Eavesdropper can still not encrypt data.

Diffie Hellman key exchange provides PFS Counter-example:

Encrypting all messages with a public key of partner

Kerberos Session key is inside ticket, encrypted with

long-term secret key Sending session key encrypted with public key

Communication Security

Escrow-foilage Alice and Bob have to give their

private keys to an escrow agency. Passive listener with those keys can

still not decrypt traffic between Alice and Bob

Communication Security Denial of Service

Protections Cookies:

Server can generate random looking cookies.

Server can quickly verify that something is a cookie.

Server hands out cookies to requestors.

Requestors need to pass cookie along with all traffic.

Communication Security

Denial of Service Attack Protection Puzzles

Server creates puzzles Client needs to solve puzzle in order to

get work done. Client does more work than server DOS

attack is harder

Communication Security Replay prevention

Use session keys Session Resumption

Goal is avoiding costly initial encryption exchange

Lotus Notes: Server has secret that changes once a month. Server sends hash(client-name, server-secret)

to client after authentication. Session key is calculated from this hash plus

nonces.

Communication Security

Negotiation of crypto-parameters Systems evolve:

Crypto-systems become breakable Newer crypto-systems demand larger

resources. Potential Security Flaw

Negotiating in bad faith, insisting on breakable crypto-suites.

Communication Security

Endpoint identifier hiding Establish secure tunnel (via Diffie

Hellman) first. Then authenticate. Man-in-the-middle gets caught in the

second step. Can only find out one identity.

IPSec

RFC 1636 identified key areas where the internet needs to be made more secure. Spoofing: Creating packets with false

addresses. Eavesdropping / packet sniffing. True for both IPv4 and IPv6.

IPSec

Implemented below the transport layer.

No application needs to be rewritten.

Is part of the OS.Applications

TCP

IPsec

IP

lower layers

IPSec

Provides confidentiality for IP connections

Allows implementation of access policies

Authenticates source IP addresses But not users.

IPSec Transport Mode

Adds IPSec information between IP Header and remainder of packet.

Tunnel Mode Encapsulates the original IP header and packet. Adds new IP header and IPSec header

IP Header IPSec Header IP Header Secure IP Payload

IP Header IPSec Header IP-payload: Old rest of packet

IPSec An IPSec packet in tunnel mode

completely encapsulates the payload. IP Header is either an

AH: Authentication Header ESP: Encapsulating Security Payload that tells

the user which Security Association to use.

IP Header IPSec header Secure IP Payload

IPSec

Developed by the Internet Engineering Task Force IETF

Architecture ESP (Encapsulating Security Payload) AH (Authentication Header) Encryption Algorithm Authentication Algorithm Key Management DOI (Domain of Interpretation) (How to fit the

work together.)

IPSec Security Association

Cryptographically protected connection. Paradigm to manage authentication and

confidentiality between sender and receiver. Unidirectional. IPSec header contains SPI (Security

Parameter Index) that identifies the security association.

Allows partner to look up the necessary data such as the key in SA database.

IPSec Security Association Database

When X transmits to Y in IPSec, X looks up Y in the SA database.

Provides key Provides SPI

Security Parameter Index Provides algorithms to be used Provides sequence number

When Y receives a transmission, Y uses the SPI and the destination address to find the SA.

IPSec

Security Policy Database Specifies what to do with packets:

Dropping Forwarded and accepted without IPSec

protection Forwarded and protected by IPSec

Decision based on fields in the IPsec packet.

IPSec Two types of IPsec headers. AH

Authentication header. Provides integrity protection only. Allows firewalls to peek at TCP ports.

ESP Encapsulating Security Payload

Optional integrity protection Optional encryption

IPSec

Two modes Transport mode

Adding IPsec information between IP header and remainder of package.

Tunnel mode Keeps the original IP packet intact,

but put it into a new packet with new IP header and IPsec data.

IPSec Transport mode

versus Tunnel mode

Original Packet IPsec Package in Transport Mode

IPSec Package in Tunnel Mode

IP header | rest IP header | IPsec header | rest new IP hdr | IPSec | IP header | rest

IPSec

IPsec in tunnel mode for a VPN:

IP: src=R1, dst=R2 | ESP | IP: src=A, dst=B | packet

IPSec NAT

Network address translation NAT boxes takes IP traffic from the

outside. Based on port number, repackages

packet to be send to an internal address and vice versa.

Allows organization to make to do with few IP addresses.

IPSec

NAT Have difficulties with incoming calls to

dynamic hosts. Need to maintain routing table

dynamically. Usually, need to be application-aware.

Function as a limited, package-based firewall.

IPSec NAT

Have difficulties with programs like FTP. FTP uses normally two channels: command

channel and data channel. Client opens command channel.

Packet to port 21, informs server of port on which it is listening.

Server responds by opening a data channel from port 20 to the client’s listening port.

PASV mode: Client sends PASV command to server. Server starts to listen on random port, gives port to

client in respond to PASV. Client opens data channel to the new port.

IPSec AH Header

Next header: position of protocol field of encapsulated package

Payload length: Size of AH header in words. SPI (Security Parameter Index) Sequence number: Used by AH to recognize replayed

packages. Not identical with TCP package number. Authentication data: Cryptographic integrity check on

the payload data.

1B 1B 2B 4B 4B variable

Next header

Payload length

Unused SPI Sequence Number

Authentication data

IPSec AH

Some IP header fields get reset by NATs and routers.

Mutable fields are not covered by the integrity check and can be changed by routers:

Type of service Flags Fragment offset Time to live Header checksum

Immutable fields cannot be changed: Payload length

Needed to reassemble fragmented AH packets.

IPSec AH

Immutable fields Destination address is protected by AH. NAT will change the destination address.

Hence, IPSec /AH and NAT do not work well together.

There is no way to predict the change at the source.

In source routing, routers change the destination address to the next field specified by source routing.

AH can predict the destination address. An example of a mutable, but predictable field.

IPSec ESP (Encapsulating Security Payload)

SPI Sequence Number (same as for AH) IV Initialization Vector (used by some cryptographic

algorithms Data: protected data, possibly encrypted Padding: needed to make data multiple of block size. Padding length Next header: Protocol field in IPv4 or next header in IPv6 Authentication data: Cryptographic integrity check.

4 4 var. var. var. 1 1 var.

SPI Sequence

number

IV data padding padding length

Next header / protocol

type

Authentication data

IPSec AH protects the IP header itself. ESP protects everything beyond the

ESP header. Hence: AH provides additional (but

useless?) protection. AH is less likely to fall under export

restrictions.

IPSec TF-ESP (Transport-friendly ESP)

Proposal to copy fields of interest of the original header in clear.

Firewalls and routers can look at these information.

Potential for information leak. Firewalls should not look at any data above

layer 3. But of course, they now do.

IPSec protection is end-to-end, and intermediate routers / firewalls cannot trust the cleartext copies of these fields.

IPSec: IKE

Internet Key Exchange Needed for

mutual authentication to set up an SA …

Compromise based on Photuris and Skip

Photuris Uses Cookies

Different from web browser cookies. When Alice connects to Bob, Bob chooses a

cookie and sends it to Alice. Bob only honors further requests from Alice

with the cookie. Foils very simple DoS attacks. To keep cookie stateless, the cookie is a

function of Alice’s address and a secret known by Bob only.

PhoturisA

lice

Bob

CA

CA, CB, crypto

CA, CB, gb mod p, crypto selected

CA, CB, gb mod p

CA, CB, {Alice, sig of prev. message} gab mod p

CA, CB, {Bob, sig of prev. message} gab mod p

Photuris

Alice chooses cookie CA in order to keep different login attempts separated.

Bob uses a stateless cookie CB in order to keep DoD attacks at bay.

Messages 3 and 4 consists of a Diffie-Hellman encryption.

Messages 5 and 6 serve for authentication. Encrypted with Diffie-Hellman key.

PhoturisA

lice

Bob

CA

CA, CB, crypto

CA, CB, gb mod p, crypto selected

CA, CB, gb mod p

CA, CB, {Alice, sig of prev. message}[gab mod p]

CA, CB, {Bob, sig of prev. message}[gab mod p]

SKIP Simple Key Management for Internet

Protocols Principals have

Certified Diffie-Hellman public keys ga mod p Long-time use

Private key a. Alice wants to talk to Bob:

Alice takes Bob’s public key gb and raises it to the ath power.

Bob takes Alice’s public key ga and raises it to the bth power.

Both share the secret gab mod p.

SKIP

SKIP derives a key KAlice,Bob from the mutually shared secret between Alice and Bob. Such as the lower bits of gab mod p.

Each packet is encrypted / authenticated with a randomly generated key Kpacket.

The key Kpacket is encrypted with KAlice, Bob and added to the packet.

The header of the packet is in clear text.

SKIP SKIP packet

Clear IP Header KAlice,Bob{Kpacket} Kpacket{payload}

SKIP

Changing a principal’s key is a difficult, but needed operation. Minimizes exposure of the key and

makes crypt-analysis more difficult. Updating the master key prevents

reusing compromised traffic keys. Each new key needs to be certified.

SKIP

Make the master key KAlice,Bob dependent on a version that automatically updates:KAlice,Bob = hash(gab,counter-value) Allows still principals to get a brand-

new certified key. Prevents some replay attacks.

IPSec: IKE Phases

Phase 1: Does mutual authentication and establishes session

keys. Known as KSAKMP SA / IKE SA

Phase 2: Establishes an ESP or AH SA

Phase 1 is necessarily expensive. The two phases try to have phase 2 profit

from a phase 1 interchange used for another protocol, connection, …

IPSec: IKE

Phase 1 IKE: Aggressive mode

Use a single crypto-proposal Main mode

Negotiate the strongest crypto-proposal that both parties can agree to.

IPSec: IKE

Phase 1 Aggressive Mode:

AliceBob

ga, Alice, crypto-proposal

gb, crypto-choice, Proof that I’m Bob.

Proof that I’m Alice

IPSec: IKE Phase 1 Main Mode:

Alice

Bob

crypto-suites I support

Crypto suites I choose.

ga

gb

gab{Alice, Proof that I’m Alice}

gab{Bob, Proof that I’m Bob}

IPSec: IKE

Key Types Pre-shared secret Public key for encryption / decryption Public key for signing

8 variants of Phase 1!!!

IPSec: IKE

Phase 1 establishes two session keys: Integrity key Encryption key for the last exchange

in phase 1 and all exchanges in phase 2.

Establishes a pair of cookies to keep different sessions different.

IPSec: IKE

Phase 1 protocols Read them!

IPSec: IKE Phase 2: A.k.a. quick mode.

Uses a pair X of cookies generated in phase 1.

Session nonce for phase 2 session. All messages are encrypted with Phase 1

encryption key SKEYID_e All messages are integrity protected with

Phase 1 intergrity key SKEYID_a. Can be initiated by either participant of

Phase 1.

IPSec: IKE

Alice BobX,Y, Crypto-protocol, SPIA, nonceA,

SPI: Security Parameter Index

X,Y, Crypto-protocol accepted, SPIB, nonceB

X, Y Ack

IP SEC Resumen

Transport Mode IPSec protects the message passed

down from the message layer by adding AH or ESP header.

Tunnel Mode IPSec completely encapsulates IP

datagram.

IP SEC Resumen

Security Policy Rule programmed into IPSec

Implementation. Tells implementation how to process

particular packets.

Security Policy Database: Stores security policies.

IP SEC Resumen Security Association

Set of security information regarding a particular connection between two devices.

Security Association Database Database containing security associations of

a specific device. Selectors

Set of rules for choosing datagrams that a SA applies to.

IP SEC Resumen

Security Association Triples Define an SA:

Security Parameter Index (SPI) 32 b number placed in AH or ESP

IP destination address Security Protocol Identifier

Specifies whether this association is AH or ESP

IP SEC Resumen

IPv4 AH Datagram Format

IPSec Transport Mode

IP SEC Resumen

IPv4 AH datagram IPSec Tunnel Mode

IP SEC Resumen

IKE overview: Blend of Internet Security and Key

Management Protocol (ISAKMP) Oakley key exchange SKEME key exchange

IP SEC Resumen

IKE phases Phase 1: Mutual Authentication and

establishment of session keys. AKA: ISAKMP SA, IKE SA

Phase 2: Multiple SAs based on phase 1

IP SEC Resumen IKE Phase 1

Aggressive mode Diffie-Hellman exchange plus mutual

authentication 3 messages

Main mode crypto suite choosing Diffie Hellman Authentication protected by Diffie

Hellman

IP SEC Resumen

IKE Phase 2 (Quick Mode) Assumes a phase 1 SA

IP SEC Resumen

Secure Socket Layer 1995: deployed in Netscape Navigator

as SSLv2. 1995: Microsoft fixes SSLv2 and

introduces a similar protocol Private Communication Technology (PCT)

1996: Netscape introduces SSLv3 1999: IETF introduces Transport Layer

Security.

SSLv3 remains the most implemented protocol.

Secure Socket Layer SSL is built on top of TCP.

TCP provides reliable packet delivery. Rogue packet problem:

Maliciously introduced TCP packet. Easy to do, since it only needs to satisfy the

non-cryptographic TCP checksum. SSL disregards the package. TCP however will not accept the true

packet, because it looks like a double to it. SSL will have to start over.

Secure Socket Layer

Various keys are formed from various random numbers exchanged during the protocol.

Negotiate crypto-protocols.

Secure Socket Layer

SSL sessions are long-lived. Many SSL connections can be

derived from an SSL session.

Secure Socket Layer:Session Connection

Alice BobHello. Ciphers I support. RAlice

Certificate. Ciphers I choose. RBob

{S}Public Key of Bob. {Keyed Hash of Messages}

{Keyed Hash of Messages}

S is a random number, the pre-master secret. Chosen by Alice.

K is the master secret, calculated from RAlice, RBob, S

Bob has authenticated himself to Alice, but not vice versa!

Alice specifies lists of ciphers and a random

number

Bob gives certificate of his public key. Bob

picks cipher.

Alice calculates the pre-master secret and sends it to Bob, protected by Bob’s public key. She also creates a (complicated) hash of the hand-shake message. She also calculates a session key K

Bob responds with his version of the hash of the session key.

Secure Socket Layer:Session Resumption If Bob wants to have multiple connections

per session, he sends in Message 2 a session id.

If Alice presents in Message 1 a session id, they skip the handshake.

Alice can still negotiate ciphers with Bob who might have changed policies.

Alice BobSession ID. Ciphers I support. RAliceSession ID. Certificate. Ciphers I choose.

RBob

{Keyed Hash of Messages}

Secure Socket Layer:Session Resumption

Session resumption is not stateless.

Server Bob needs to maintain a database entry of session id and master secret.

Secure Socket Layer

SSL comes deployed with public keys of various trusted organizations.

User can modify this list. User verifies public keys by

sending certificate requests to the organizations in the list.

Secure Socket Layer

SSLv3 upgrades: Protects against the “downgrade attack”

Active attacker replaces the initial messages with ones containing weak crypto.

Protects against the “truncation attack” Active attacker sends a TCP close (FIN)

message. TCP is not protected, so the connection is abnormally

terminated without SSL being aware of it.

Secure Shell: SSH

SSH client and server are applications (running on top of OS).

SSH consists of a bunch of applications.

But SSH is not a UNIX shell.

Secure Shell: SSH

Provides Authentication Encryption Integrity

Secure Shell: SSH SSH provides

scp: secure file transfer Secure remote command execution Automatic authentication:

Place public key files on remote computers Enable SSH clients (scp, ssh) to access remote

accounts Invoke ssh-agent program Choose keys needed for remote logins. Load private keys with ssh-add (invoking passphrase) ssh-agent keeps private keys in memory.

Delegate limited authentication. Secretary can only read the email.

Port forwarding

Secure Shell: SSH1 Client contacts server.

By going to port 22 by convention. Client and server disclose the SSH versions

they support. Client and server switch to a packet based

protocol. Packet consists of

4B length, 1-8B of random padding, one-byte packet type code, packet payload data, four-byte integrity check field.

Secure Shell: SSH1 Server identifies itself by sending

Host key Server key 8 random bytes (use as cookie) List of encryption, compression,

authentication methods. Both sides compute a 128b session

identifier.

Secure Shell: SSH When the client receives the host key, the

client looks into the known host database.

If the host key matches the one in the database then the client proceeds.

If the host is in the database but with a different key, then the client queries the user.

Otherwise, the client warns the user and proposes to add host and key to the known host database.

Secure Shell: SSH Client randomly generates a session key.

Clients sends the session key encrypted with the server key and then with the host’s public key.

Together with the choice of crypto-suites. Both sides now use the session key for

encryption. Server sends confirmation message encrypted

with the session key. This proves the server’s authenticity to the

client.

Secure Shell: SSH

Authentication phase starts: SSH1 tries out

Kerberos Rhosts RhostsRSA Public key TIS Password

Secure Shell: SSH

At this point, a secure communication channel has been established.

Client is sure of the authenticity of server.

Server now authenticates the client.

Secure Shell: SSH SSH2 changes:

SSH2 consists of modules: SSH Transport layer protocol SSH Authentication protocol SSH Connection protocol

SSH2 allows for additional parameter negotiation

More general session key exchange possibilities

Secure Shell: SSH SSH-2 changes:

SSH-2 uses better integrity checking for messages.

Supports password changes. User-authentication methods more

restricted: Public key (DSA, RSA, OpenPGP) Hostbased password