Table of Contents. DNS security basics. What DNSSEC has to offer. In what sense is DNS insecure? Why DNS needs to be secured.

Transcription

1 Table of Contents DNS security basics The basics Karst Koymans (with Niels Sijm) Informatics Institute University of Amsterdam (version 2.3, 2013/09/13 11:46:36) Tuesday, Sep 17, 2013 Why DNS needs to be secured The long (and winding) road to the DNSSEC specification On locks and seals Chain of trust Walking and trusting the DNS tree Validating RRsets using multiple DNSKEY records Details of RRs used in the chain of trust In what sense is DNS insecure? What DNSSEC has to offer DNS data can be subject to forgery Non-authoritative servers can try to inject false information Records can be changed in transit to point to evil information Like A records pointing to a phisher s IP address DNS data traverses the network in clear text Anyone with network path access can eavesdrop on your DNS traffic Gleaning information useful in spoofing attacks Protects against forgery Uses public key cryptography Cryptographically signs the resource record sets in answers Builds a chain of trust from the root down Does not prevent eavesdropping Data still traverses the network in clear text Gleaning data is still possible But spoofing is not possible any more

2 DNSSEC specification Alternative DNS security mechanism Original specification from January 1997 RFC 2065 Revised specification from March 1999 RFC 2535 Incorporated feedback from early users Had deployment problems, especially scaling issues Final specification from March 2005 DNSSEC-bis (RFC 4033, 4034 and 4035) Final addition from February 2008 NSEC3 (RFC 5155) DNSCurve Idea by Dan Bernstein Proposed in August 2008 (after NSEC3 spec) Encrypts and authenticates on the link level Signs communication packets, not resource records Uses labels of name servers to distribute public keys Uses state of the art elliptic curve cryptography for speed Worth a read at Also see Secret key cryptography Public key cryptography encryption Use one lock and two identical keys Use a lock, which closes without key, and one key to open Source: Cisc, University of Hong Kong Source: Cisc, University of Hong Kong

3 Public key cryptography signing Trusted party and/or certificate authority Use an unforgeable seal and check the characterisitics Use a trusted repository or party Create a chain of trust by signing public keys Source: Cisc, University of Hong Kong Source: Cisc, University of Hong Kong Basic tree walking mechanism Delegations of authority Validating a RRset for from the root (. ) down Start at the root, which is a trust anchor Verify authenticity of delegation to nl. zone Verify authenticity of delegation to os3.nl. zone Verify authenticity of RRset for Source: Niels Sijm, CIA lecture

4 DNSSEC-bis resource records Signing Resource Record sets Resource Records used to build the chain of trust DNSKEY DNS (public) KEY belonging to a zone Used to verify signatures Root DNSKEY is well known DS Delegation Signer Contains the hash of the DNSKEY of a delegation (child) zone The DNSKEY hashed is a secure entry point (SEP) RRSIG Resource Record SIGnature Contains the signature of an RRset Source: Niels Sijm, CIA lecture Tree walking algorithm Query types used Validating delegation from. (root) to nl. zone (top down) 1 1. Signing key of root zone is known to the resolver 2. Ask. zone for DS of nl. zone 3. Ask nl. zone for DNSKEY of nl. zone 4. Verify that DS contains a valid hash of DNSKEY Two steps are missing Get the signatures of the DS record 6. Check that the DS record for nl. authentic Source: Niels Sijm, CIA lecture Ignoring KSKs and ZSKs for simplicity for now

5 Detailed tree walking algorithm (1) Detailed tree walking algorithm (2) 1. Retrieve DNSKEY for root zone Stored in resolver as a secure starting point Can also be retrieved from root nameservers dnskey 2. Ask root zone for the DS of the nl. zone Contains a hash of the DNSKEY of the nl. zone Stored in the root zone nl. ds 3. Ask nl. zone for DNSKEY of nl. zone dig [@ns1.dns.nl.] nl. dnskey 4. Verify that DS contains a valid hash of DNSKEY Create the hash of the DNSKEY RRset yourself Compare the result to the hash in the DS record Detailed tree walking algorithm (3) Multiple DNSKEY records Don t forget the following steps 5. Retrieve signature of nl. DS RRset Stored in root zone dig nl. ds Without the +dnssec flag you don t get the RRSIG info needed 6. Verify this signature using the root zone DNSKEY, thereby proving the authenticity of the DS record Zones tend to contain multiple DNSKEY records in the apex Usually there are at least two DNSKEYs A KSK (Key Signing Key) as secure entry point for chain of trust A ZSK (Zone Signing Key) for RRSIG creation A ZSK may change much more often than a KSK This is not necessary for DNSSEC operation It simplifies DNS key management

