CIS/TCOM 551 Computer and Network Security Slide Set 6 Carl A. Gunter Spring 2004.

CIS/TCOM 551Computer and Network SecuritySlide Set 6

Carl A. GunterSpring 2004

Public Key Infrastructure

Mutual authentication of participants in a transaction requires a system of identities.

Principals are identified by public keys. These keys can be used for authentication,

but only if “spoofing” is prevented. A PKI provides a basis for establishing

trust.

PKI Systems

ITU X.509 (viz. IETF PKIX). PGP “web of trust”. DNS sec.

X.509

Part of the X.500 series of standards: the ISO/ITU Directory.

Originally intended to support access control for the directory as part of the Directory Access Protocol (DAP).

Dominant candidate now for PKI to support electronic commerce, although adoption has been slow.

X.509 Certificates

X.509 certificates bind a subject to a public key.This binding is signed by a Certificate Authority (CA).

Subject Name

Subject Public Key

CA Name

CA Signature

Subject Name

Subject Public Key

CA Name

CA Signature

Chaining

Pennsylvania CA

Pennsylvania CA Key

USA CA

Philly CA

Philly CA Key

Pennsylvania CA

Joe Smith

Joe’s Key

Philly CA

Subject

Subject’s Key

Issuer

Certificate Distribution

Certificate accompanying signature. Directory service.

DAP. LDAP. DNS SEC.

Email (S/MIME and MOSS). Primary technique: cut and paste

from web pages!

X.509 Certificate Format (v3)

Required fields. Optional fields.

Required Fields

Version of format (1,2, or 3 currently). Serial number. Signature algorithm identifier.

Examples: DSS with SHA hash. RSA with MD5 hash.

Issuer (CA) X.500 name. Validity period (start and expiry

times).

Required Fields, Continued

Subject X.500 name. Subject public key information.

Algorithm identifier. Public key value.

Issuer signature.

Optional Fields

Issuer unique identifier. Subject unique identifier. Extensions.

Extension type. Critical/Non-critical. Extension field value.

Certificate Revocation Lists

Sometimes it is necessary to terminate certificates before their expiration time.

How does the relying party know that the certificate has been revoked?

Mitre report for NIST suggests certificate revocation will be the largest maintenance cost for PKI’s.

Many distribution strategies proposed.

Semantics of CRL’s

Three certificates.1. Q says P is the public key of Alice.2. R says P is the public key of Alice.3. Q says R is the public key of Bob.

Three kinds of revocation.1. P is not the public key of Alice. (3 not

2.)2. Q no longer vouches for whether P is

the public key of Alice. (2 and 3.)3. The key of Q has been compromised.

(2 not 3.)1998 Fox and LaMacchia

Revoke

Adoption of PKI

Problems Revocation User ability to deal

with keys Registration

(challenge for all authentication techniques)

Weak business model

Areas of Progress SSL Authenticode SSH Smart cards for

government employees

Web services

Overview of Network Security Challenges:

Sharing Complexity Scale Unknown perimeter Many points of attack Anonymity Unknown paths

Security in Layers

1. Physical2. Link3. Network4. Transport5. Application

Examples

Physical Spread spectrum Tempest

Link WEP GSM

Network Firewalls IPSec

Transport SSL and TLS

Application S/MIME XMLDSIG and WS

security Access control

systems for web pages, databases, and file systems

Network Layer Security

HTTP FTP SMTP

TCP

IP/IPSec

Transport Layer Security

HTTP FTP SMTP

TCP

IP

SSL or TLS

Application Layer Security

S/MIME PGP SET

TCP

IP

SMTP HTTP

UDP

Kerberos

Division of Labor in the Internet

Hosts

Routers

Networks

Link

Network

Transport

Application

Link

Network

Transport

Application

Link

Network

Link

Network

TCP/IP Protocol Stack

Host HostRouter Router

Physical PhysicalPhysical Physical

Communication Processing Flow

Link

Network

Transport

App2

Link

Network

Transport

Link

Network

Link

Network

App1 App2App1

Physical PhysicalPhys Phys

