Network Security ArchitecturesPart 2 Formalization and Testing

Summer School on Software Security Theory to Practice

Carl A. GunterUniversity of PennsylvaniaSummer 2004

End-to-End Security and Mandatory Tunnels

First hopencryption

Second hopencryption

SecurityGatewayClient Server

Examples: WTLS, cdma2000, L2TP, Palm VII

Goals for a Security Protocol

1. If client C receives content from server S, then this is authorized by the policies of S and all of the security gateways between C and S

2. If C receives content from S, then this content is encrypted and authenticated from end-to-end between C and S

3. Simple setup and low-overhead enforcement

IPSec Strategy

Encapsulation

AH headers for authentication and authorization of traversal. Use tunnel mode.

ESP header for authentication and confidentiality of end-to-end communication. Use transport mode.

IP AH IP AH IP ESP TCP payload ESP

20 24 20 24 20 8 20 16

Drawbacks to IPSec Solution

Requires complex configuration using nested tunnels to establish security associations between client, gateways and server

Encrypts the TCP header limiting use of VJC and other similar compression techniques

Setup is relatively costly as session keys must be exchanged

Nested headers introduce significant bandwidth overhead

IP SEC Header Overheads for 576 Byte Packets

# SGs

TCP TCP + VJC

0 7% 17%

1 22% 31%

2 39% 49%

3 61% 70%

4 88% 97%

Security overhead =

(4.50 + 7.61t) (60.8 – 5.25t)

Evidence of Problems

Experimental: FreeBSD IPSec showed an overhead of 46% with two gateways

Standards activity: secure L2TP overheads were so severe a standard was developed specifically to reduce them. Default security with one gatekeeper yielded this:ESPIP L2TPUDP IPPPP TCPESP Payload ESPESP

A Goodloe, C Gunter, T Hiller, P McCann, M McDougall

Case Study: Layer 3 Accounting (L3A)

Motivating problem from wireless security

Solution by composing secure tunnels

Maude model Problems Future work

A Goodloe, C Gunter, MO Stehr

Wireless Security

Why is wireless security any different from wired security? Resource constraints Increased risk to confidentiality Value of the network link

Wireless Security Efforts

Layer 1 (Physical) Spread spectrum

Layer 2 (Link) 802.11x – 802.11(b) WEP, 802.11(g) CDMA 2000 GPRS

802.11/WEP

Server

RADIUS

Attacker

SSL

WEP

Router/NAT

Network Layer Wireless Security

We propose that security be addressed at the network layer

Advantages Independent of underlying link layer Overcomes many of the problems of layer 2

solutions Leverages extensive experience, s/w, and h/w

support from Ipsec for VPNs Disadvantage

Need set up protocols

Protocols for Tunnel Composition

We have been investigating protocols for composing IPSec security tunnels

Given a scenario we ask: What tunnels should we establish? What properties should these tunnels

have? Develop protocols that compose these

tunnels into a satisfactory solution Lots of messy details to consider in order

to get the composition to work

Toward Layer 3 Security

Suppose we have three parties: client, server, network access server (NAS)

The client wishes to securely access the server

We will assume that the client has a relationship with the NAS and the server, but the NAS does not have a relationship to the server The Client will have to authenticate itself to

both the NAS and the server

Network Layer Wireless Security

Laptop

Server

Authentication

Authentication and Encryption

NAS

Problem

Similar problem as before The NAS does not protect the client

from attacking incoming traffic Being forced to pay for service you

never used is worse than denial of service

How About a Firewall?

Laptop

Server

Authentication

Authentication and Encryption

NAS

Firewall

Why Not a Firewall

A stateful firewall can be programmed to allow only traffic from the address to which a connection has been made

The firewall can not see the contents of the Ipsec traffic and cannot guarantee origin of any traffic.

L3A Protocol Principles

The user’s traffic should travel in DOS resistant IPSec tunnels

These IPSec tunnels should be set up using DOS resistant protocols