6 DNSSEC-bis chain of trust (1) DNSSEC-bis chain of trust (2) This time we present the algorithm more abstractly and bottom up To validate a resource record set RRset Validate RRSIG(RRset) by using a ZSK (zone signing key) from the DNSKEY RRset Validate RRSIG(DNSKEYset) by using a KSK (key signing key) from that same DNSKEY RRset Validate the KSK by using a DS (present in the parent zone) which contains a hash of the KSK the KSK used is called a SEP (Secure Entry Point) Continue validating one level higher in the hierarchy Use DS as RRset and iterate Use trusted anchors for DNSKEYs or DSs to terminate for instance for checking root zone keys Authority around a cut is now as follows NS and DNSKEY are authoritative on the child side of the cut (zone apex) DS is authoritative on the parent side of the cut (delegation point) Chain of trust illustration RRSIG record example from RFC Walking the Chain of Trust Locally configured Trusted key: $ORIGIN.. DNSKEY ( ) 5TQ3s (8907) ; KSK DNSKEY ( ) lase5 (2983) ; ZSK RRSIG DNSKEY ( ) Hw9.. net. DS ab15 RRSIG DS ( ) $ORIGIN ripe.net $ORIGIN net. net. DNSKEY ( ) q3dew (7834) ; KSK DNSKEY ( ) 5TQ3s (5612) ; ZSK RRSIG DNSKEY ( ) 7834 net. cmas... ripe.net. DS ab15 RRSIG DS ( ) net host.example.com IN RRSIG A ( example.com. ojb1w6wngv+ldvq3wdg0mqkg5iehjrip8wtr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) ripe.net. DNSKEY ( ) rwx002 (4252) ; KSK DNSKEY ( ) sovp42 (1111) ; ZSK 8 RRSIG DNSKEY ( ) 4252 ripe.net. 5t... A RRSIG A ( ) 1111 ripe.net. a Albuquerque Feb 2006 Source: Olaf Kolkman, RIPE NCC, NLnet Labs

7 RRSIG record content DNSKEY record example from RFC 4034 Part Type covered Algorithm Labels TTL Expiration and Inception Key Tag Signer s Name Signature Meaning Record type this RRSIG is about Signature algorithm used; 5 is RSA/SHA-1 Number of labels of owner (without root) Original time to live Signature validity date bounds To help find 2 (not identify) the signing key Owner name of zone and key to use Signature (in Base64) example.com IN DNSKEY ( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31gajiqky+5cptlr3buxa10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/TpPSEDhm2SNKLijfUppn1U anvv4w== ) 2 In fact it is a kind of checksum on the RDATA of the DNSKEY RR DNSKEY record content DS record example from RFC 4034 and 4509 Part Flags Protocol Algorithm Public key Meaning Zone key (KSK+ZSK); Secure entry point (KSK) Always 3 (for backward compatibility with KEY RR) Signature algorithm used; 5 is RSA/SHA-1 Key used for signing (in Base64) dskey.example.com IN DNSKEY ( AQOeiiR0GOMYkDshWoSKz9Xz fwjr1aytsmx3tgkjanxvbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egxd/m5+x7orzkbambcvdflu Uh6DhweJBjEVv5f2wwjM9Xzc nof+epbtg9dmbmadjfdc2w/r ljwvfw== ) ; key id = dskey.example.com IN DS ( 2BB183AF5F A53B0A98631FAD1A ) ; SHA-1 dskey.example.com IN DS ( D4B7D520E7BB5F0F67674A0C CEB1E3E0614B93C4F9E99B83 83F6A1E4469DA50A ) ; SHA-256

8 DS record content Part Key Tag Algorithm Digest Type Digest Meaning To help find (not identify) the signing key Signature algorithm of the signing key Hashing algorithm used; 1 is SHA-1, 2 is SHA-256 Sequence of case-insensitive hexadecimal digits