Link

Phys

Link

Phys

Typical Patchwork

Link

Network

Transport

App2

Link

Network

Transport

Link

Network

Link

Network

App1 App2App1

Physical PhysicalPhys Phys

Link

Phys

Link

Phys

Physical Layer Protection Issues

Hide signal Spread spectrum

Emission security Radio emissions (Tempest) Power emissions

Encapsulation

LinkLink IP TCP Application

Link Layer Frame

Network LayerHeader

Transport LayerHeader

Application LayerPayload

Link

Network

Transport

Application

Link

Network

Transport

Application

Link

Network

Link

Network

One Hop Link Layer Encryption


Link Link

Link Layer Encryption


Encrypted

Link

Network

Transport

Application

Link

Network

Transport

Application

Link

Network

Link

Network

End-to-End Network Security


Network Layer Transport Mode



Encrypted

Hdr Tlr

Link

Network

Transport

Application

Link

Network

Transport

Application

Link

Network

Link

VPN Gateway


Network

Network Layer Tunnel Mode


LinkLink New IP TCP ApplicationHdr IP

Encrypted

Tlr

Layer 3 Implementation Options

Location Host Network

Style Integrated Modular (for tunnel mode)

Modular Implementation:Bump In The Stack (BITS)

Link

Security

Network

App2

Link

Network

Link

Network

Link

Net + Sec

App1 App2App1

Transport

Transport

Security

Modular Implementation:Bump In The Wire (BITW)

Link

Network

Security

App2

Link

Network

Link

Network

Link

Network

App1 App2App1

Transport Transport

Implementation Options:Integrated on Host

Link

Net + Sec

App2

Link

Net + Sec

Link

Network

Link

Network

App1 App2App1

Transport Transport

Implementation Options:Integrated on Router

Link

Network

App2

Link

Network

Link

Net + Sec

Link

Net + Sec

App1 App2App1

Transport Transport

Network Security Location Options

Link

Network

Transport

Application

Link

Network

Transport

Application

Link

Network

Link

Network

Link

Network

Transport

Application

Link

Network

Transport

Application

Link

Network

Link

Network

Link

Network

Transport

Application

Link

Network

Transport

Application

Link

Network

Link

Network

End-to-End Transport

Voluntary Tunnel

Involuntary Tunnel

Link

Network

Transport

Application

Link

Network

Transport

Application

Link

Network

Link

Network



Transport Layer Encryption



Encrypted

RH

LinkLink IP TCP App

Message Processing Sequence

Link

Network

Transport

App2

Link

Network

Transport

Link

Network

Link

Network

App1 App2App1

App2 Sec App2 Sec



LinkLink IP TCP ApplicationKey ID

Encrypted

Link Layer Security

Advantages: Transparent to applications. Hardware solution possible. Can address especially vulnerable links

(viz. wireless). Disadvantages:

Hop-by-hop protection causes multiple applications of crypto operations.

Network Layer Security

Advantages Transparent to applications. Amenable to hardware. Flexible.

Disadvantages Makes routing more complex. Flexibility introduces policy

management and compatibility challenges.


Advantages Transparent to applications. Exposing TCP enables compression,

QoS. Disadvantages

Probably implemented in software. Exposing TCP risks DoS


Advantages: customize to application no special protocol stack required:

transparent to networking Disadvantages:

hard to share between applications

Firewalls

GatewayInside Outside

Filter Filter

Filters protect against “bad” packets.A gateway machine restores needed services.Protect services offered internally from outside access.Provide outside services to hosts located inside.

Possible Firewall Architecture

Hosts

Routers

Networks

Internal Network

External Network

Gateway

DMZ

Filtering Routers

“Demilitarized Zone”

Benefits of Firewalls

Increased security for internal hosts. Reduced amount of effort required to

counter break ins. Possible added convenience of

operation within firewall (with some risk).

Reduced legal and other costs associated with sponsoring hacker activities.

Costs of Firewalls

Hardware purchase and maintenance Software development or purchase, and

update costs Administrative setup and training, and

ongoing administrative costs and trouble-shooting

