Enabling Practical IPsec authentication for the Internet

On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops (First International Workshop on Information Security (IS'06), OTM Federated Conferences and workshops). Montpellier, Oct,/Nov. 2006There is a strong consensus about the need for IPsec, although its use is not widespread for end-to-end communications. One of the main reasons for this is the difficulty for authenticating two end-hosts that do not share a secret or do not rely on a common Certification Authority. In this paper we propose a modification to IKE to use reverse DNS and DNSSEC (named DNSSEC-to-IKE) to provide end-to-end authentication to Internet hosts that do not share any secret, without requiring the deployment of a new infrastructure. We perform a comparative analysis in terms of requirements, provided security and performance with state-of-the-art IKE authentication methods and with a recent proposal for IPv6 based on CGA. We conclude that DNSSEC-to-IKE enables the use of IPsec in a broad range of scenarios in which it was not applicable, at the price of offering slightly less security and incurring in higher performance costs.Universidad de Montpellier IIPublicad

Roll, Roll, Roll your Root:A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover

The DNS Security Extensions (DNSSEC) add authenticity and integrity to the naming system of the Internet. Resolvers that validate information in the DNS need to know the cryptographic public key used to sign the root zone of the DNS. Eight years after its introduction and one year after the originally scheduled date, this key was replaced by ICANN for the first time in October 2018. ICANN considered this event, called a rollover, "an overwhelming success" and during the rollover they detected "no significant outages". In this paper, we independently follow the process of the rollover starting from the events that led to its postponement in 2017 until the removal of the old key in 2019. We collected data from multiple vantage points in the DNS ecosystem for the entire duration of the rollover process. Using this data, we study key events of the rollover. These events include telemetry signals that led to the rollover being postponed, a near real-time view of the actual rollover in resolvers and a significant increase in queries to the root of the DNS once the old key was revoked. Our analysis contributes significantly to identifying the causes of challenges observed during the rollover. We show that while from an end-user perspective, the roll indeed passed without major problems, there are many opportunities for improvement and important lessons to be learned from events that occurred over the entire duration of the rollover. Based on these lessons, we propose improvements to the process for future rollovers

Consequences of compromised zone keys in DNSSEC

The Domain Name System is a distributed tree-based database. The DNS protocol is largely used to translate a human readable machine name into an IP address. The DNS security extensions (DNSSEC) has been designed to protect the DNS protocol. DNSSEC uses public key cryptography and digital signatures. A secure DNS zone owns at least a key pair (public/private) to provide two security services: data integrity and authentication. To trust some DNS data, a DNS client has to verify the signature of this data with the right zone key. This verification is based on the establishment of a chain of trust between secure zones. To build this chain of trust, a DNSSEC client needs a secure entry point: a zone key configured as trusted in the client. And then, the client must find a secure path from a secure entry point to the queried DNS resource. Zone keys are critical in DNSSEC and are used in every steps of a name resolution. In this report, we present a study on consequences of a compromised key in DNSSEC. We describe compromised key attacks and we present current defenses. \\ Le sytème de noms de domaine est une base de donnée distribuée basée sur un modèle arborescent. Le protocole DNS est largement utilisé pour effectuer essentiellement la correspondance entre un nom de machine et son adresse IP. Les extensions de sécurité du DNS (DNSSEC) ont été conçues pour protéger ce protocole. Pour cela, DNSSEC utilise la cryptographie à clé publique ainsi que des signatures numériques. Une zone DNSSEC possède au moins une paire de clés (publique/privée) pour signer ses données DNS et fournir ainsi deux services de sécurité essentiels\,: l'intégrité et l'authenticité des données. Pour faire confiance à des données DNS, un client DNSSEC doit en vérifier les signatures numériques avec la clé de zone appropriée. Cette vérification est basée sur l'établissement d'une chaîne de confiance entre des zones sécurisées. Pour construire cette chaîne, le client a besoin d'un point d'entrée sécurisé\,: une clé de zone configurée dans le client comme clé de confiance. Puis, le client doit trouver un chemin sécurisé partant de ce point jusqu'aux données DNS demandées. Les clés de zones sont essentielles au fonctionnement de DNSSEC et sont utilisées dans toutes les étapes d'une résolution de nom. Dans ce papier, nous présentons une étude des conséquences d'une clé compromise sur le protocole DNSSEC. Nous décrivons les attaques pouvant être mener grâce à une clé compromise et nous présentons les défenses possibles

Search for Trust: An Analysis and Comparison of CA System Alternatives and Enhancements

The security of the Public Key Infrastructure has been reevaluated in response to Certification Authority (CA) compromise which resulted in the circulation of fraudulent certificates. These rogue certificates can and have been used to execute Man-in-the-Middle attacks and gain access to users’ sensitive information. In wake of these events, there has been a call for change to the extent of either securing the current system or altogether replacing it with an alternative design. This paper will explore the following proposals which have been put forth to replace or improve the CA system with the goal of aiding in the prevention and detection of MITM attacks and improving the trust infrastructure: Convergence, Perspectives, Mutually Endorsed Certification Authority Infrastructure (MECAI), DNS-Based Authentication of Named Entities (DANE), DNS Certification Authority Authorization (CAA) Resource Records, Public Key Pinning, Sovereign Keys, and Certificate Transparency. Provided are brief descriptions of each proposal, along with an indication of the pros and cons of each system. Following this, a new metric is applied which, according to a set of criteria, ranks each proposal and gives readers an idea of the costs and benefits of implementing the proposed system and the potential strengths and weaknesses of the design. We conclude with recommendations for further research and remark on the proposals with the most potential going forward