A Method for Storing IPsec Keying Material in DNS
RFC 4025

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    ipseckey mailing list <ipseckey@ietf.org>, 
    ipseckey chair <ipseckey-chairs@tools.ietf.org>
Subject: Protocol Action: 'A method for storing IPsec keying 
         material in DNS' to Proposed Standard 

The IESG has approved the following document:

- 'A method for storing IPsec keying material in DNS '
   <draft-ietf-ipseckey-rr-13.txt> as a Proposed Standard

This document is the product of the IPSEC KEYing information resource 
record Working Group. 

The IESG contact persons are Russ Housley and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-13.txt

Technical Summary
 
  This document defines a new DNS record for IPsec keys, and in particular 
for IPsec keys for opportunistic encryption.
 
Working Group Summary
 
 The working group rapidly converged on a design.  A separate IPsec key RR 
was needed because RFC 3445 deprecated subtypes of KEY RRs.
 
Protocol Quality
 
 Steve Bellovin reviewed this document for the IESG.

RFC Editor note:

In Section 1:

Old text:
   Suppose we have a host which wishes to establish an IPsec tunnel with
   some remote entity on the network.  In many cases this end system
   will only know a DNS name for the remote entity (whether that DNS
   name be the name of the remote node, a DNS reverse tree name
   corresponding to the IP address of the remote node, or perhaps a the
   domain name portion of a "user@FQDN" name for a remote entity).  In
   these cases the host will need to obtain a public key in order to
   authenticate the remote entity, and may also need some guidance about
   whether it should contact the entity directly or use another node as
   a gateway to the target entity.

   The IPSECKEY RR provides a storage mechanism for such data as the
   public key and the gateway information.

New text:
    Suppose we have a host which wishes (or is required by policy) to
    establish an IPsec tunnel with some remote entity on the network
    prior to allowing normal communication to take place.  In many
    cases this end system will be able to determine the DNS name for
    the remote entity (either by having the DNS name given explicitly,
    by performing a DNS PTR query for a particular IP address, or
    through some other means, e.g., by extracting the DNS portion of a
    "user@FQDN" name for a remote entity).  In these cases the host
    will need to obtain a public key in order to authenticate the
    remote entity, and may also need some guidance about whether it
    should contact the entity directly or use another node as a gateway
    to the target entity.  The IPSECKEY RR provides a mechanism for 
    storing such information.