Lost business or inconvenience from broken gateway

Loss of some services that an open connection would supply.

Firewall Placement

Kinds of Firewalls

Filtering: operates by filtering based on packet headers

Circuit: operates at the level of TCP Application: operates at the level of

the application

Filtering Firewalls

Filtering can take advantage of the following information from network and transport layer headers: Source Destination Source Port Destination Port Flags

IPv4 Packet Format

IPv4 (Version field set to “4”)

Version Hlen TOS Length

Ident Flags Offset

TTL Protocol Checksum

SourceAddr

DestinationAddr

Options(variable length) Pad

Other Headersand Payload

TCP and UDP packets

Protocols support O.S. “port numbers”:

SrcPort DstPort

Checksum Length SequenceNum

SrcPort DstPort

Options (variable)

Checksum UrgPtr

HL 0 Flags Advert.Wind.

Acknowledgment


UDP TCP


Three-Way Handshake

TCP State Transitions

SYN Filtering

TheirServer

OurServer

SYN

SYN/ACK

TheirClient

OurClient

Our Firewall

SYN

Ports

Ports are used to distinguish applications and services on a machine.

Low numbered ports are often reserved for server listening.

High numbered ports are often assigned for client requests.

Port 7 (UDP,TCP): echo server

Port 13 (UDP,TCP): daytime

Port 20 (TCP): FTP data Port 21 (TCP): FTP control Port 23 (TCP): telnet Port 25 (TCP): SMTP Port 79 (TCP): finger Port 80 (TCP): HTTP Port 123 (UDP): NTP Port 2049 (UDP): NFS Ports 6000 to 6xxx (TCP):

X11

Filter Example

Action ourhost port theirhost port commentblock * * SPIGOT * we don’t trust these peopleallow GW 25 * * connect to our SMTP port

Action ourhost port theirhost port commentblock * * * * default

Apply rules from top to bottom with assumed default entry:

Bad entry intended to allow connections to SMTP from inside:

Action ourhost port theirhost port commentallow * * * 25 connection to their SMTP

This allows all connections from port 25, but an outside machinecan run anything on its port 25.

Filter Example Continued

Action src port dest port flags commentallow {our hosts} * * 25 our pkts to their SMTPallow * 25 * * ACK their replies

Permit outgoing calls to port 25.

When to Filter

Router

Inside Outside

On Input or Output

Filtering on output can be more efficient since it can be combined with table lookup of the route.

However, some information is lost at this stage such as the physical input port on which the packet arrived.

This can be useful information to prevent address spoofing.

Filtering on input can protect the router itself.

Recommend: Filter ASAP

Action src port dest port commentblock SPIGOT * * * we don’t trust themallow * * GW 25 connect to our SMTPallow GW 25 * * our reply packets

Action src port dest port commentblock * * SPIGOT * subtle differenceallow * * GW 25 connect to our SMTPallow GW 25 * * our reply packets

Is preferred over:

Example of a Pitfall

Filter output to allow incoming and outgoing mail, but prohibit all else.

Apply this output filter set to both interfaces of the router. Does it work?

Unintended consequence: allows all communication on high numbered ports!

Action dest port commentallow * 25 incoming mailallow * >= 1024 outgoing responsesblock * * nothing else

Router

Inside Outside

Router

Net 1

Outside

Larger Example

Gateway

Net 2

Net 3

AB

Security Policy

Very limited connections through the router between GW and the outside world.

Very limited, but possibly different, connections are permitted between GW and anything in Net 2 or Net 3.

Anything can pass between Net 2 and Net 3.

Outgoing calls only are allowed between Net 2 or Net 3 and the outside world.

Using Input Filters

This is very difficult or impossible to achieve with output filtering only.

Example: how can output filters be used to ensure that a spoofed source from the outside does not make it appear that the packet goes from Net 2 to Net 3?

Filter on Input to Interface A

Action src port dest port flags commentblock {net 1} * * * * block forgeriesblock {net 2} * * * *block {net 3} * * * *allow * * GW 25 legal calls to usallow * * {net 2} * ACK replies to our callsallow * * {net 3} * ACK

