DNS Security Extensions

Name servers are (relatively) easily spoofed. – Security ... time according to a mathematical formula ..... Our authoritative name servers need the zone's.
527KB taille 2 téléchargements 337 vues
The DNS Security Extensions Cricket Liu Acme Byte & Wire [email protected] www.acmebw.com Copyright © 1999 Acme Byte & Wire LLC

DNS Security Today • Name servers are subject to many types of attacks – Denial of service – Buffer overruns – As new attacks are discovered, they are patched

• Name servers are (relatively) easily spoofed – Security measures (e.g., access lists) and mechanisms (e.g., credibility) can make spoofing more difficult, but not impossible

Copyright © 1999 Acme Byte & Wire LLC

Enter DNSSEC • DNSSEC, the DNS Security Extensions, augments the current DNS standard to add – Data origin authentication and – Data integrity checking

• DNSSEC is described in RFC 2065 • DNSSEC doesn’t address attacks against the server itself

Copyright © 1999 Acme Byte & Wire LLC

Digital Signatures • DNSSEC supports data origin authentication and data integrity checking through the use of digital signatures • Digital signatures use public key cryptography to prove that a specific set of data (like resource records in a zone) was created or vouched for as authentic by a particular person (say the zone’s administrator)

Copyright © 1999 Acme Byte & Wire LLC

Public Key Cryptography • To understand digital signatures, you must understand a little about public key cryptography • The magic of public key cryptography is the key pair – A key pair is two numbers, derived at the same time according to a mathematical formula – Given one key, you can’t figure out what the other is – Data that is encrypted using one key must be decrypted using the other, and vice versa

Copyright © 1999 Acme Byte & Wire LLC

Public Key Cryptography – One key, called the private key, is kept, well, private – The other key, called the public key, is made public

Copyright © 1999 Acme Byte & Wire LLC

Signing • If you encrypt data with your private key, anyone who has access to your public key can decrypt it – So the data isn’t private – However, since you’ve kept the private key to yourself, and no one can deduce the private key from the public key, the fact that it decrypts correctly proves that you, the holder of the private key, encrypted it – This is called signing

Copyright © 1999 Acme Byte & Wire LLC

Performance • Unfortunately, encrypting everything to sign it just isn’t practical – Encryption, particularly in public key cryptography, is a slow, resource-intensive process • The more data you want to encrypt, the longer it takes

• Consequently, we usually run data through a secure hash algorithm before encrypting it

Copyright © 1999 Acme Byte & Wire LLC

Secure Hash Algorithms • Secure hash algorithms compute a fixed-size number (say 128 bits) no matter how much data you shove through them – The number, called the hash value, depends on each bit of the input – Vary the input by a single bit, and the hash value changes dramatically

Copyright © 1999 Acme Byte & Wire LLC

Secure Hash Algorithms – With a good secure hash algorithm, it is “computationally infeasible” • ...given a value, to find data that hashes to a that value • ...to find two different sets of data that hash to the same value

– Therefore, the hash value is like a fingerprint that represents exactly the source data, but in a distilled form

Copyright © 1999 Acme Byte & Wire LLC

Using Secure Hash Algorithms • So before signing data (encrypting it with our private key), we first distill it by running it through a secure hash algorithm – This means the encryption process will take less time and fewer resources

• The result, a relatively small amount of encrypted data, is called a digital signature – The digital signature is usually appended to the data its authenticates

Copyright © 1999 Acme Byte & Wire LLC

Verifying Digital Signatures • To verify a digital signature, the recipient retrieves the public key of the alleged signer • The recipient then decrypts the digital signature with that public key, to find an ostensible hash value • The recipient then runs the data through the same secure hash algorithm the signer used – If the value matches the decrypted value, the data is verified – If the value doesn’t match the decrypted value, the data is bogus Copyright © 1999 Acme Byte & Wire LLC

What Verification Proves • Verifying a signature proves – that a person with the private key really did sign the data (or else the digital signature wouldn’t have decrypted under the corresponding public key) – that the data that accompanied the digital signature hasn’t been modified since the signer signed it (or else the decrypted hash value wouldn’t match the recalculated hash value)

