1 / 23

Using Digital Signature with DNS

Using Digital Signature with DNS. DNS structure. Virtually every application uses the Domain Name System (DNS). DNS database maps: Name to IP address www.darpa.mil = 128.9.176.20 And many other mappings (mail servers, IPv6, reverse…) Data organized as tree structure.

ita
Télécharger la présentation

Using Digital Signature with DNS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using Digital Signaturewith DNS

  2. DNS structure • Virtually every application uses the Domain Name System (DNS). • DNS database maps: • Name to IP addresswww.darpa.mil = 128.9.176.20 • And many other mappings (mail servers, IPv6, reverse…) • Data organized as tree structure. • Each zone is authoritativefor its local data.

  3. Example of Zone file Example Zone file dacht.net 7200 IN SOA ns.ripe.net. olaf.ripe.net.( 2001061501 ; Serial 43200 ; Refresh 12 hours 14400 ; Retry 4 hours 345600 ; Expire 4 days 7200 ; Negative cache 2 hours ) dacht.net 7200 IN NS ns.ripe.net. dacht.net 7200 IN NS ns.high5.net. pinkje.dacht.net 3600 IN A 193.0.1.162 host25.dacht.net 2600 IN A 193.0.3.25

  4. DNS resolving Question: www.cnn.com . www.cnn.com A ? dns.cs.umass.edu lab.cs.umass.edu resolver ask .com server the ip address of .com server stub resolver www.cnn.com A ? xxx.xxx.xxx.xxx www.cnn.com A ? .com ask cnn.com server the ip address of cnn.com server add to cache www.cnn.com A ? xxx.xxx.xxx.xxx www.cnn.com cnn.com

  5. DNS Vulnerabilities • Client <-> DHCP Server • Client <-> Resolver • Resolver itself (rootfile) • Resolver's communication to the net • Various glue records and their update mechanism • Various nameserver <-> nameserver communication • Various network <-> network communication

  6. Focus on vulnerabilities Cache impersonation Corrupting data Impersonating master Zone administrator master resolver Zone file Dynamic updates slaves stub resolver Cache pollution by Data spoofing Unauthorized updates Data Protection Server Protection

  7. Historical reasons • Original DNS design focused on data availability • DNS zone data is replicated at multiple servers. • A DNS zone works as long as one server is available. • DDoS attacks against the root must take out 13 root servers. • But the DNS design included no authentication. • Any DNS response is generally believed. • No attempt to distinguish valid data from invalid. • Just one false root server could disrupt the entire DNS.

  8. Simple attack

  9. More complex attack

  10. What is the problem ? • Resolver can not distinguish between valid and invalid data in a response. • Idea is to add source authentication • Verify the data received in a response is equal to the data entered by the zone administrator. • Must work across caches and views. • Must maintain a working DNS for old clients.

  11. What is solution ? • Each DNS zone signs its data using a private key. • Recommend signing done offline in advance • Query for a particular record returns: • The requested resource record set. • A signature (SIG) of the requested resource record set. • Resolver authenticates response using public key. • Public key is pre-configured or learned via a sequence of key records in the DNS heirarchy.

  12. Protect DNS with digital signature • Secure client <-> resolver communication • Secure LAN/DHCP • DNSSEC aware Resolver on Client(!) • Secure communication between nameservers • Zone transfers (AXFR) • dynamic updates • Secure data storage integrity • Zonefiles • Caches

  13. DNSSEC • The core of the DNSSEC specification is described in the following 3 RFCs, published March 2005: • RFC 4033 - DNS Security Introduction and Requirements • RFC 4034 - Resource Records for the DNS Security Extensions • RFC 4035 - Protocol Modifications for the DNS Security Extensions

  14. Main Goal of DNSSEC • a) origin authentication of DNS data, • b) data integrity • c) authenticated denial of existence.

  15. New record types • The KEY record: The public key used • The SIG record: The signatures created by that key • The NXT record: For denial of existance • The DS record: For building the chain of trust

  16. How does it work • The DNS servers sign (digitally encrypt)the hash of resource record set with its private keys • Resouce record set: The set of resource records of the same type. • Public KEYs can be used to verify the SIGs • The authenticity of public KEYs is established by a SIGnature over the keys with the parent’s private key • In the ideal case, only one public KEY needs to be distributed off-band (the root’s public KEY)

  17. Key record RRlabel TTL IN KEY <flags> <protocol> <algorithm> <key material> freeswan.nl. 3600 IN KEY 256 3 5 ( AQPRv8TN8ayfxrtRo1dveOMVSSpT4PGEZvfGjaERldQZ izYKgVBj/l84DjVktGUbkJ3pBiLBAzZ+5nbGkWn+Lz5Z gHMlQnjWde/mKKDlZnwQ13vU+HPt3cszNy9CdBmn6l8= ) ; key id = 56954 flags: authentication, confidentiality protocol: DNSSEC = 3, IPsec = 4 [only protocol 3 is allowed since RFC3445] algorithm: RSAMD5 = 1, DiffieHellman = 2, DSA = 3, EllipticCurve = 4, RSASHA1 = 5

  18. The SIG record RRlabel TTL IN SIG <type covered> <algorithm> <# of labels> <original ttl> <sig expiration> <sig inception> <key tag> <signer name> <key material> freeswan.nl. 3600 IN NS ns.xtdnet.nl. freeswan.nl. 3600 IN NS ns1.xtdnet.nl. freeswan.nl. 3600 IN SIG NS 5 2 3600 20030506165654 ( 20030406165654 56954 freeswan.nl. bTKJvyrwmP+nsFoE8oelC4gFqoyJxkawNIExMVupI+ie NeyUYdkrpDVBF5yn7U0dLxQu/+wqbOGYjPWx/r1ybZF7 JMd1PRefb30TsBtsrA9Ah13EKmO18oyJEZdDWwPV )

  19. The NXT record RRlabel TTL IN NXT <alphanumeric next RRlabel> <list of existing RRsets> alpha.freeswan.nl. 3600 IN NXT gamma.freeswan.nl. NS SOA MX SIG KEY NXT Denial of existance: We now know there is no RRset beta.freeswan.nl.

  20. Delegation problem • The Parent should securely delegate authority of the child zone • Parent cannot give a “non-authoritative” answer • Parent cannot not sign child zone data • It has no private key of child • Parent should not sign child zone data • It is not authoritative for child zone • Parent will need to serve NS (and perhaps glue) records of child zone • Answer needs to be secure

  21. The DS recordSign a hash of the child key RRlabel TTL IN DS <key tag> <algorithm> <20 bit SHA-1 Digest> freeswan.nl. 345600 IN NS ns.xtdnet.nl. freeswan.nl. 345600 IN NS ns1.xtdnet.nl. freeswan.nl. 345600 IN DS 49601 5 1 ( C7D3B76F7DEE10E6A73B7D0F6EDAF55FFF60CA78 ) freeswan.nl. 345600 IN SIG DS 1 2 345600 20030416070311 ( 20030409070311 6869 nl. W2pmK7IGF1W7SDJxyyTep707lDRQ36IEkmyEhezJO72U 3g1YeWTI4r5lSAOkGW/+u74FRuQgMFzYzRisCZKYCiBm rNiatRg+TTf9+yzJcqg9A2CuygNBi8I7aVloYxsM+qri 9J1CJQuxAzbKLPAppQw4UP1VOiB4NvHWG2jwFNw= ) - These are all the freeswan.nl records at the parent - Parent only signs DS record for which it is authoritative.

  22. Is it deployed • Standard since 2005 • Not yet deployed at a large scale !! • Considerable overhead (CPU, network). • No major attacks against DNS justify the need. • Could we consider it as a “failed” case for security ? • Telnet was replaced by SSH, FTP replace with secure version. Only DNS and SMTP remain totally unsecured.

  23. THANK YOU QUESTIONS ?

More Related