Filter on Input to Interface B

Action src port dest port flags commentallow GW * {partners} 25 mail relayallow GW * {net 2} * ACK replies to inside callsallow GW * {net 3} * ACKblock GW * {net 2} * stop other GW callsblock GW * {net 3} *allow GW * * * let GW call the world

Doing it with Output Filtering

For a two-port router, input filtering on one port is the same asoutput filtering on the other.

RouterXY

Use two routers!

Two Routers, Same Rules

Router

Outside

Gateway

Net 2

Net 3

A

BRouter

Application Level Gateways

The gateway acts as an intermediary at the level of the application, receiving outgoing commands, relaying them, obtaining responses and relaying them back to the source.

Mail gateways are a typical example. Very strong control over security, but Special purpose software is required.

Circuit Level Gateways

Caller connects to a TCP port on the gateway and the gateway connects to a TCP port on the other side. It relays bytes, acting like a wire.

More general-purpose than application-level but allows finer control than filtering only.

Example: valuable logs of connections can be kept.

Secure Socket Layer (SSL)

Session protocol with: Server authentication. Client authentication optional. Integrity checksum. Confidentiality.

Possibly the most important security-related ecommerce protocol.

Connection sets up security parameters. Many sessions possible within a given

connection. Current version TLS 1.0

http://www.ietf.org/rfc/rfc2246.txt

http://www.ietf.org/rfc/rfc2246.txt

X.509 Key Est. Messages (Reminder)

Let DA = EB(k), rA, LA, A. Let DB = rB, LB, rA, A Two messages:

1. A -> B : certA, DA, SA(DA)Check that the nonce rA has not been seen, and is not expired according to LA. Remember it for its lifetime LA.

2. B -> A : certB, DB, SB(DB)Check the rA and A. Check that rB has not been seen and is not expired according to LB.

Real-World Protocols

Evolution (versions, extensibility) Interoperability (options, negotiation) Error modes

SSL Protocol Stack

TCP

IP

SSL Record Protocol

HandshakeChange

Cipher SpecAlert HTTP

SSL Record

ContentType

MajorVersion

MinorVersion

Length

Payload

Content Types

Handshake

Change Cipher Spec

Alert

Opaque Content

Type Length Content

1 byte 3 bytes 0 bytes

1

Level Alert

Higher-Level Protocol Content

1 byte

1 byte 1 byte

1 bytes

Creating Opaque Content

Begin with application data. Fragment it into blocks of 2**14 bytes or

less. Optionally compress the fragments. Add a message authentication code (MAC)

to the compressed data to ensure integrity.

Encrypt the data to ensure confidentiality. Add SSL record header (4 fields).

What Is Needed?

Negotiation of cryptographic protocols.

Initial authentication. Key exchange to set up:

Bulk encryption. MAC.

How is this Done?

The handshake protocol negotiates the protocols to be used for authentication and bulk encryption.

The handshake protocol carries out initial authentication.

The handshake protocol establishes a 48 byte pre-master secret. Client and server use this to derive a 48 byte

master secret. The master secret is used to generate a key

block of sufficient length to supply all needed cryptographic parameters.

MAC Calculation

A MAC write secret, MACWS, is extracted from the key block.

A hash function H is selected: either MD5 or SSH.

The MAC is defined as follows.

H( MACWS || pad2 || H( MACWS || pad1 || seq_no || SSLCompressed.type || SSLCompressed.length || SSLCompressed.fragment ))

SSL Key Exchange Protocols

RSA Fixed Diffie-Hellman Ephemeral Diffie-Hellman Anonymous Diffie-Hellman Fortezza

SSL Bulk Encryption Protocols

Protocol (type, key length) IDEA (block, 128) RC2-40 (block, 40) DES-40 (block, 40) DES (block, 56) 3DES (block, 168) Fortezza (block, 80) RC4-40 (stream, 40) RC4-128 (stream, 128)

SSL Handshake Protocol Phases

Establish Security Capabilities Server Authentication and Key

Exchange Client Authentication and Key

