DNSSEC Lightweight Database Access Protocol Gateway

Abstract

A system that converts standardized lightweight database access protocol (LDAP) requests into a series of domain name system (DNS) requests to look up requested information. DNS responses are validated using DNS security extensions (DNSSEC) to ensure their validity, then converted into standardized LDAP responses. The system is either operated as a service for public use on the Internet or private use in an enterprise; or as an application running on end user machines, e.g., laptops, mobile phones, to guarantee end-to-end security by validating responses on the end user machine. The standardized, widespread nature of the LDAP allows existing applications to immediately reap the benefits of global, ubiquitous, cross-organizational, trans-national data distribution via DNS secured by DNSSEC.

Claims

1. A system to translate standardized lightweight database access protocol (LDAP) requests into domain name system (DNS) security extensions (DNSSEC) secured requests and back comprising: conversion of standardized LDAP requests into a series of DNS requests to ascertain the information sought in the original LDAP request; transmission of the request to the DNS; validating DNS responses using DNSSEC; discarding invalid DNSSEC responses and returning a LDAP error in response to the original LDAP request; converting validated DNSSEC responses into LDAP responses and returning them as responses to the original LDAP request.

2. The method of claim 1, further comprising generating responses to other non-information gathering, administrative, LDAP requests.

3. The method of claim 2, further comprising support for secure LDAP communications.

4. The method of claim 3, further comprising use of a public-private key pair to digitally re-sign information obtained from the DNS before incorporating into LDAP responses where the end user application uses the public half of the pair to verify information in the LDAP response.

5. The method of claim 4, where the system runs on an end user's device to guarantee security by validating DNS responses on the same device.

6. The method of claim 4, where the system is operated as a public or enterprise wide gateway where the operator and connection to the operator is trusted.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0006] FIG. 1 shows a diagram of a preferred embodiment of the present invention as part of an overall system.

PREFERRED EMBODIMENT

[0007] The preferred embodiment of the present invention consists of an email client (100) with built in support for LDAP (101) such as Microsoft Outlook. When the user enters an email address such as user1@zx.com, the email client asks preconfigured LDAP servers for further information on this email address which may include full name and cryptographic key information. The latter is what is necessary to encrypt email exchanges. The query (102) is typically made of existing corporate directories containing employee and specific client information. For a non-corporate email client as depicted on the left had side of FIG. 1, there is typically no such centralized, shared directory. In this case, the query (102) can be made of a public directory service or a virtual one implemented on the email client machine itself. If a public directory service is used, requests and responses traverse the Internet.

[0008] The preferred embodiment of the present invention spoofs the directory service (103), regardless of its location, by processing LDAP requests (102) and returning LDAP responses (111). It converts LDAP requests (102) into a series of DNSSEC requests (104) and converts corresponding DNSSEC responses (110) into LDAP responses (111) on the fly. The DNSSEC requests and responses travel over the Internet (105) and may involve multiple intermediate DNS servers and DNS resolution servers to eventual query (106) the authoritative DNS server responsible for the domain on the right hand side of the email address, in this case zx.com (108). This DNS server responds (109) either directly or via an intermediate DNS resolving server with the requested information to the directory server/gateway (103). The gateway ensures the response (110) has not been surreptitiously modified by using DNSSEC to validate the response. Once validated the gateway assembles and converts the format of these responses into a LDAP response (111) for the LDAP client (101) to provide the requested information to the email client (100).

[0009] Now armed with information associated with email address such as cryptographic keys, the user of the email client (100) can send encrypted email (112) to users using a corporate (107) email client (118), without having to first exchange keys between them or relying on a trusted third party authority and associated fees and management overhead. In the preferred embodiment, the gateway (103) would use its own key to vouch for the authenticity of email keys it has discovered and validated using DNSSEC. This single key would be used by the email client (100) to establish trust in the keys received via LDAP so that they may be used to encrypt transmission for remote addresses. The remote email client (118) is preconfigured to trust its own keys by virtue of being the source of those keys. Encryption protects the email from modification or viewing as it traverses the typical email path through mail servers (113,116), Internet (105) and corporate infrastructure (107).

[0010] The preferred embodiment should not be considered to exclude the wider claims of the present invention which include the translation of ANY current or future information made available in the DNS (protected by DNSSEC) into suitable LDAP requests and responses. The current set of standards in the IETF relying on DNSSEC as a secure transmission mechanism [1,2,3,4] are an indication of this growing list.

REFERENCES

[1] DNS-Based Authentication of Named Entities/DANE

[0011] https://tools.ietf.org/html/rfc6698
[2] Using Secure DNS to Associate Certificates with Domain Names For S/MIME
https://tools.ietf.org/html/draft-ietf-dane-smime-08

[3] Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints

[0012] https://tools.ietf.org/html/rfc4255
[4] TLS sessions in SIP using DNS-based Authentication of Named Entities (DANE) TLSA records
https://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-01