8.X Sec & I Pv6

Post on 20-Aug-2015

434 views 3 download

Transcript of 8.X Sec & I Pv6

Course 3: Network Security, Section 8Pascal Meunier, Ph.D., M.Sc., CISSPMay 2004, updated July 30, 2004Developed thanks to the support of Symantec Corporation,NSF SFS Capacity Building Program (Award Number 0113725) and the Purdue e-Enterprise CenterCopyright (2004) Purdue Research Foundation. All rights reserved.

Course 3 Learning Plan

Architecture Physical and link layer Network layer Transport layer Application layer: DNS, RPC, NFS Application layer: Routing Wireless networks More secure protocols: DNSSEC, IPSEC, IPv6

Learning objectives

Understand how IPSEC and IPv6 are inter-related Learn the IPSEC header types and transport modes Understand how ISAKMP and IKE support IPSEC Understand how DNSSEC can secure some

vulnerabilities in DNS

More Secure Protocols

-IPSEC, IPv6– ISAKMP– IKE

DNSSEC

IPSEC Outline

Goals, Services Relationship to IPv6 Fundamental Concept: Security Associations IPSEC Headers (protocols)

– Authentication Header (AH)– Encapsulating Security Payload (ESP)

IPSEC support protocols– IKE– ISAKMP

Advanced topics– Security limitations of IPSEC– NAT and IPSEC

IPSEC Goals

Add-on to IPv4 Built into IPv6 Provides, at the IP layer:

– Authentication– Integrity– Confidentiality

Does not provide solutions or solve problems for Availability

IPSEC Services

Access control Connectionless integrity Data origin authentication Protection against replays (a form of partial

sequence integrity) Encryption (confidentiality) Limited traffic flow confidentiality

– e.g., Does Eve need to know that Alice and Bob are exchanging data?

Differences IPv6 vs IPv4

New ICMP architecture (ICMPv6) Expanded Addressing Capabilities Header Format Simplification Improved Support for Extensions and Options Flow Labeling Capability (for quality of service) Authentication and Privacy Capabilities

– i.e., IPSEC (RFC 2460)

Security Associations

Channel that provides certain properties (keys, algorithms...) to the traffic between the hosts

Directional: Host A to Host B Uniquely identified by a triple:

– Security Parameter Index Some integer

– IP Destination Address (so far only unicast)– Protocol header identifier

See header types on next slides

SAs must be established and negotiated before any data is exchanged.

SA Headers

Each SA must be of type – AH (Authentication Header) or– ESP (Encapsulating Security Payload)

Two modes:– Tunnel– Transport

{X, 192.168.1.2, ESP}

192.168.1.2 192.168.1.3

{Z, 192.168.1.3, AH}

Transport Mode

Does not hide or replace the original IP header– AH header is used in illustration

IPHeader

TCPHeader

TCPPayload

IPHeader

TCPHeader

TCPPayload

SAHeader

Packet transformation for SA transport

Tunnel Mode

Adds a new IP header Allows nesting of SAs Protects the original IP header

IPHeader

TCPHeader

TCPPayload

IPHeader

TCPHeader

TCPPayload

SAHeader

Packet transformation for SA tunnel

IPHeader

Note: The illustration applies to a AH header

IP Authentication Header

RFC 2402 AH goals:

– connectionless integrity– data origin authentication– optional anti-replay service

Which IPSEC service doesn’t AH provide?

Answer

Confidentiality

Authentication Header Format

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Next Header | Payload Len | RESERVED |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Security Parameters Index (SPI) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Sequence Number Field |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

+ Authentication Data (variable) |

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Integrity

Provided by an Integrity Check Value (ICV)– Stored in the "authentication data" field

Calculation method: HMAC with either of:– MD5– SHA-1

Uses a secret key exchanged during SA negotiation

Authentication

Hash is calculated over as much data as possible

IPHeader

TCPHeader

TCPPayload

SAHeader

Authenticated except for mutable fields

IPHeader

TCPHeader

TCPPayload

SAHeader

IPHeader

AH Data Origin Authentication

Because the HMAC secret is specific to the SA Because the IP addresses are included in the

HMAC calculation

AH Anti-Replay Service

Sender puts in a Sequence Number– Not to be confused with the TCP sequence number– SAs become void when the sequence number overflows

Receiver must verify it– optional

HMAC calculation guarantees that nobody could alter the sequence number or inject malicious packets with the correct sequence number– So it doesn't matter if the sequence number is predictable

ESP

Has service options 2 service types

– Confidentiality Confidentiality through encryption Limited traffic flow confidentiality

– Requires tunnel mode so that the original IP header is encrypted

– Authentication Connectionless integrity Data origin authentication Optional anti-replay service

– Can be selected only if data origin authentication was selected

Both types can be present at the same time Described in RFC 2406

ESP Parts

Header Trailer

– Not present in AH

Authentication– Part of the AH header

ESP Transport Mode

Does not hide or replace the original IP header

IPHeader

TCPHeader

TCPPayload

IPHeader

TCPHeader

TCPPayload

ESPHeader

Packet transformation for ESP transport

ESPTrailer

ESPAuth

ESP Tunnel Mode

Adds a new IP header Allows nesting of SAs Protects the original IP header

IPHeader

TCPHeader

TCPPayload

IPHeader

TCPHeader

TCPPayload

ESPHeader

Packet transformation for ESP tunnel

IPHeader

ESPTrailer

ESPAuth

ESP Authentication

Uses the same idea as AH authentication– HMAC provides integrity and data origin authentication

Sequence number provides optional protection from replay attacks