Exchange Finish

Establish Security Capabilities

Client Hello

Server Hello

Client Server

Time

Client Hello

1. Highest version number understood by client.

2. 32-bit timestamp and 28-bit nonce.3. Session identifier.

Nonzero value: update parameters of existing connection.

Zero value: new connection and session.

4. CipherSuite list in order of preference. A CipherSuite is a pair consisting of a key exchange algorithm (as given earlier) and a CipherSpec.

5. List of compression methods.

CipherSpec

CipherAlgorithm (as given earlier). MACAlgorithm (SHA-1 or MD5). CipherType (stream or block). IsExportable (true or false). HashSize: 0, 16 (for MD5), or 20 (for

SHA-1) bytes. Key Material. IV Size.

Server Hello

1. Highest version number supplied by client and acceptable to server.

2. Time and nonce from server (independent of same from client).

3. Session identifier. If non-zero from client then same value from

server. Otherwise proposed by server.

4. First cipher suite proposed by client and supported by server.

5. First compression method proposed by client and supported by server.

Server Auth & Key Exchange

Server Hello Done

Client Server

Time

Certificate Request

Server Key Exchange

Certificate

Optional

Certificate

List of x.509 certificates. Required for all protocols except

anonymous Diffie-Hellman.

Server Key Exchange

Protocol-dependent keying material. Needed for all except RSA and fixed

Diffie-Hellman. Example: in anonymous Diffie-

Hellman this message consists of a prime number, a primitive root for it, and the Diffie-Hellman public key for the server.

Certificate Request

Requests a certificate type (e.g. DSS for ephemeral Diffie-Hellman).

Specifies a list of certificate authorities.

Server Done

Indicates that all messages in the server authentication phase have been sent and server is now awaiting a client response.

Client Auth & Key Exchange

Client Server

Time

Certificate Request

Client Key Exchange

Certificate

Optional

Optional

Certificate

Client sends an X.509 certificate as requested by server or sends a No Certificate Alert.

Client Key Exchange

Protocol-dependent keying material. Example: In RSA the client generates

a 48 byte secret and encrypts it using the public key of the server (from the Server Key Exchange message).

Certificate Verification

Contains explicit verification of client certificate.

Client signs the hash of a concatenation of the master secret and handshake messages.

Client Auth & Key Exchange

Client Server

Time

Change Cipher Spec

Finish

Change Cipher Spec

Finish

Client and Server

The Change CipherSpec message causes the CipherSpec to become active. This is not a handshake record, but a record in the Change CipherSpec protocol.

Each party sends the Finished message under the new CipherSpec.

The message contains hashes using MD5 and SHA-1 containing the master secret and the handshake messages.

Master Secret

The Master Secret is computed from the Pre-Master Secret as follows:

MasterSecret = MD5( PreMasterSecret || SHA(“A” || PreMasterSecret || ClientHello.random || ServerHello.random)) || MD5( PreMasterSecret || SHA(“BB” || PreMasterSecret || ClientHello.random || ServerHello.random)) || MD5( PreMasterSecret || SHA(“CCC” || PreMasterSecret || ClientHello.random || ServerHello.random))

Cryptographic Parameters

The remaining cryptographic parameters are computed by iterating the following pattern.

KeyBlock = MD5( MasterSecret || SHA(“A” || MasterSecret || ClientHello.random || ServerHello.random)) || MD5( MasterSecret || SHA(“BB” || MasterSecret || ClientHello.random || ServerHello.random)) || MD5( MasterSecret || SHA(“CCC” || MasterSecret || ClientHello.random || ServerHello.random)) ||

Cryptographic Parameters

Client write MAC secret. Server write MAC secret. Client write key. Server write key. Client write IV. Server write IV.

Alerts

Unexpected message. Bad MAC. Decompression failure. Handshake failure, unable to

negotiate an acceptable set of security protocols.

Illegal parameter in handshake message.

Close notify.

Alerts, Continued

No certificate. Bad certificate. Unsupported certificate. Certificate revoked. Certificate expired. Certificate unknown: an unspecified

