dns security brad pokorny the university of minnesota informal security seminar 4/18/03

27
DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03

Upload: theresa-cook

Post on 22-Dec-2015

222 views

Category:

Documents


0 download

TRANSCRIPT

DNS Security

Brad Pokorny

The University of Minnesota

Informal Security Seminar

4/18/03

Outline

Introduction to DNS The problems with it PK-DNSSEC SK-DNSSEC Comparison of PK-DNSSEC to SK-

DNSSEC

Intro to DNS

Domain Name System – Distributed, hierarchical database that associates host names with IP addresses– Allows a user to find a system without knowing

its IP (convenience)silicon.cs.umn.edu 128.101.35.181

– Organizes the internet into domains

Hierarchical Ordering

Domains logically organized as an inverted tree– exa.cs.umn.edu - full specification of the machine with

name exa– cs.umn.edu - the cs domain at umn– umn.edu - the University of Minnesota domain– edu - subdomain of root domain, denoted “.”

Divided into zones, delegating responsibilities Allows scalability required by the internet The Internet Corporation for Assigned Names and

Numbers (ICANN) oversees the domain name assignments

Hierarchical Ordering

Each zone has a Name Server (NS) NS maintains database of host information

for its zone Contact the authoritative NS of that zone to

get host information (such as IP) Information needs to be updated when host

info changes in the zone Dynamic updates change DNS data without

having to rebuild any other part of the DNS tree

Resource Records (RR’s)

Hold all DNS data Some examples

– NS - Defines the name server of a zone– A - Maps a hostname to an IP address– CNAME (Canonical Name) - Maps a hostname

alias to an A record RR’s can be cached for performance

– The TTL field of an RR specifies how long it should be cached for

The problem: Domain Hijacking IP addresses in DNS database are changed by

unauthorized hosts to point traffic destined for one domain to another

Several ways to do it1. DNS Spoofing - Trick the DNS server into trusting an

update of IP addresses2. Cache Poisoning - False IP with a high TTL, which the

DNS server will cache for a long time3. Email Spoofing - Registration with ICANN often done via

email and authenticated by the email address. Return addresses can be falsified

4. Hack the DNS Server - Change the data on the server itself5. Human Error - Administrator enters the DNS information

incorrectly DNSSEC can help prevent the first two

PK-DNSSEC - authenticate DNS data requests and replies

Use public key cryptography to implement digital signatures

Include security related DNS data as new resource records in servers and hosts

What PK-DNSSEC does NOT do

DNS data is public– No differentiation of responses to different

inquirers– No confidentiality

No Denial of Service protection

Verifying Data Authenticity and Integrity Each RRset sent as a reply to a DNS query will be accompanied by a

digital signature generated with the sender’s private key The receiver can verify the authenticity and integrity of the message

by verifying the signature

DNSSEC specifies a new RR called KEY, the public key of a system

– As always, we MUST have an authentic public key The SIG resource record is the digital signature of a reply/request

Host A NS for Host B

1. DNS Request

2. DNS Answer || Signature(DNS Answer)

3. Host A verifies signature

The SIG RR

Contains RDATA and the signature field that binds all RR data to a sender– The digital signature algorithm can be specified– Takes input of data = RDATA | RR(s)...– RDATA is the plaintext data in the SIG RR– RR(s) is the set of RR's being transmitted– Sender computes s = Ekr[h(data)]

Receiver: verifies– Dku[s] =? h(data)

The SIG RR

The SIG RR

Usually doesn't require changes to the original DNS protocol.

However, we do need authentic public keys...

Walking the chain of trust - Obtaining Authentic Public Keys Host A queries for information about Host B There is 1 trusted server (the authentic public key

is known) That server knows the public key of Host B The trusted server sends the public key of Host B

to Host A with a digital signature of the key Host A can authenticate Host B’s public key

because the trusted server’s public key is known Can be recursively applied to obtain the public key

of any system

Authenticating negative replies - NXT RR Host A sends a request for host B's (in another domain)

DNS data There is no host B, so the NS for a zone replies that it

doesn't exist An attacker obtains a copy of this message and can replay

it for request for other hosts The attacker makes existing systems "disappear" The NXT record prevents this attack

– NXT is used to get the “next” host in the domain– NXT can be authenticated– The chain of NXT’s will show that a host really doesn’t

exist if there is no entry for it

SK-DNSSEC (Ateniese) Using symmetric key cryptography would be more

efficient Encryption and decryption are faster and require

smaller keys Notice that with PK-DNSSEC

– The DNS system acts as an online Certificate Authority

– Each DNS name server that supplies public keys must be unconditionally trusted

Ateniese says we can use symmetric key crypto because of these requirements

SK-DNSSEC uses both public and private key crypto Root has a globally known public key

– All systems can authenticate communications from root

Use symmetric key certificates build chain of trust

Protocol Overview

RootHost A

1.Eku_root(PH,k1,k2,Root_Cert_Req)

.edu

2.PRA,Ek1(kRA,MACk2(kRA,PRA))

3.PRA,DNS_Req,Nonce0

4.P.eduA,DNS_Ans0,EkRA_1(k.eduA,MACkRA_2(DNS_Ans0,Nonce0,k.eduA))

5.P.eduA,DNS_Req,Nonce1

6.Pumn.eduA,DNS_Ans1,Ek.eduA_1(kumn.eduA,MACk.eduA_2(DNS_Ans1,Nonce1,kumn.eduA))

umn.edu

7.Pumn.eduA,DNS_Req,Nonce2

8.DNS_Ans2,MACkumn.eduA_2(DNS_Ans2,Nonce2)

Host A requests information about host.umn.edu

SK-DNSSEC Protocol Details

Protocol Details

Protocol Details

Protocol Details

Advantages of SK-DNSSEC Efficiency

– SK signatures can be created and verified much faster than PK signatures

– PK signatures can be reused for performance, but verification is slow and must be done for every answer

Advantages of SK-DNSSEC

Query and response sizes– Authenticated PK-DNSSEC queries and responses

don’t fit into 512byte UDP datagrams, but SK-DNSSEC authoritative answers and referrals will

– PK-DNSSEC must send a signature for each RRset, but SK-DNSSEC only sends 1 signature per query

Storage Size– Signing a zone file in a PK-DNSSEC server increases

its size by 7 times– SK-DNSSEC gives a minimal increase– Don’t need to store NXT records with SK-DNSSEC – Smaller size means that more certificates can be cached

to increase performance

Advantages of SK-DNSSEC

Replay protection– PK-DNSSEC signatures may be replayed if the

validity time is long– SK-DNSSEC uses nonces to prevent replay

Possible extensions– Mutual authentication– Confidentiality– Can be combined with PK-DNSSEC

• Top level domains use PK certificates• Lower level use SK certificates

Resources

ATEN01 Ateniese, G., Mangard, S. "A New Approach to DNS Security (DNSSEC). “Eighth ACM Conference on Computer and Communications Security, November 2001.

EAST99 Eastlake, D. "Domain Name System Security Extensions." RFC 2535, March 1999.

http://www.cs.colorado.edu/~tor/sadocs/dns/dns.html

PK-DNSSEC diagram from EAST99

SK-DNSSEC diagrams from ATEN01