Information Document 17-E

1. Information Document 17-E ITU-T Study Group 2 May 2002 QUESTION: Q.1/2 SOURCE: TSB TITLE: INTRODUCTION TO SECURE DNS (by Jim Reid) The purpose of this document is to provide some basic introductory material on security features of the Domain Name System (DNS)

2. Introduction to Secure DNS

3. Introduction • Explaining the problem • Weaknesses in the DNS resolution process • Attacks on the name servers • Consequences of those attacks • Spoofing, mangled DNS answers • Solutions to the problem • Transaction Signatures (TSIG) • DNS Security Extensions (DNSSEC)

4. What’s the IP address of www.nominum.com? The Resolution Process • The workstation annie asks its configured name server, dakota, for www.nominum.com’s address dakota.west.sprockets.com annie.west.sprockets.com ping www.nominum.com.

5. The Resolution Process • Let’s look at the resolution process step-by-step: annie.west.sprockets.com ping www.nominum.com.

6. What’s the IP address of www.nominum.com? The Resolution Process • The name server dakota asks a root name server, m, for www.nominum.com’s address m.root-servers.net dakota.west.sprockets.com annie.west.sprockets.com ping www.nominum.com.

7. Here’s a list of the com name servers. Ask one of them. The Resolution Process • The root server m refers dakota to the com name servers • This type of response is called a “referral” m.root-servers.net dakota.west.sprockets.com annie.west.sprockets.com ping www.nominum.com.

8. What’s the IP address of www.nominum.com? The Resolution Process • The name server dakota asks a com name server, f, for www.nominum.com’s address m.root-servers.net dakota.west.sprockets.com f.gtld-servers.net annie.west.sprockets.com ping www.nominum.com.

9. Here’s a list of the nominum.com name servers. Ask one of them. The Resolution Process • The com name server f refers dakota to the nominum.com name servers m.root-servers.net dakota.west.sprockets.com f.gtld-servers.net annie.west.sprockets.com ping www.nominum.com.

10. What’s the IP address of www.nominum.com? The Resolution Process • The name server dakota asks an nominum.com name server, ns1.sanjose, for www.nominum.com’s address m.root-servers.net dakota.west.sprockets.com ns1.sanjose.nominum.net f.gtld-servers.net annie.west.sprockets.com ping www.nominum.com.

11. Here’s the IP address for www.nominum.com The Resolution Process • The nominum.com name server ns1.sanjose responds with www.nominum.com’s address m.root-servers.net dakota.west.sprockets.com ns1.sanjose.nominum.net f.gtld-servers.net annie.west.sprockets.com ping www.nominum.com.

12. Here’s the IP address for www.nominum.com The Resolution Process • The name server dakota responds to annie with www.nominum.com’s address m.root-servers.net dakota.west.sprockets.com ns1.sanjose.nominum.net f.gtld-servers.net annie.west.sprockets.com ping www.nominum.com.

13. What’s Wrong With That? • Nothing: it all works fine….. • BUT there’s no authentication at all! • A client can’t tell: • Where an answer really came from • If the server that replied is telling the truth or not • If it received exactly what the server sent

14. Cracking the DNS • Bombard client with bogus answers • Guess what the answer might be • Intercept an answer packet & modify it • Only works well if adjacent to client or server • Set up a fake server for some zone • Trick other servers into querying the fake one • Evil routing/peering tricks & hi-jack traffic • Inject bogus routes for the root servers (or the servers for any other “interesting” zone)

15. What Does This Mean? • A DNS client can’t be sure of anything: • Did a lookup for www.nominum.com really get answered by the nominum.com name servers? • Did it get what a real nominum.com name server actually sent? • Is the server that answered telling the truth? • Did we get the actual address of Nominum’s web server? • Feel free to replace nominum.com with your favourite domain name….

16. Transaction Signatures The use of Transaction Signatures, TSIG, is explained in this section

17. Transaction Signatures (TSIG) • Defined in RFC2845 • Computed on the fly • Not in zone files • Added to Additional Section of DNS replies • Uses a shared secret and cryptographic hash functions • Currently HMAC-MD5 • Timestamps prevent replay attacks

18. TSIG Overview • "Lightweight" digital signature • Cryptographic hash of: • DNS query or answer • Timestamp • Shared secret • Can be anything (within reason) • Usually generated by dnssec-keygen • Use any tool that generates a base-64 encoded string