Copyright © 1999 Acme Byte & Wire LLC

Public Key Cryptography Illustrated encrypt private

Signing data

signed data key decrypt public

Verifying signed data

key

Copyright © 1999 Acme Byte & Wire LLC

authenticated data

DNS Digital Signatures • In DNSSEC, each zone has its own public and private key • The zone’s private key is used to sign each RRset in the zone – An RRset comprises all resource records with the same owner, class and type • For example, all IN class A RRs for www.acmebw.com

– The digital signature for the RRset is added to the zone in the form of a new record type, called a SIG record

Copyright © 1999 Acme Byte & Wire LLC

DNS Digital Signatures • The zone’s public key is stored in another new record type, called a KEY record – The zone’s KEY record is signed, too, by the zone’s parent – This allows a name server that knows the parent zone’s public key to discover the subzone’s public key and verify it

Copyright © 1999 Acme Byte & Wire LLC

Verifying DNS Digital Signatures • A name server or resolver that looks up records in a signed zone will get back a response that includes the SIG record that corresponds to the records in the answer • The name server or resolver can then retrieve the KEY record for the zone and verify it • Once the name server or resolver has verified the KEY record, it can decrypt the digital signature in the SIG record to get the ostensible hash value, recalculate the hash value, and compare the two

Copyright © 1999 Acme Byte & Wire LLC

What Verification Proves • Verifying the DNS data – proves that the records your name server looked up really came from the right zone • For example, that the address of www.acmebw.com really came from the One True acmebw.com zone

– proves the data hasn’t been modified since it was signed

Copyright © 1999 Acme Byte & Wire LLC

Proving Something Doesn’t Exist • Traditionally, name servers have responded with NXDOMAIN or NOERROR/0 answers when an RRset didn’t exist • Proving cryptographically that the RRset doesn’t exist, however, requires something to sign – That something is a NXT record

Copyright © 1999 Acme Byte & Wire LLC

The NXT Record • The NXT record spans a gap between two domain names in a zone – The NXT record is attached to the first domain name, and specifies what record types exist for the domain name – The NXT record also specifies the next (hence “NXT”) domain name in the zone – Obviously, the notion of a “next”record implies a canonical order to the records in a zone – NXT records are added automatically during the DNS signing process

Copyright © 1999 Acme Byte & Wire LLC

Ordered Zones • To support NXT records, the records in a zone have a canonical order – Labels in a domain name are sorted by • shifting all characters to lowercase • sorting non-existent bytes ahead of “0” • sorting lexicographically from the highest-level label to the lowest

Copyright © 1999 Acme Byte & Wire LLC

Ordering a Zone • So the following example zone: test.com.

IN SOA ns.test.com. 99021800 1h 10m 30d 1d ) IN IN IN

NS A MX

ns.test.com. 10.0.0.1 0 mail.test.com.

ns mail www ftp west ns.west

IN IN IN IN IN IN

A A A CNAME NS A

10.0.0.1 10.0.0.2 10.0.0.3 www.test.com. ns.west.test.com. 10.0.0.5

east ns.east

IN IN

NS A

ns.east.test.com. 10.0.0.6

Copyright © 1999 Acme Byte & Wire LLC

root.test.com.

(

Ordering a Zone • Would sort to: test.com.

IN SOA ns.test.com. 99021800 1h 10m 30d 1d ) test.com. IN NS ns.test.com. test.com. IN A 10.0.0.1 test.com. IN MX 0 mail.test.com. east.test.com. IN NS ns.east.test.com. ns.east.test.com. IN A 10.0.0.6 ftp.test.com. IN CNAME www.test.com. mail.test.com. IN A 10.0.0.2 ns.test.com. IN A 10.0.0.1 west.test.com. IN NS ns.west.test.com. ns.west.test.com. IN A 10.0.0.5 www.test.com. IN A 10.0.0.3

Copyright © 1999 Acme Byte & Wire LLC

root.test.com.