ESP authentication does not protect the IP header in transport mode– AH header protects the IP header as much as possible

ESP Coverage

Hash is calculated over less data than AH header

Authenticated

IPHeader

TCPHeader

TCPPayload

ESPHeader

ESPTrailer

ESPAuth

IPHeader

TCPHeader

TCPPayload

ESPHeader

IPHeader

ESPTrailer

ESPAuth

Encrypted

Question

Why would someone prefer AH instead of ESP?

a) AH is more compatible with IPv4b) AH is significantly fasterc) ESP can’t authenticated) AH authenticates the headerse) no reason

Question

Why would someone prefer AH instead of ESP?

a) AH is more compatible with IPv4b) AH is significantly fasterc) ESP can’t authenticated) AH authenticates the headerse) no reason

ISAKMP

Internet Security Association and Key Management Protocol

Aims to be "a common security establishment protocol"– Means it helps setup security associations

Problem statement: How do you– Perform initial authentication of peers– Create, manage and delete associations

Specify AH or ESP

– Decide which encryption algorithm to use– Decide which authentication algorithm to use

Described in RFC 2408– Rides on top of UDP

Fundamental Basis for ISAKMP/IPSEC

Public key cryptography– Hosts are identified with certificates signed by a Certificate

Authority Including public key

Need for Public Key Infrastructure (PKI) Internet Policy Registration Authority (IPRA)

– Policy Certification Authorities (PCA) Certificate Authorities (CAs)

Certificate Payloads

ISAKMP has the ability to carry certificate payloads Where to get certificates?

1. DNSSEC or equivalent

2. Certificate Payloads (ISAKMP) PKCS #7 wrapped X.509 certificate PGP certificate X.509 Kerberos Tokens DNS signed key

ISAKMP Characteristics

Abstract, ubiquitous framework Heavy

1. Hosts must first establish an SA for ISAKMP exchanges

2. Then the needed SAs can be established– Many fields or messages to negotiate– Implements reliability

– Timers, resending of packets

ISAKMP

Flexible– Many negotiation options

Complicated– The negotiation options have various advantages and

disadvantages– The security implications of the choices, and which one is

optimal for a given task, are not obvious

Does not perform the actual key generation and exchange– Need to use IKE (see next slide)

IKE

Internet Key Exchange RFC 2409 IKE works with ISAKMP to establish and manage

SAs to provide IPSEC services. Key exchange can be done manually and IPSEC

still works; IKE automates it. Details out of the scope of this presentation

DNSSEC

DNS Extension Based on cryptographic digital signatures Basic Idea:

– Store public keys in DNS records "KEY" resource record Associated with a name

– Use those to authenticate DNS transactions

Provides:– Data integrity– Authentication

Zones

Each zone has a public/private key pair– RR sets are signed with the private key– Resolvers can verify the signature with a public key

Initial public key must be seeded securely somehow From that key, a chain of trust is created to other zones

Guarantees integrity and authenticity No cache poisoning IN-ADDR.ARPA domain information still controlled

by possibly untrustworthy sources– Even if the data is signed, it may be malicious– Inconsistencies between the two DNS trees are not

resolved

DNSSEC Today

Still not in wide use Had several setbacks in specification development Doesn't solve all problems

– However an incremental improvement is better than status quo

Meetings and plans to establish the deployment roadmap (2004)

Question

The AH IPSEC header provides: a) Connectionless integrity, data origin

authentication, and an optional anti-replay service b) Confidentiality (encryption) and limited traffic flow

confidentiality

Question

The AH IPSEC header provides: a) Connectionless integrity, data origin

authentication, and an optional anti-replay service b) Confidentiality (encryption) and limited traffic

flow confidentiality

Question

Which is the strong requirement for the practical, widespread deployment of IPSEC, DNSSEC and related protocols?

a) Better keyed hash algorithms b) Larger cryptographic key sizes c) A mass adoption and transition to IPv6 d) A cheap, deployed public key infrastructure (PKI) e) Greater, cheaper internet bandwidth

Question

Which is the strong requirement for the practical, widespread deployment of IPSEC, DNSSEC and related protocols?

a) Better keyed hash algorithms b) Larger cryptographic key sizes c) A mass adoption and transition to IPv6 d) A cheap, deployed public key infrastructure

(PKI) e) Greater, cheaper internet bandwidth

Question

Security Associations are a) Bidirectional b) Multidirectional c) Special interest groups d) Unidirectional

Question

Security Associations are a) Bidirectional b) Multidirectional c) Special interest groups d) Unidirectional

Question

DNSSEC protects DNS against a) Malicious DNS administrators b) All networking protocol attacks c) Malicious web sites d) DNS cache poisoning

Question

DNSSEC protects DNS against a) Malicious DNS administrators b) All networking protocol attacks c) Malicious web sites d) DNS cache poisoning

Questions or Comments?

About These Slides

You are free to copy, distribute, display, and perform the work; and to

make derivative works, under the following conditions.

– You must give the original author and other contributors credit

– The work will be used for personal or non-commercial educational uses

only, and not for commercial activities and purposes

– For any reuse or distribution, you must make clear to others the terms of

use for this work

– Derivative works must retain and be subject to the same conditions, and

contain a note identifying the new contributor(s) and date of modification

– For other uses please contact the Purdue Office of Technology

Commercialization.

Developed thanks to the support of Symantec Corporation

Pascal Meunierpmeunier@purdue.eduContributors:Jared Robinson, Alan Krassowski, Craig Ozancin, Tim Brown, Wes Higaki, Melissa Dark, Chris Clifton, Gustavo Rodriguez-Rivera