19. Cryptographic Hash Functions • Very strong checksums • Mathematically proven to have almost no chance of a collision: • Different inputs cannot result in the same hash value • MD5 hash of ASCII character 1 • b026324c6904b2a9cb4b88d6d61c81d1 • MD5 hash of ASCII character 2 • 26ab0db90d72e28ad0ba1e22ee510510

20. TSIG Validation • Other party knows: • Contents of DNS packet • Chosen crypto hash algorithm • Time of day (UTC) • Shared Secret • It can compute the TSIG hash value • If the calculated hash matches the TSIG hash in DNS packet, all is well • If not, something has gone wrong: • Wrong timestamp • Different shared secret

21. TSIG Shared Secret • An obvious vulnerability • Has to remain secret • Systems using TSIG should be under one administrative & operational control • Authenticating zone transfers? • Many TLDs do this already • Dynamic DNS update requests • DHCP server, nsupdate

22. Using TSIG named.conf key{}, server{}statements: key examplekey { algorithm hmac-md5; secret "pRP5FapFoJ95JEL06sv4PQ=="; }; server 10.9.8.7 { keys { examplekey; }; }; Use examplekey to send/validate TSIG DNS packets to/from 10.9.8.7

23. TSIG for Access Control • The name of a TSIG key can be used in a BIND Access Control List: allow-transfer { examplekey; }; allow-update {127.0.0.1; examplekey; }; Zone transfers must be TSIG “signed” withexamplekey Accept dynamic updates from 127.0.0.1 or if they're signed byexamplekey

24. TSIG and named.conf • named.conf is usually world-readable • but TSIG keys should be kept secret • Use an include statement • put the keys in a private file and include that: include "/not/for/public/tsig-keys"; • Watch out for keys in core dumps or name server logs!

25. TSIG and Dynamic Updates • nsupdate • BIND utility for performing Dynamic DNS (DDNS) updates • nsupdate understands TSIG • Allows TSIG authentication of Dynamic Update requests • Only sane way to authenticate them • Alternative is by (easily forged) IP address

26. TSIG and DHCP • ISC DHCP server understands TSIG too • Standards for DDNS and DHCP interaction still to be completed by IETF • Security considerations • Name server may trust DHCP daemon • DHCP daemon may believe untrusted clients • Could insert illegal/unwanted hostnames into DNS • TSIG "signatures" better than nothing

27. dhcpd Updates with TSIG Add to dhcpd.conf: key examplekey { algorithm HMAC-MD5.SIG-ALG.REG.INT; secret pRP5FapFoJ95JEL06sv4PQ==; }; zone EXAMPLE.ORG. { primary 127.0.0.1; key examplekey; }; Send dynamic updates for example.org to 127.0.0.1 signed with examplekey TSIG key

28. Timestamps and TSIG • Transaction Signatures include a timestamp • Prevents replay attacks • Fuzz factor allows clocks to be out by up to a few minutes • Systems using TSIG should have their clocks synchronised • Should be running NTP anyway • Run Secure NTP if you're paranoid • Or buy an atomic clock!

29. Windows 2000 • Windows 2000 uses Dynamic DNS updates • Active Directory • Does not use TSIG • Uses a proprietary mechanism, GSS-TSIG • Based on “mangled” Kerberos tickets • GSS-TSIG proposed as IETF standard • No second implementation (yet)

30. Summary • Transaction Signatures (TSIG) have been explained in this section: • How to use them for authentication • clients, name servers, dynamic update requests • Using them in BIND Access Control Lists • Timestamps mean clocks should be synchronised • Windows 2000 issues

31. Secure DNS (DNSSEC) This section explains DNSSEC: Secure DNS • Rationale for DNSSEC • What problems DNSSEC solves • What problems it does not solve • What problems DNSSEC creates • KEY, SIG and NXT records • BIND9's DNSSEC utilities • Signing a zone

32. Why Secure DNS? • The DNS is not secure!!! • Servers could be lying • Cache poisoning attacks • Servers could be spoofed • Answers could be tampered with • UDP makes these attacks simple • This is what Secure DNS is designed to solve

