[foaf-protocols] Fwd: [keyassure] WG Action: DNS-based Authentication of Named Entities (dane)

Dan Brickley danbri at danbri.org
Sat Dec 11 10:18:22 CET 2010


Another day, another WG... :)

---------- Forwarded message ----------
From: IESG Secretary <iesg-secretary at ietf.org>
Date: Fri, Dec 10, 2010 at 7:17 PM
Subject: [keyassure] WG Action: DNS-based Authentication of Named
Entities (dane)
To: IETF Announcement list <ietf-announce at ietf.org>
Cc: keyassure at ietf.org


A new IETF working group has been formed in the Security Area.
For additional information, please contact the Area Directors or the WG
Chairs.

DNS-based Authentication of Named Entities (dane)
---------------------------------------------------
Current Status: Active Working Group

Chairs:
 Warren Kumari <warren at kumari.net>
 Ondrej Sury <ondrej.sury at nic.cz>

WG Secretary:
 Matt Lepinski <mlepinski at bbn.com>

Security Area Directors:
 Sean Turner <turners at ieca.com>
 Tim Polk <tim.polk at nist.gov>

Security Area Advisor:
 Tim Polk <tim.polk at nist.gov>

Mailing Lists:
 General Discussion: keyassure at ietf.org
 To Subscribe: https://www.ietf.org/mailman/listinfo/keyassure
 Archive:
http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html

Description of Working Group:

Objective:

Specify mechanisms and techniques that allow Internet applications to
establish cryptographically secured communications by using information
distributed through DNSSEC for discovering and authenticating public
keys which are associated with a service located at a domain name.

Problem Statement:

Entities on the Internet are usually identified using domain names and
forming a cryptographically secured connection to the entity requires
the entity to authenticate its name. For instance, in HTTPS, a server
responding to a query for <https://www.example.com> is expected to
authenticate as "www.example.com". Security protocols such as TLS and
IPsec accomplish this authentication by allowing an endpoint to prove
ownership of a private key whose corresponding public key is somehow
bound to the name being authenticated. As a pre-requisite for
authentication, then, these protocols require a mechanism for bindings
to be asserted between public keys and domain names.

DNSSEC provides a mechanism for a zone operator to sign DNS
information directly, using keys that are bound to the domain by the
parent domain; relying parties can continue this chain up to any trust
anchor that they accept. In this way, bindings of keys to domains are
asserted not by external entities, but by the entities that operate the
DNS. In addition, this technique inherently limits the scope of any
given entity to the names in zones he controls.

This working group will develop mechanisms for zone operators to
present bindings between names within their control and public keys, in
such a way that these bindings can be integrity-protected (and thus
shown to be authentically from the zone operator) using DNSSEC and
used as a basis for authentication in protocols that use domain names as
identifiers. Possible starting points for these deliverables include
draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
draft-josefsson-keyassure-tls.

The mechanisms developed by this group will address bindings between
domain names and keys, allowing flexibility for all key-transport
mechanisms supported by the application protocols addressed (e.g., both
self-signed and CA-issued certificates for use in TLS).

The solutions specified by this working group rely upon the security of
the DNS to provide source authentication for public keys. The decision
whether the chain of trust provided by DNSSEC is sufficient to trust the
key, or whether additional mechanisms are required to determine the
acceptability of a key, is left to the entity that uses the key
material.  In addition to the protections afforded by DNSSEC, the
protocols and mechanisms designed by this working group require securing
the "last hop" by operating a local DNS resolver or securing the
connection to remote resolver - this WG will not specify new mechanisms
to secure that hop, but will reference existing specifications or
document existing methods in order to allow implementations to
interoperate securely.

Initial deliverables for this working group are limited to distribution
of bindings between names within the zone operator's control and public
keys.  More general statements of policy for a domain are out of scope,
and new tasks in this area may only be adopted through a re-chartering.

The group may also create documents that describe how protocol entities
can discover and validate these bindings in the execution of specific
applications. This work would be done in coordination with the IETF
Working Groups responsible for the protocols.

Goals and Milestones:

Apr 2011  First WG draft of standards-track protocol for using DNS to
         associate hosts with keys for TLS and DTLS
May 2011  First WG draft of standards-track protocols for using DNS to
         associate hosts with IPsec
Sep 2011  Protocol for using DNS to associate domain names with keys for
         TLS and DTLS to IESG
Sep 2011  Protocols for using DNS to associate domain names with keys
         for IPsec to IESG
Nov 2011  Recharter

_______________________________________________
keyassure mailing list
keyassure at ietf.org
https://www.ietf.org/mailman/listinfo/keyassure


More information about the foaf-protocols mailing list