Paper 5
Layering Public Key Distribution Over Secure DNS
using Authenticated Delegation
ACSAC 2005
Why?
To me, key distribution seems to be holding up the whole world of
secure networking.
I was curious as to how their approach differed from others
and whether it seemed to work.
Quick Assessment
Their work looks really nice.
I think it is a nice approach to distributing keys.
The premise of the paper is set up in the summary:
Powerful cryptographic tools exist to address security
and privacy concerns, but have not been widely used since
NO CONVENIENT INFRASTRUCTURES IS AVAILABLE FOR AUTHENTICATED
KEY DISTRIBUTION.
IKS (Internet Key Service) is
a simple, scalable public key distribution service...
Introduction
focus on a capability...simple scalable, authenticated
public key distribution...layered on top of Secure DNS
(DNSSEC).
-
DNS domain has naming authority over the objects that belong to it,
therefore all names are ultimately DNS names.
-
IKS is loosly coupled to DNS.
Background
public keys must be authenticated to prevent impersonation
and man-in-the-middle attacks. Two approaches
-
Certifying Authorities
In practice, a small set of root certificates
are typically preloaded into the application.
-
Web of Trust
Relies on peers vouching for the validity and trustworthiness
of other peers.
IKS uses Certifying Authority.
DNS names are assigned from a hierarchical namespace,
and organizations are granted control over a sub-tree rooted
at the domain they have registered...
DNSSEC is a collection of proposals for securing the data stored in DNS.
DNSSEC signs the resource records comprising the zone with a public/private
key pair bound to that zone, and delivers those signatures to querying
clients.
To facilitate distribution of zone keys, DNSSEC defines a DNSKEY
resource record.
By recursively requesting keys and moving up the DNS hierarchy,
the client will ether find a trusted key, or exhaust the name space.
The paper indicates that DNSSEC is now implementable.
BUT
DNSSEC cannot support random key distribution:
-
945 million users vs 230 million hosts...scable issue
-
Subtypes were to be used for applications, etc. Not supported
in DNSSEC, so requester needs to grab all the keys and then
sort them.
-
Allowing users some level of direct control over their keys
would violate the existing DNS administration model.
Related Work
Can be used to provide a key service:
-
SSH
-
SSL/TLS
-
PGP/GPG
-
SDSI/SPKI
-
X500
-
IBE - key escrow.
IKS - Internet Key Service
-
Use DNSSEC for authentication delegation...
to securely delegate a part of
DNS's authority over name resolution
to a specialized service designed to
meet the requirements of authenticated
key distribution.
-
IKS allows public keys to be assigned to anything
that can have a DNS name: host, user, port.
-
keys are stored and managed by IKS servers.
WHICH ARE DISCOVERED THROUGH DNSSEC.
-
Client uses DNS to find IKS server then does
a look up or a registration.
-
Figure 1
-
each domain administers its own IKS server,
so there are no communications between IKS servers.
Design Requirements
-
Authority
-
Scalability
-
Compatibility
-
Flexibility
-
Efficiency
-
Generality
-
Security
-
Consistency
IKS Architecture
-
DNS adds resource records for IKS server.
-
IKS servers sign all keys returned with a
key-signing key (KSK), the public 1/2 of which
is in DNSSEC
-
Registration acks and query failure responses
are signed with a
response-signing key (RSK), the public 1/2
of which can be retrieved from the IKS.
-
IKS is actually independent of DNSSEC,
really relies only on the presence of some
trustworthy name service.
-
scalability - keys move outside of DNS to IKS.
-
query interface - IKS uses its own
-
admin authority - DNS does not change much,
the IKS pointer, is more or less static.
Protocol Overview
-
Key Lookup
-
Key Registration
-
Key Revocation
-
Locating an IKS Server
-
Messages
-
Authenticating Key Signing Keys
Mike Erlinger
Last Modified Thursday, 30-Mar-2006 09:48:13 PST