33. What DNSSEC Does Not Do • Prevent/thwart denial-of-service attacks • Stop name server compromises • Buffer overflows • Run BIND9 to stop that! • Environment variable leakages • Confidentiality of DNS data • The DNS is public after all...

34. What Secure DNS Proves • Data authenticity • What was received was what the server sent • Non-repudiation • Who/what signed the data • Name server authenticity (in theory anyway) • An answer for foo.example.com comes from the genuine name servers for example.com • Should be a chain of trust to the root

35. The Chain of Trust • Public key for nominum.com is signed with the private key for .com • .com “trusts” the nominum.com key • Public key for .com is signed with the private key for the root • Root zone “trusts” the .com key • Everyone trusts the root zone’s public key • Openly published • Built in to every name server?

36. Validation Model • Answer for ww.nominum.com is provably correct • It’s been signed with the nominum.com key • Nobody could have tampered with the data • The nominum.com key was signed by the key for .com so the nominum.com key is OK • The .com key was signed by the root key so the delegation to com can be trusted too • The root key is known and trusted by everyone

37. Secure DNS Overview • Defined in RFC2535 (DNSSEC) • Raft of enhancements & extensions since then: • RFC2536, RFC2537, RFC2931, RFC3007, RFC3008, RFC3090, RFC3110, etc • Three new resource records: • KEY, SIG and NXT • Digital signatures of DNS data • Industrial-strength crypto: • DSA, RSA, Diffie-Helman

38. Public Key Cryptography • Asymmetric encryption: • RSA, DSA • Public key and private key pairs • Data encoded with public key can only be decoded with the corresponding private key and vice versa • Digital signatures • Non-repudiation • Confidentiality • Not used in DNSSEC! • DNS is supposed to be public after all

39. DNSSEC Signatures • Don't explicitly sign the actual DNS data • Sign a hash of the data instead (SHA1) • Less data to sign • Names must be normalised to a canonical form: • All in lower-case • Fully qualified domain names • Handled automatically by the zone signing tool

40. The KEY Record • The public key component • Format: name KEY flags proto algorithm pubkey

41. flags • What the key can be used for: authentication, zone, user, etc • proto • Protocol identifier: DNSSEC, IPsec, TLS, etc • algorithm • Crypto algorithm: RSA, DSA • pubkey • Base-64 public key

42. An Example KEY Record example.com. IN KEY 256 3 1 AQPOz/KyZAsaXxv8hbx+7lfgv4iP5twIQtyNGVnpBAMTbOykxKMJNrBdg41AufR4hItZIi76vbd0R1emEXvPpBAZ • Public RSA zone key for DNSSEC called example.com

43. The SIG Record • A digital signature for some RRset • RRset: resource records with same name, class, type and TTL • Horribly complicated • Format: name SIG type alg labels ottl sig-exp sig-inc key-tag signer sig

44. type • the RRset type that the SIG record signs • A, MX, SOA, etc • alg • crypto algorithm • as in the KEY record • labels • number of labels in the name that are signed • kludge for wildcards: *.example.com

45. ottl • original TTL of signed RRset • sig-exp • time when the signature expires • sig-inc • time when the signature is valid from

46. key-tag • short-cut to identify the key • helps when there are 2 or more keys • signer • name of the public key to validate the signature • sig • base-64 encoding of signature

47. An Example SIG Record • example.com. 86400 SIG SOA ( 1 2 86400 2001072720082 20010627200820 42000 example.com. pGsWdt8qpm58kXDqkM8DLLKxjT8qqgTny9nY8jBHEiUAxGTV+i53fsIpVJOnWalUxbkP260OAR0bTHve4voN9g== ) • A SIG record for example.com's SOA record signed with the key for example.com

48. The NXT Record • For proving a name or RR type does not exist • Can't just sign NULL string! • Format: name NXT next-name types • next-name • Name of alphabetically next record in the zone • Last name points back to zone's SOA record • types • Resource record types that exist for the name

49. An Example NXT Record • jim.example.com. NXT \ ns0.example.com A SIG NXT • Next name in zone after jim.example.com is ns0.example.com. • A, SIG and NXT records exist for jim.example.com

50. Signing a Zone • 4 steps: • Generate a key • Get parent to sign zone key • Incorporate parent's signature of zone key • Sign the zone • Can self-sign when the parent zone is not DNSSEC-aware • e.g. self-sign example.com if com is not signed