issue arose in certificate verification.

Ipsec

Network layer security

IPsec Classification

Modes Tunnel Transport

Protocols Authenticated

Header (AH) Encapsulated

Security Payload (ESP)

Configurations End-to-end Concatenated Nested

Principal elements Security

Associations (SAs) Internet Key

Exchange (IKE) Policy

Typical Case

Client

Server

S

SESP ESPG

S

Gateway

Internet

Corporate Network

Encapsulated Security Header and Trailer

Security Parameter Index (SPI)

Sequence Number

Initialization Vector

Protected Data

PadPad Length Next Header

Authentication Data

16-23 23-310-7 8-15

Security Association

An SA describes the parameters for processing a secured packet from one node to another.

SAs are simplex: use one for each direction.

If more than one SA is used for a packet the applicable SAs are called an “SA bundle”.

SA Parameters (ESP Only)

Sequence number, Sequence number overflow, Anti-replay window

Lifetime Mode Tunnel destination PMTU Encryption algorithm (IV, etc.) Authentication algorithm

Policy

Policy is not standardized in IPSec but certain basic functionality is expected.

A Security Policy Database (SPD) is consulted to determine what kind of security to apply to each packet.

The SPD is consulted during the processing of all traffic: Inbound and outbound IPSec and non-IPSec

SPD Actions

Discard Bypass IPsec Apply IPsec: SPD must specify the

security services to be provided. For inbound traffic it is inferred from:

destination address, protocol, SPI. For outbound traffic this is done with a

selector.

Selectors

Selectors are predicates on packets that are used to map groups of packets to SAs or impose policy.

They are similar to firewall filters. Selector support

Destination and source IP addresses Name (DNS, X.509) Source and destination ports (may not

be available on inbound ESP packets; use inner header for inbound tunnel mode).

IPsec Processing: Inbound

Use selectors in SPD to determine drop, bypass, or apply.

If apply, determine whether an SA or SA bundle for the packet exists. If yes, then apply all appropriate SAs before

dispatching. If no, then create all necessary SAs. Apply

these when done before dispatching. When creating SA determine scope of

future use: this selection or all matching the SPD selector. Update SPD selectors accordingly.

IPsec Processing: Inbound

If there are no IPsec headers check SPD selectors to determine processing discard, bypass, or apply.

If apply, then drop. If there are IPsec headers, apply SA

determined by SPI, destination, protocol.

Use selectors on result to retrieve policy and confirm correct application.

Case Study

Ipsec nested tunnels as an approach to gateway security requirements.

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 gatekeepers.

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

Internet Key Exchange

Motivating problem: Security settings (SAs) must be highly configurable

Solutions: Let network administrator manually

configure SA (most common) Provide mechanism to allow automatic

negotiation and configuration Can be found at:

http://ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-13.txt

IKEv2 Current as of March 22, 2004

IPSec

Motivating problem: Security settings (SAs) must be highly configurable

Solutions: Let network administrator manually

configure SA (most common) Provide mechanism to allow automatic

negotiation and configuration

High-level view

Requester: Responder:

IKE_SA_INIT --> <-- IKE_SA_INIT IKE_AUTH --> <-- IKE_AUTH

These are mandatory message exchange pairs, and must be executed in this order.

High-level view

Initiator: Responder:

CREATE_CHILD_SA --> <--

CREATE_CHILD_SA INFORMATIONAL --> <--

INFORMATIONAL These messages are optional and can

be sent by either party at any time.

Usage scenarios

Tunnel endpoint - Tunnel endpoint (Security gateway - Security gateway) Neither endpoint of the IP connection

implements IPSec Transparent protection Endpoints announce addresses behind

them Packets sent in tunnel mode

Usage scenarios

Endpoint - Endpoint Both implement IPSec Can use transport or tunnel mode Single pair of addresses is negotiated

for packets to be sent over this SA If NAT is used, must UDP encapsulate in

order to use port number to identify addresses “behind” NAT box

Usage scenarios

Endpoint - Security gateway Probably used for remote access to secured

