Information Document 17-E - PowerPoint PPT Presentation

information document 17 e n.
Skip this Video
Loading SlideShow in 5 Seconds..
Information Document 17-E PowerPoint Presentation
Download Presentation
Information Document 17-E

play fullscreen
1 / 89
Information Document 17-E
Download Presentation
Download Presentation

Information Document 17-E

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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 The Resolution Process • The workstation annie asks its configured name server, dakota, for’s address ping

  5. The Resolution Process • Let’s look at the resolution process step-by-step: ping

  6. What’s the IP address of The Resolution Process • The name server dakota asks a root name server, m, for’s address ping

  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” ping

  8. What’s the IP address of The Resolution Process • The name server dakota asks a com name server, f, for’s address ping

  9. Here’s a list of the name servers. Ask one of them. The Resolution Process • The com name server f refers dakota to the name servers ping

  10. What’s the IP address of The Resolution Process • The name server dakota asks an name server, ns1.sanjose, for’s address ping

  11. Here’s the IP address for The Resolution Process • The name server ns1.sanjose responds with’s address ping

  12. Here’s the IP address for The Resolution Process • The name server dakota responds to annie with’s address ping

  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 really get answered by the name servers? • Did it get what a real 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 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 { keys { examplekey; }; }; Use examplekey to send/validate TSIG DNS packets to/from

  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 {; examplekey; }; Zone transfers must be TSIG “signed” withexamplekey Accept dynamic updates from 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; key examplekey; }; Send dynamic updates for to 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 comes from the genuine name servers for • Should be a chain of trust to the root

  35. The Chain of Trust • Public key for is signed with the private key for .com • .com “trusts” the 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 is provably correct • It’s been signed with the key • Nobody could have tampered with the data • The key was signed by the key for .com so the 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 IN KEY 256 3 1 AQPOz/KyZAsaXxv8hbx+7lfgv4iP5twIQtyNGVnpBAMTbOykxKMJNrBdg41AufR4hItZIi76vbd0R1emEXvPpBAZ • Public RSA zone key for DNSSEC called

  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: *

  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 • 86400 SIG SOA ( 1 2 86400 2001072720082 20010627200820 42000 pGsWdt8qpm58kXDqkM8DLLKxjT8qqgTny9nY8jBHEiUAxGTV+i53fsIpVJOnWalUxbkP260OAR0bTHve4voN9g== ) • A SIG record for's SOA record signed with the key for

  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 • NXT \ A SIG NXT • Next name in zone after is • A, SIG and NXT records exist for

  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 if com is not signed