(

Adding NXT Records • And here’s the zone with NXT records added: test.com. test.com. test.com. test.com. test.com. east.test.com. east.test.com. ns.east.test.com. ns.east.test.com. ftp.test.com. ftp.test.com. mail.test.com. mail.test.com. ns.test.com. ns.test.com. west.test.com. west.test.com. ns.west.test.com. ns.west.test.com. www.test.com. www.test.com.

IN SOA ns.test.com. root.test.com. 99021800 1h 10m 30d 1d ) IN NS ns.test.com. IN A 10.0.0.1 IN MX 0 mail.test.com. IN NXT east.test.com. A NS SOA MX NXT IN NS ns.east.test.com. IN NXT ns.east.test.com. NS NXT IN A 10.0.0.6 IN NXT ftp.test.com. A NXT IN CNAME www.test.com. IN NXT mail.test.com. CNAME NXT IN A 10.0.0.2 IN NXT ns.test.com. A NXT IN A 10.0.0.1 IN NXT west.test.com. A NXT IN NS ns.west.test.com. IN NXT ns.west.test.com. NS NXT IN A 10.0.0.5 IN NXT www.test.com. A NXT IN A 10.0.0.3 IN NXT test.com. A NXT

Copyright © 1999 Acme Byte & Wire LLC