network Packets sent using tunnel mode Outer IP header is source IP address (direct

back to endpoint) Inner IP header is source IP address (through

secure tunnel) Outer destination address is security gateway

IKE_SA_INIT

Negotiates common cryptographic algorithm to use for the life of SA

Exchanges nonces Performs Diffie-Hellman key

exchange

IKE_SA_INIT


HDR, SAi1, Kei, Ni --> HDR - SPIs, Version number, various

flags SAi1 - supported crypto algorithms KEi - Diffie-Hellman value (key material) Ni - Nonce

IKE_SA_INIT


<-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR - SPIs, version numbers, flags SAr1 - choice of crypto from SAi1 KEr - completes Diffie-Hellman

exchange Nr - nonce [CERTREQ] - optional certificate request

Encryption

Now both parties have enough information to compute a common SKEYSEED to derive all keys for IKE_SA

Call SK_e encryption key Call SK_a authentication key Call SK_d derived key (for

CHILD_SAs) Separate keys in each direction

IKE_AUTH

Authenticates IKE_SA_INIT by using private information from IKE_SA_INIT

Exchanges identities Exchanges certificates Establishes first CHILD_SA

IKE_AUTH

Initiator: Responder: HDR, SK {Idi, [CERT,] [CERTREQ,]

[IDr,] AUTH, SAi2, TSi, TSr} --> Everything in {..} is encrypted and

integrity protected with SK IDi - assert Initiator’s identity AUTH - prove knowledge of secret

corresponding to IDi

IKE_AUTH

Initiator: Responder: HDR, SK {Idi, [CERT,] [CERTREQ,]

[IDr,] AUTH, SAi2, TSi, TSr} --> SAi2 - begin negotiation of CHILD_SA TSi, TSr - Traffic selectors (selection

criteria for packets - entries from Security Policy Database associated with SA)

IKE_AUTH

Initiator: Responder: <--HDR, SK {IDr, [CERT,] AUTH,

SAr2, TSi, TSr} IDr - asserts Responder’s identity AUTH - authenticates identity SAr2 - completes negotiation of

CHILD_SA

Important Note

The recipients of IKE_AUTH messages must verify that all signatures and MACs are computed correctly and that the names in the ID payload correspond to the keys used to generate the AUTH payload

What have we accomplished?

Both sides have assurance that they “know” who they are talking to

The created CHILD_SA has been instantiated with parameters based upon a set of shared secrets, and these parameters have been encrypted

CREATE_CHILD_SA

Used to create a new SA when one already exists, due to different security policy, SA expiration

Similar to IKE_AUTH, without any authentication processing

Either side can initiate at any time Use SK_d for new key material

INFORMATIONAL

Used to convey control messages due to errors, notifications, or configuration changes

Node should audit half-open connections periodically and close them, but may not reuse SPIs

Other Issues

Initiating node is completely responsible for retransmission if timeout occurs

Use Message IDs for replay protection

Node can not rely on out-of-band routing information (ICMP) due to possible DoS attack

Other Issues

Nodes must be willing to accept multiple responses on IKE_SA_INIT since they are not cryptographically protected, and any intercepting node can respond

IKEv2 is highly forward compatible Rekeying can occur at any time from

either side (no set agreed lifetime)

Changes from IKEv1

4 initialization messages instead of 8 Decrease latency in common case of 1

CHILD_SA by piggybacking this onto initial message exchanges

Protocol is reliable (all messages are acknowledged and sequenced)

Responder does not have to commit state until initiator proves it can accept messages

Potential DoS Threat?

Computing keys, MACs, signatures is expensive (State, CPU exhaustion) Carry no state unless initiator responds

correctly to IKE_SA_INIT, IKE_AUTH Can still mount attack by sending a

number of valid IKE_SA_INITs, IKE_AUTHs (DDoS likely)

Possibility: Selective verification on IKE_SA_INIT?

CIS/TCOM 551 Computer and Network Security Slide Set 6 Carl A. Gunter Spring 2004.

Documents

Transcript of CIS/TCOM 551 Computer and Network Security Slide Set 6 Carl A. Gunter Spring 2004.