Transcript 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.
– Each zone is authoritative
for its local data.
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
DNS resolving
Question: www.cnn.com
.
www.cnn.com A ?
dns.cs.umass.edu
lab.cs.umass.edu
stub
resolver
ask .com server
the ip address of .com server
www.cnn.com A ?
xxx.xxx.xxx.xxx
resolver
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
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
•
•
•
•
•
•
•
Focus on vulnerabilities
Cache impersonation
Corrupting data
Impersonating master
Zone
administrator
Zone file
master
Dynamic
updates
slaves
resolver
stub resolver
Unauthorized updates
Server
Protection
Cache pollution by
Data spoofing
Data
Protection
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.
Simple attack
Easy to observe UDP DNS query sent to
well known server on well known port.
www.darpa.mil A?
Root DNS Server
www.darpa.mil
A 192.5.18.19
Doug’s
Laptop
www.darpa.mil
A 128.9.128.127
Caching
DNS Server
mil DNS Server
Dan’s
Laptop
First response wins. Second response is
silently dropped on the floor.
darpa.mil DNS Server
More complex attack
DARPA
Caching Server
Response
www.attacker.com
attacker.com
attacker.com
ns.attacker.com
www.google.com
www.google.com
= 128.9.128.127
A 128.9.128.127
NS ns.attacker.com
NS www.google.com
A 128.9.128.2
A 128.9.128.127
ns.attacker.com
Query
www.attacker.com
Query www.google.com
Any DARPA Computer
Remote attacker
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.
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.
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
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
Main Goal of DNSSEC
• a) origin authentication of DNS data,
• b) data integrity
• c) authenticated denial of existence.
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
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)
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
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.
freeswan.nl.
freeswan.nl.
3600 IN NS ns.xtdnet.nl.
3600 IN NS ns1.xtdnet.nl.
3600 IN SIG NS 5 2 3600 20030506165654 (
20030406165654 56954 freeswan.nl.
bTKJvyrwmP+nsFoE8oelC4gFqoyJxkawNIExMVupI+ie
NeyUYdkrpDVBF5yn7U0dLxQu/+wqbOGYjPWx/r1ybZF7
JMd1PRefb30TsBtsrA9Ah13EKmO18oyJEZdDWwPV )
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.
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
The DS record
Sign 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.
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.
THANK YOU
QUESTIONS ?