page 2 Rough Outline An introduction to DNSSEC Olaf Kolkman 21 September 2006 Stichting (www.nlnetlabs.nl) Introduction Why DNSSEC DNSSEC Theory Famous last words page 3 DNSSEC evangineers of the day Olaf: DNS and DNSSEC research Protocol and software development (NSD) Co-Chair of the IETF DNSEXT working group Member of the Internet Architecture Board DNSSEC experience since about 2001 DNSSEC deployment at RIPE NCC DNSSEC Howto Net::DNS::SEC extensions RFC 4641 on DNSSEC operations page 4 Why DNSSEC Introducing DNSSEC Based on material developed while I was with the RIPE NCC. They are acknowledged for allowing me to re-use this material page 6 The Material 21 September 2006 Stichting Good security is multi-layered Multiple defense rings in physical secured systems page 7 page 8 page 9 Why DNSSEC The Problem DNS data published by the registry is being replaced on its path between the server and the client. This can happen in multiple places in the DNS architecture Good security is multi-layered Multiple defense rings in physical secured systems Multiple layers in the networking world Some places are more vulnerable to attacks then others Vulnerabilities in DNS software make attacks easier (and there will always be software vulnerabilities) DNS infrastructure Providing DNSSEC to raise the barrier for DNS based attacks Provides a security ring around many systems and applications Bourtange, source Wikipedia 1
Solution a Metaphor Compare DNSSEC to a sealed transparent envelope. The seal is applied by whoever closes the envelope Anybody can read the message The seal is applied to the envelope, not to the message page 10 Registrars/ Registrants Registry DB primary edu as DNS provider secondary Provisioning DNS Protocol DNS Architecture edu as friend secondary page 11 edu institution as ISP Cache server client Registrars Registrants Registry DB Provisioning Inter-server communication DNS Architecture DNS Protocol Server compromise Cache Poisoning page 12 Subject: tenure Astrophysics Mail Server Where? Example: Unauthorized mail scanning There! Central Admin Mail Server page 13 Subject: tenure Astrophysics Mail Server Where? Example: Unauthorized mail scanning Elsewhere Central Admin Mail Server page 14 Where Does DNSSEC Come In? DNSSEC secures the name to address mapping Tranport and Application security are just other layers. page 15 DNS DNS Bad Guy Bad Guy DNSSEC secondary benefits DNSSEC provides an independent trust path The person administering https is most probably a different from person from the one that does DNSSEC The chains of trust are most probably different See acmqueue.org article: Is Hierarchical Public-Key Certification the Next Target for Hackers? page 16 More benefits? With reasonable confidence perform opportunistic key exchanges SSHFP and IPSECKEY Resource Records With DNSSEC one could use the DNS for a priori negotiation of security requirements. You can only access this service over a secure channel page 17 DNSSEC properties DNSSEC provides message authentication and integrity verification through cryptographic signatures Authentic DNS source No modifications between signing and validation It does not provide authorization It does not provide confidentiality page 18 2
Other DNS security We talked about data protection The sealed envelope technology RRSIG, DNSKEY, NSEC and DS RRs There is also a transport security component Useful for bilateral communication between machines TSIG or SIG0 page 19 DNSSEC is essential for good layered security DNS protocol intrinsically easy to attack DNSSEC and Transport security Securing Host- Host Communication 21 September 2006 Stichting 21 September 2006 Stichting Registrars Registrants Registry DB TSIG Protection page 22 AXFR and IXFR Queries to caching forwarers Transaction Signature: TSIG TSIG (RFC 2845) Authorising dynamic updates and zone transfers Authentication of caching forwarders Independent from other features of DNSSEC One-way hash function DNS question or answer and timestamp Traffic signed with shared secret key Used in configuration, NOT in zone file page 23 Slave KEY: %sgs!f23fv SOA SOA Sig... verification TSIG Example Query: AXFR AXFR AXFR Sig... Sig... Master KEY: %sgs!f23f SOA SOA Sig... page 24 verification Provisioning DNS Protocol dynamic updates Response: Zone TSIG for Zone Transfers 1. Generate secret 2. Communicate secret 3. Configure servers 4. Test page 25 Importance of the Time Stamp TSIG/SIG(0) signs a complete DNS request / response with time stamp To prevent replay attacks Currently hardcoded at five minutes Operational problems when comparing times Make sure your local time zone is properly defined date -u will give UTC time, easy to compare between the two systems Use NTP synchronisation! page 26 Authenticating Servers Using SIG(0) Alternatively, it is possible to use SIG(0) Not yet widely used Works well in dynamic update environment Public key algorithm Authentication against a public key published in the DNS SIG(0) specified in RFC 2931 page 27 3
Cool Application Use TSIG-ed dynamic updates to configure configure your laptops name My laptop is know by the name of grover.secret-wg.org http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html Mac OS users: there is a bonjour based tool. www.dns-sd.org page 28 TSIG/Sig(0) Generate secret Configure servers DNSSEC Mechanisms New Resource Records Setting Up a Secure Zone Delegating Signing Authority Key Rollovers 21 September 2006 Stichting 21 September 2006 Stichting page 31 page 32 page 33 Registrars Registrants DNSSEC protection DNSSEC hypersummary The DNS is Not a PKI Registry DB Provisioning envelope sealed DNS Protocol Seal checked Seal checked Data authenticity and integrity by signing the Resource Records Sets with private key Public DNSKEYs used to verify the RRSIGs Children sign their zones with their private key Authenticity of that key established by signature/checksum by the parent (DS) Ideal case: one public DNSKEY distributed All key procedures are based on local policy A PKI is as strong as its weakest link Certificate Authorities control this through SLAs The DNS does not have Certificate Revocation Lists If the domain is under one administrative control you might be able to enforce policy Public Key Crypto Key pair: a private (secret) key and a corresponding public key Simplified: If you know the public key, you can verify a signature created with the private key If you know the public key, you can encrypt data that can only be decrypted with the private key DNSSEC only uses signatures PGP uses both methods page 34 Security Status of Data (RFC4035) Secure Resolver is able to build a chain of signed DNSKEY and DS RRs from a trusted security anchor to the RRset Insecure Resolver knows that it has no chain of signed DNSKEY and DS RRs from any trusted starting point to the RRset Bogus Resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so May indicate an attack but may also indicate a configuration error or some form of data corruption Indeterminate Resolver is not able to determine whether the RRset should be signed page 35 21 September 2006 Stichting New Resource Records 4
page 37 page 38 page 39 RRs and RRSets Resource Record: name TTL class type rdata www.ripe.net. 7200 IN A 192.168.10.3 RRset: RRs with same name, class and type: www.ripe.net. 7200 IN A 192.168.10.3 A 10.0.0.3 A 172.25.215.2 RRSets are signed, not the individual RRs New Resource Records Three Public key crypto related RRs RRSIG Signature over RRset made using private key DNSKEY Public key, needed for verifying a RRSIG DS Delegation Signer; Pointer for building chains of authentication One RR for internal consistency NSEC Indicates which name is the next one in the zone and which typecodes are available for the current name authenticated non-existence of data DNSKEY RDATA 16 bits: FLAGS 8 bits: protocol 8 bits: algorithm N*32 bits: public key Example: ripe.net. 3600 IN DNSKEY 256 3 5 ( AQOvhvXXU61Pr8sCwELcqqq1g4JJ CALG4C9EtraBKVd +vgif/unwigfloa O3nHp/cgGrG6gJYe8OWKYNgq3kDChN) RRSIG RDATA 16 bits - type covered 8 bits - algorithm 8 bits - nr. labels covered 32 bits - original TTL ripe.net. 3600 IN RRSIG A 5 2 3600 ( 20050611144523 20050511144523 3112 ripe.net. VJ+8ijXvbrTLeoAiEk/qMrdudRnYZM1VlqhN vhyuacyke2x/jqyfmfjfsurmhpo+0/gozjw 66DJubZPmNSYXw== ) signature field 32 bit - signature expiration 32 bit - signature inception 16 bit - key tag signer s name page 40 Delegation Signer (DS) Delegation Signer (DS) RR indicates that: delegated zone is digitally signed indicated key is used for the delegated zone Parent is authorative for the DS of the child s zone Not for the NS record delegating the child s zone! DS should not be in the child s zone page 41 DS RDATA 16 bits: key tag 8 bits: algorithm 8 bits: digest type 20 bytes: SHA-1 Digest $ORIGIN ripe.net. disi.ripe.net. 3600 IN NS ns.disi.ripe.net disi.ripe.net. 3600 IN DS 3112 5 1 ( 239af98b923c023371b52 1g23b92da12f42162b1a9 ) page 42 page 43 page 44 page 45 NSEC RDATA NSEC Records NSEC Walk Points to the next domain name in the zone also lists what are all the existing RRs for name NSEC record for last name wraps around to first name in zone N*32 bit type bit map Used for authenticated denial-of-existence of data authenticated non-existence of TYPEs and labels Example: www.ripe.net. 3600 IN NSEC ripe.net. A RRSIG NSEC NSEC RR provides proof of non-existence If the servers response is Name Error (NXDOMAIN): One or more NSEC RRs indicate that the name or a wildcard expansion does not exist If the servers response is NOERROR: And empty answer section The NSEC proves that the QTYPE did not exist More than one NSEC may be required in response Wildcards NSEC records are generated by tools Tools also order the zone NSEC records allow for zone enumeration Providing privacy was not a requirement at the time Zone enumeration is a deployment barrier Work has started to study solutions Requirements are gathered If and when a solution is developed, it will co-exist with DNSSEC-BIS! 5
Current Developments NSEC3 being tested All RR names hashed Hashed names are ordered opt-out for unsecured delegations possibilities SHA1 to be deprecated New hash for DS records Overlap, no flag day page 46 Other Keys in the DNS DNSKEY RR can only be used for DNSSEC Keys for other applications need to use other RR types CERT For X.509 certificates Application keys under discussion/development IPSECKEY SSHFP page 47 DNSSEC not a PKI Zone status New RRs: DNSKEY, RRSIG, NSEC, DS 21 September 2006 Stichting Delegating Signing Authority Chains of Trust Locally Secured Zones Key distribution does not scale!. net. com. money.net. kids.net. os.net. Secure entry points corp dop marnick mac unix nt dev market dilbert Out of band key-exchanges page 50 Using the DNS to Distribute Keys Secured islands make key distribution problematic Distributing keys through DNS: Use one trusted key to establish authenticity of other keys Building chains of trust from the root down Parents need to sign the keys of their children Only the root key needed in ideal world Parents always delegate security to child page 51 21 September 2006 Stichting page 52 page 53 page 54 Key Problem Interaction with parent administratively expensive Should only be done when needed Bigger keys are better Signing zones should be fast Memory restrictions Space and time concerns Smaller keys with short lifetimes are better Key Functions Large keys are more secure Can be used longer Large signatures => large zonefiles Signing and verifying computationally expensive Small keys are fast Small signatures Signing and verifying less expensive Short lifetime Key solution: More Than One Key RRsets are signed, not RRs DS points to specific key Signature from that key over DNSKEY RRset transfers trust to all keys in DNSKEY RRset Key that DS points to only signs DNSKEY RRset Key Signing Key (KSK) Other keys in DNSKEY RRset sign entire zone Zone Signing Key (ZSK) 6
Walking the Chain of Trust page 55 Initial Key Exchange 1. 2 Child needs to: 4 RRSIG DNSKEY ( ) 8907. 69Hw9.. Send key signing keyset to parent 3 Parent needs to: net. DS 7834 3 1ab15 RRSIG DS ( ). 2983 $ORIGIN ripe.net. Check childs zone 5 7 $ORIGIN net. net. DNSKEY ( ) q3dew (7834) ; KSK DNS KEY ( ) 5TQ3s (5612) ; ZSK RRSIG DNSKEY ( ) 7834 net. cmas... ripe.net. DS 4252 3 1ab15 RRSIG DS ( ) net. 5612 6 Verify if key can be trusted Generate DS RR www.ripe.net. A 193.0.0.202 RRSIG A ( ) 1111 ripe.net. a3... if signed by the parents Zone-Signing-Key or DS or DNSKEY records can be trusted if exchanged outof-band and locally stored (Secure entry point) 9 page 59 Reflector attacks 21 September 2006 Stichting page 61 target src: resolver dst: target Answer from cache src: resolver dst: isp Recently Open recursive servers used to amplify traffic several Gbits/second traffic to critical infrastructure Source addresses at DDOS target are valid, packet format valid page 60 resolver DDOS and the DNS Scaling problem: secure islands Zone signing key, key signing key Chain of trust src: isp dst: resolver ISP page 63 an UDP problem Drop packets if source address is strange to the network src: target (spoof!) dst: resolver Remedy: Ingress filtering (BCP38) DNS has nice amplification characteristics closing open resolvers helps, but authoritative servers will do to You make the packets smaller? We ll just wake up more zombies Zombie botnet page 62 resolver page 57 Data in zone can be trusted if signed by a ZoneSigning-Key Zone-Signing-Keys can be trusted if signed by a KeySigning-Key Key-Signing-Key can be trusted if pointed to by trusted DS record DS record can be trusted ripe.net. DNSKEY ( ) rwx002 (4252) ; KSK DNSKEY ( ) sovp42 (1111) ; ZSK 8 RRSIG DNSKEY ( ) 4252 ripe.net. 5t... for DNSKEY & RRSIGs DNSKEY ( ) 5TQ3s (8907) ; KSK DNSKEY ( ) lase5 (2983) ; ZSK Chain of Trust Verification, page 56 Locally configured Trusted key:. 8907 $ORIGIN. Zombie botnet 7
page 64 page 66 Repeat: BCP38 http://www.ietf.org/rfc/rfc2827.txt(bcp38) Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing Deploy on your own networks Act responsibly in the Public Space Require deployment by others Part of procurement procedures Key Rollovers Private Keys You have to keep your private key secret Private key can be stolen Put the key on stand alone machines or on bastion hosts behind firewalls and strong access control Private key reconstruction (crypto analysis) Random number not random Leakage of key material (DSA) Brute force attacks 21 September 2006 Stichting Key Rollovers Try to minimise impact Short validity of signatures Regular key rollover Remember: DNSKEYs do not have timestamps the RRSIG over the DNSKEY has the timestamp Key rollover involves second party or parties: State to be maintained during rollover Operationally expensive page 67 Timing of the Scheduled Key Rollover Don t remove the old key while there servers are still handing out the old DS RR New DS needs to be distributed to the slaves Max time set by the SOA expiration time Old DS needs to have expired from caches Set by the TTL of the original DS RR You (or your tool) can check if the master and slave have picked up the change page 68 time 0 t 1 t 2 t 3 Timing Properties Authoritative Master Authoritative Slave Caching Nameserver Foo TXT Old Foo TXT Old Foo TXT New Zone synchronization Foo TXT Old Foo TXT New TTL Poof page 69 Publication of new data Query to slave followed by Caching Zone transfer Expiration From Cache Unscheduled Rollover Problems Needs out of band communication With parent and pre-configured resolvers The parent needs to establish your identity again How to protect child delegations? Unsecured? There will be a period that the stolen key can be used to generate seemingly secure data There is no revoke key mechanism Emergency procedure must be on the shelf page 70 Key Rollover - Generate new KSK Sign with old and new KSKs Wait for your servers + TTL of old DNSKEY RRset Inform resolvers of the new key that have you as a trusted entry point Query for the parental DS and remember the TTL Upload the new KSK or DS to the parent Check if *all* parental servers have new DS Wait another TTL before removing the old key page 71 Key size and signature lifetimes Key rollovers Emergency procedure 21 September 2006 Stichting 8
page 73 9