The NAS should ensure that when the accounting system logs traffic as being from a user it is actually from that user: viz. it must authenticate incoming traffic

L3A Protocol Components

L3A protocol sets up three bidirectional tunnels

SIKE Key Exchange protocol (X509 + DoS protection) Very simple: does not use two party key

generation No guarantee of perfect forward

secrecy. Assumes existence of public key

infrastructure

L3A Architecture

Laptop

Server

Authentication Authentication

Authentication and Encryption

NAS

Methodology

An English language description resembling an IETF RFC is produced

A formal specification is written in Maude

Systems are modeled using membership equational logic and rewriting logic

Symbolic simulation has been our main debugging aid

We feel the design is now relatively stable

IPSec SA & SPD

Security Associations define a set of cryptographic transformations that are applied to each packet. Authentication w/ HMAC. Encrypt

w/3DES. SAD

Security Policies filter traffic and define what SAs apply to what traffic. CS goes into tunnels CS and CN SPD

SIKEA B

rA, SPI(n,0)

rA,rB, SPI(n,m), certB, cookieA

certA,cookieA, DA, Ps(a,DA)

Where DA = [rA, IPB, SPI(n,m)]

Where CookieA = VersionSecret | Hash([rA,rB,IPA, SPI(n,m)],Secret)

DB, Ps(b,DB)

Where DB = [rB, IPA, rA, SPI(n,m), Pe(A, K)]

Update SADB/SPD AB

Update SADB/SPD BA

Update SADB/SPD BA

Update SADB/SPD AB

L3A Protocol Overview

ClientNAS Server

Req(cred)

Ack(cred)

Fin

SPD CS:(CN)

SPD C->S:(C->N)

SPD SC:(SN)

SPD:SC:(SN)

Abstractions

Getting the right level of abstraction Modeled the various components and

layers IP, IPSec, L3A, …..

We found that we didn’t need to model details of IPSec authentication and encryption since we are interested in the set up of tunnels

We discovered that our model of IP send/receive was too abstract. Introduced messy concurrency problems

Overview of Module Interaction

L3A

PKI

SIKE

Ipsec

IP

setkey

Security Assoc

State Message

IpsecSecurity Policy

SIKEPKI

L3A AbstractL3A

L3A Test Abstract

L3A Test ConcreteSIKE Test

IP

Routing TableIP Message

Setkey

Modeling Uncovered Problems

Problems arose from interactions among the components

Numerous iterations were required to resolve problems resulting from when the Ipsec databases are updated Maude search feature was of great help

here When things are not done right

packets can slip into partially set up tunnels

We Didn’t Model

Timers Lost Messages Periodic updates to the secret used

to generate the cookie Fragmentation

Can be the source of DOS attacks UDP layer: Ports not mentioned at all

in the model

Implementation

Under development at this moment Platform. X86 running FreeBSD w/

IPSec. C with Open SSL crypto libraries Radius server to be used for accounting

Will demonstrate that our protocol can be implemented using available technology

Hope to get some useful benchmarks

A Goodloe, C Gunter, M Jacobs, G Shah

Future Work

Continue work on verifying composition of security tunnels

We are currently thinking about attacks

Do such compositions introduce new vulnerabilities?

Add the capability to reuse tunnels Seemed easy at first, but may require

some major restructuring of the design Figure out what theorems need to be

proven

Simulators

Maude “logical simulations” Exhaustive breath

first search. Model checking. Must abstract

things like packet size.

Not good with timers.

Not really useful for performance modeling.

OPNET, NS-2 discrete event simulation. Good at modeling

details (time, etc). Often used to

estimate network performance

Not good at finding the extreme cases

Probably wouldn’t have found several of our concurrency problems

Summary

Complex problems arise when composing high-level security protocols such as Ipsec tunnels

Wireless networks pose some new challenges but can leverage general solutions

Symbolic simulation can provide a powerful tool for the design of network security protocols