Top Banner
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.

Dec 22, 2015

Download

Documents

Theresa Cook
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

DNS Security

Brad Pokorny

The University of Minnesota

Informal Security Seminar

4/18/03

Page 2: 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

Page 3: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 4: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 5: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

Hierarchical Ordering

Page 6: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 7: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 8: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 9: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 10: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

What PK-DNSSEC does NOT do

DNS data is public– No differentiation of responses to different

inquirers– No confidentiality

No Denial of Service protection

Page 11: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 12: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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)

Page 13: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

The SIG RR

Page 14: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

The SIG RR

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

However, we do need authentic public keys...

Page 15: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 16: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 17: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 18: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 19: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 20: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

SK-DNSSEC Protocol Details

Page 21: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

Protocol Details

Page 22: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

Protocol Details

Page 23: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

Protocol Details

Page 24: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 25: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

Page 26: DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.

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

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

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