DNS Security Brad Pokorny The University of Minnesota Informal Security Seminar 4/18/03.
-
Upload
theresa-cook -
Category
Documents
-
view
225 -
download
0
Transcript of 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
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
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
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