2011 Issue

48 DNSSEC is a promising solution to the problems suffered by legacy DNS, its certificates of authenticity and integrity can be forged. The Network Time Protocol (NTP) is a free and open source software (FOSS) time-keeping solution that provides an absolute time reference to a computer network from an atomic clock like the U.S. Naval Observatory. NTP has a network hierarchy similar to DNS using layers of stratum. NTP uses several tech- niques such as slewing and stepping to gradually adjust a server’s internal clock to an external time source. The NTP daemon can be run jointly with DNS- SEC to provide an absolute time stamp to the signature and inception fields of the RRSIG in DNSSEC. Research is currently being planned by the author to determine whether implementing absolute time stamps in DNSSEC can prevent man-in-the-middle attacks made possible by relative time stamps. More research is needed to address the chal- lenges that DNSSEC faces as the U.S. Federal Government relies on DNSSEC to shore up our nation’s information infrastructure against attacks. Associate Professor S. Jeff Cold teaches in the Information Systems & Technology Dept. at Utah Valley University. He is a Senior Member of the IEEE and a member of the IEEE Computer Society. He received the IEEE Utah Section Educator of the Year Award in 2010. I N THE EARLY 1980s when Dr. Paul V. Mockapetris proposed the DNS sys- tem in Requests for Comment (RFC) 882 and 883, Internet security was not a serious threat so there was no security built into DNS. DNS is vulnerable to cache poisoning, man-in-the-middle at- tacks, IP-spoofing for Dynamic DNS, and Distributed Denial-of-Service (DDOS) attacks, among others. Securing the infrastructure of the Inter- net has become an objective of the U.S. Federal Government since the passing of the E-Government Act of 2002. By December 2006, the National Institute for Standards and Technology (NIST) issued publication 800-53r1: Recom- mended Security Controls for Federal Information Systems. This publication mandated the installation of a secure version of DNS called the DNS Secu- rity Extensions (DNSSEC) protocol in “moderate” and “high” impact federal government Information Technology (IT) systems within one year. By 2009, NIST had established the Security Naming Infrastructure Pilot (SNIP) to promote DNSSEC and train federal Information Technology (IT) workers on how to imple- ment DNSSEC servers. The primary purpose of DNSSEC is to provide authentication and integrity for query responses received from the world-wide DNS database. Keys in pub- lic-key infrastructure (PKI) are used to generate signed certificates from DNS- SEC servers providing responses to que- ries from Internet clients or other DNS servers. In some PKI implementations, it is assumed that some universally trusted certification authority (like VeriSign) or some external database of public keys will be available (like a Web of Trust). In DNSSEC, public key distribution is a Catch 22. DNSSEC is the information provider, so the mechanism for public key distribution must be built-in. For DNSSEC, the design relies on the resolver trusting the zone’s public key. The parent zone validates the public key of its child zone. This trust is sup- posed to begin at the very top of the DNS hierarchy: the root servers. This is known as a trust anchor. Where no trust anchor exists in the cryptographic line of authority, the DNS response cannot be verified. In 2008, a study looking at the operational status of DNSSEC deploy- ment showed that as much as 97% of the DNSSEC zones were still unverifiable. In addition to the problem of unverifi- able DNSSEC responses, there exists another issue with its design. The way in which signed certificates are evaluated for acceptance between DNSSEC serv- ers and the Internet clients (resolvers) they serve is based on a relative time stamp: the current time relative from the UNIX epoch: January 1, 1970. DNSSEC does not have an internal time clock built into its protocol. Incorrect time stamps can cause a vulnerability known as a replay attack. A replay attack is a type of a man-in-the-middle attack where a certificate is captured, forged, and then replayed. It is possible that the resolver would accept a tainted response as valid and reject the original response as cor- rupted, based on the time stamp of the certificate. This means that although Domain Name Services Security Extensions and the Time Stamp Problem S. Jeff Cold Traditional Domain name Services (DnS) has been part of the Internet infrastructure since the beginning of the Internet. Every time email is sent, a web page is retrieved, or a file is downloaded, a DnS server is queried by an Internet client to resolve the Internet Protocol (IP) address of the host. Cold