Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03."— Presentation transcript:

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

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

3 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) –Organizes the internet into domains

4 Hierarchical Ordering  Domains logically organized as an inverted tree – - full specification of the machine with name exa – - the cs domain at umn – - 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

5 Hierarchical Ordering

6 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

7 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

8 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 it 1.DNS Spoofing - Trick the DNS server into trusting an update of IP addresses 2.Cache Poisoning - False IP with a high TTL, which the DNS server will cache for a long time 3.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 itself 5.Human Error - Administrator enters the DNS information incorrectly  DNSSEC can help prevent the first two

9 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

10 What PK-DNSSEC does NOT do  DNS data is public –No differentiation of responses to different inquirers –No confidentiality  No Denial of Service protection

11 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

12 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 = E kr [h(data)]  Receiver: verifies –D ku [s] =? h(data)

13 The SIG RR

14  Usually doesn't require changes to the original DNS protocol.  However, we do need authentic public keys...

15 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

16 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

17 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

18 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

19 Protocol Overview Root Host A 1.E ku_root (PH,k1,k2,Root_Cert_Req).edu 2.P RA,E k1 (k RA,MAC k2 (k RA,P RA )) 3.P RA,DNS_Req,Nonce 0 4.P.eduA,DNS_Ans 0,E kRA_1 (k.eduA,MAC kRA_2 (DN S_Ans 0,Nonce 0,k.eduA )) 5.P.eduA,DNS_Req,Nonce 1 6.P umn.eduA,DNS_Ans 1,E k.eduA_1 (k umn.eduA,MAC k.eduA_2 (DNS_Ans 1, Nonce 1,k umn.eduA )) 7.P umn.eduA,DNS_Req,Nonce 2 8.DNS_Ans 2,MAC kumn.eduA_2 (DNS_Ans 2,Nonce 2 ) Host A requests information about

20 SK-DNSSEC Protocol Details

21 Protocol Details



24 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

25 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

26 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

27 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. PK-DNSSEC diagram from EAST99 SK-DNSSEC diagrams from ATEN01

Download ppt "DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03."

Similar presentations

Ads by Google