(

Notes on NXT • CNAMEs now can have other data (NXTs, SIGs and KEYs) • The final NXT “wraps around”from the last name in the ordered zone to the first • In a signed zone, each NXT record would have a corresponding SIG

Copyright © 1999 Acme Byte & Wire LLC

Notes on NXT • If you tried to look up north.test.com, you’d get back: mail.test.com.

IN

NXT

ns.test.com. A NXT

and its SIG, showing that there are no domain names in the zone between mail.test.com and ns.test.com, and hence no north.test.com • If you tried to look up MX records for mail.test.com, you’d get the same NXT record back, showing that there are only A and NXT records for that domain name

Copyright © 1999 Acme Byte & Wire LLC

Our Zone • Here’s the zone we’ll use to demonstrate how to sign zones with BIND 8.2: $ cat db.acmebw acmebw.com.

IN SOA

www ftp huskymo littlemiss walterb

IN NS IN NS IN NS IN A IN MX IN MX CNAME CNAME A A A

IN IN IN IN IN

speakeasy.mspring.net. dnshelp.mindspring.com. ( 1999021701 ; serial 1H ; refresh 10M ; retry 4w2d ; expiry 1D ) ; default TTL speakeasy.mspring.net. hearsay.mspring.net. rumor.mspring.net. 207.69.209.143 0 @ 10 store-forward.mspring.net. acmebw.com. acmebw.com. 206.168.119.178 206.168.119.179 206.168.119.180

Copyright © 1999 Acme Byte & Wire LLC

Step 1: Generate the Key Pair • First, generate the zone’s key pair: # bind-8.2-T5B/src/bin/dnskeygen/dnskeygen -D 640 -z -n acmebw.com. Generating 640 bit DSS Key for acmebw.com. Generated 640 bit Key for acmebw.com. id=49292 alg=3 flags=16641

• This generates a 640 bit DSA (-D 640) key pair for the zone (-z) named acmebw.com (-n acmebw.com.) • Remember the ID – We’ll use it later to specify this particular key – It’s also part of the name of the file that stores the key, in case we forget it Copyright © 1999 Acme Byte & Wire LLC

Step 2: Check the Keys • Next, check that the keys were created: # ls K* Kacmebw.com.+003+49292.key Kacmebw.com.+003+49292.private # cat Kacmebw.com.+003+49292.key acmebw.com. IN KEY 16641 3 3 AvqyXgKk/uguxkJF/hbRpYzxZFG3x8EfNX389l7GX6w7rlLyBJ14TqvrDvXr84XsShg+OFcUJafNr84U4ER2dg6NrlR AmZA1jFfV0UpWDWcHBR2jJnvgV9zJB2ULMGJheDHeyztM1KGd2oGkAensm74NlfUqKzy/3KZ9KnQmEpj/EEBr48vAsg AT9kMjN+V3NgAwfoqgS0dwj5OiRJoIR4+cdRt+s32OUKsclAODFZTdtxRnvXF3qYV0S8oewMbEwh3trXi1c7nDMQC3R moY8RVGt5U6LMAQKITDyHU3VmRJ36vn77QqSzbeUPz8zEnbpik8kHPykJZFkcyjjZoHT1xkJ1tk # cat Kacmebw.com.+003+49292.private Private-key-format: v1.1 Algorithm: 3 (DSA) Prime(p): x8EfNX389l7GX6w7rlLyBJ14TqvrDvXr84XsShg+OFcUJafNr84U4ER2dg6NrlRAmZA1jFfV0UpWDWcHBR2jJnvgV9z JB2ULMGJheDHeyzs= Subprime(q): +rJeAqT+6C7GQkX+FtGljPFkUbc= Base(g): TNShndqBpAHp7Ju+DZX1Kis8v9ymfSp0JhKY/xBAa+PLwLIAE/ZDIzfldzYAMH6KoEtHcI+TokSaCEePnHUbfrN9jlC rHJQDgxWU3bcUZ70= Private_value(x): grRckH72K8Tr65tHcMUMNFnYfsU= Public_value(y): cXephXRLyh7AxsTCHe2teLVzucMxALdGahjxFUa3lToswBAohMPIdTdWZEnfq+fvtCpLNt5Q/PzMSdumKTyQc/KQlkW RzKONmgdPXGQnW2Q=

Copyright © 1999 Acme Byte & Wire LLC

Step 3: Append the KEY Record • Notice that the .key file contains a KEY record • Append the new KEY record to the zone data file: # cat Kacmebw.com.+003+49292.key >> db.acmebw

Copyright © 1999 Acme Byte & Wire LLC

Step 4: Send the Zone’s Public Key to Your Superzone to Sign • Since our zone’s KEY record needs to be signed by our superzone’s private key, we need to send it to them to sign: # mail -s ‘acmebw.com KEY RR needs signing’ [email protected] Hi, Mr. Hostmaster. Attached please find the KEY RR for the zone acmebw.com. Would you please sign it with the com zone’s private key and send me the results? Thanks, Cricket ~r /var/named/Kacmebw.com.+003+49292.key "/var/named/Kacmebw.com.+003+49292.key" 1/378

• Actually, the InterNIC doesn’t sign KEY records yet, so don’t bother sending them any • Also, when they do start signing keys, you’ll undoubtedly need to do more than send email to prove who you are Copyright © 1999 Acme Byte & Wire LLC

Step 5: Sign the Zone • Now we can sign the zone: # bind-8.2-T5B/contrib/dns_signer/signer/dnssigner -or acmebw.com. -zi db.acmebw \ -zo db.acmebw.signed -k1 acmebw.com dsa 49292 -st Time statistics Run begun: Wed, 02/17/99 03:35:59 PM Tree finished: Wed, 02/17/99 03:35:59 PM Signing started: Wed, 02/17/99 03:35:59 PM Run ended: Wed, 02/17/99 03:36:01 PM Search space statistics Names read: Names in zone: Sets read: Records read/written Records read: Signatures gain or loss NXTs gain or loss Records written: NXT statistics NXTs dropped: NXTs added: Signature statistics Sigs added: Sigs written:

6 6 10 13 15 6 34 0 6 15 (inserted) 15 (= retained + inserted)

Copyright © 1999 Acme Byte & Wire LLC

Step 6: Examine the Zone • The new zone data file should look something like this (the beginning, anyway): # more db.acmebw.signed ; Generated by dns_signer dated July 17, 1998 $ORIGIN acmebw.com. acmebw.com. 86400 IN SOA speakeasy.mspring.net. dnshelp.mindspring.com. ( 1999021701 ; serial 1H ; refresh 10M ; retry 4w2d ; expiry 1D ) ; minimum SIG SOA 3 86400 19990320224141 19990217224141 49292 acmebw.com. ( AnnwKotKk32dqs8m0SGczcquji9HJw9ysUveQ4qJNpP+ppyr +J/BrX0= ) acmebw.com. KEY 0x4101 3 3 ( AvqyXgKk/uguxkJF/hbRpYzxZFG3x8EfNX389l7GX6w7rlLy BJ14TqvrDvXr84XsShg+OFcUJafNr84U4ER2dg6NrlRAmZA1 jFfV0UpWDWcHBR2jJnvgV9zJB2ULMGJheDHeyztM1KGd2oGk Aensm74NlfUqKzy/3KZ9KnQmEpj/EEBr48vAsgAT9kMjN+V3 NgAwfoqgS0dwj5OiRJoIR4+cdRt+s32OUKsclAODFZTdtxRn vXF3qYV0S8oewMbEwh3trXi1c7nDMQC3RmoY8RVGt5U6LMAQ KITDyHU3VmRJ36vn77QqSzbeUPz8zEnbpik8kHPykJZFkcyj jZoHT1xkJ1tk )

Copyright © 1999 Acme Byte & Wire LLC

The KEY Record • Here’s the KEY record from the file: acmebw.com.

KEY 0x4101 3 3 ( AvqyXgKk/uguxkJF/hbRpYzxZFG3x8EfNX389l7GX6w7rlLy BJ14TqvrDvXr84XsShg+OFcUJafNr84U4ER2dg6NrlRAmZA1 jFfV0UpWDWcHBR2jJnvgV9zJB2ULMGJheDHeyztM1KGd2oGk Aensm74NlfUqKzy/3KZ9KnQmEpj/EEBr48vAsgAT9kMjN+V3 NgAwfoqgS0dwj5OiRJoIR4+cdRt+s32OUKsclAODFZTdtxRn vXF3qYV0S8oewMbEwh3trXi1c7nDMQC3RmoY8RVGt5U6LMAQ KITDyHU3VmRJ36vn77QqSzbeUPz8zEnbpik8kHPykJZFkcyj jZoHT1xkJ1tk )

• The KEY record’s fields are: – 0x4101, the flags field (use for confidentiality prohibited, zone key, valid for signing) – 3, the protocol octet (DNSSEC) – 3, the KEY algorithm number (DSA) – The public key itself Copyright © 1999 Acme Byte & Wire LLC

The SIG Record • Here’s the SOA record and its SIG record from the file: acmebw.com.

SIG

86400 IN

SOA speakeasy.mspring.net. dnshelp.mindspring.com. ( 1999021701 ; serial 1H ; refresh 10M ; retry 4w2d ; expiry 1D ) ; minimum SOA 3 86400 19990320224141 19990217224141 49292 acmebw.com. ( AnnwKotKk32dqs8m0SGczcquji9HJw9ysUveQ4qJNpP+ppyr +J/BrX0= )

Copyright © 1999 Acme Byte & Wire LLC

The SIG Record • The SIG record’s fields are: – SOA, the type of records signed – 3, the digital signature algorithm used (DSA) – 86400, the original time to live on the records signed – 19990320224141, when the signature expires – 19990217224141, when the records were signed – 49292, the key footprint – acmebw.com., the signer’s name – “AnnwKotKk32dqs8m0SGczcquji9HJw9ysUveQ4 qJNpP+ppyr+J/BrX0=“, the digital signature itself Copyright © 1999 Acme Byte & Wire LLC

Step 7: Configure Authoritative Name Servers with the Public Key • Our authoritative name servers need the zone’s public key so they can verify the zone’s records when they load them. • We can get the public key from the .key file zone “acmebw.com” { type master; file “db.acmebw.signed”; pubkey 16641 3 3 “AvqyXgKk/uguxkJF/hbRpYzxZFG3x8EfNX389l7GX6w7rlLyBJ1 4TqvrDvXr84XsShg+OFcUJafNr84U4ER2dg6NrlRAmZA1jFfV0UpWDWcHBR2jJnvgV9zJB2ULMGJheDH eyztM1KGd2oGkAensm74NlfUqKzy/3KZ9KnQmEpj/EEBr48vAsgAT9kMjN+V3NgAwfoqgS0dwj5OiRJo IR4+cdRt+s32OUKsclAODFZTdtxRnvXF3qYV0S8oewMbEwh3trXi1c7nDMQC3RmoY8RVGt5U6LMAQKIT DyHU3VmRJ36vn77QqSzbeUPz8zEnbpik8kHPykJZFkcyjjZoHT1xkJ1tk”; };

Copyright © 1999 Acme Byte & Wire LLC

Step 8: Examine Our Superzone’s SIG • Now we receive a SIG record from the administrator of our superzone, signing our zone’s KEY record with the superzone’s private key • First we examine what they’ve sent us: acmebw.com.

KEY 0x4101 3 3 ( AvqyXgKk/uguxkJF/hbRpYzxZFG3x8EfNX389l7GX6w7rlLy BJ14TqvrDvXr84XsShg+OFcUJafNr84U4ER2dg6NrlRAmZA1 jFfV0UpWDWcHBR2jJnvgV9zJB2ULMGJheDHeyztM1KGd2oGk Aensm74NlfUqKzy/3KZ9KnQmEpj/EEBr48vAsgAT9kMjN+V3 NgAwfoqgS0dwj5OiRJoIR4+cdRt+s32OUKsclAODFZTdtxRn vXF3qYV0S8oewMbEwh3trXi1c7nDMQC3RmoY8RVGt5U6LMAQ KITDyHU3VmRJ36vn77QqSzbeUPz8zEnbpik8kHPykJZFkcyj jZoHT1xkJ1tk ) SIG KEY 3 86400 19990321010705 19990218010705 4932 com. ( Am3tWJzEDzfU1xwg7hzkiJ0+8UQaPtlJhUpQx1snKpDUqZxm igMZEVk= )

Copyright © 1999 Acme Byte & Wire LLC

Step 9: Incorporate Our Superzone’s SIG • If the SIG record looks good, we store this into a file and incorporate it into our signed zone: # bind-8.2-T5B/contrib/dns_signer/signer/dnssigner -or acmebw.com. -zi db.acmebw.signed \ -pi acmebw.signed.key -zo db.acmebw.final

Copyright © 1999 Acme Byte & Wire LLC

Step 10: Review the Finished Zone Finally, we review the finished zone: ; Generated by dns_signer dated July 17, 1998 $ORIGIN acmebw.com. acmebw.com. 86400 IN SOA speakeasy.mspring.net. dnshelp.mindspring.com. ( 1999021701 ; serial 1H ; refresh 10M ; retry 4w2d ; expiry 1D ) ; minimum SIG SOA 3 86400 19990320224141 19990217224141 49292 acmebw.com. ( AnnwKotKk32dqs8m0SGczcquji9HJw9ysUveQ4qJNpP+ppyr +J/BrX0= ) acmebw.com. KEY 0x4101 3 3 ( AvqyXgKk/uguxkJF/hbRpYzxZFG3x8EfNX389l7GX6w7rlLy BJ14TqvrDvXr84XsShg+OFcUJafNr84U4ER2dg6NrlRAmZA1 jFfV0UpWDWcHBR2jJnvgV9zJB2ULMGJheDHeyztM1KGd2oGk Aensm74NlfUqKzy/3KZ9KnQmEpj/EEBr48vAsgAT9kMjN+V3 NgAwfoqgS0dwj5OiRJoIR4+cdRt+s32OUKsclAODFZTdtxRn vXF3qYV0S8oewMbEwh3trXi1c7nDMQC3RmoY8RVGt5U6LMAQ KITDyHU3VmRJ36vn77QqSzbeUPz8zEnbpik8kHPykJZFkcyj jZoHT1xkJ1tk ) SIG KEY 3 86400 19990321010705 19990218010705 4932 com. ( Am3tWJzEDzfU1xwg7hzkiJ0+8UQaPtlJhUpQx1snKpDUqZxm igMZEVk= ) Copyright © 1999 Acme Byte & Wire LLC