Skip to main content

A Method for Storing IPsec Keying Material in DNS
RFC 4025

Revision differences

Document history

Date Rev. By Action
2018-12-20
12 (System)
Received changes through RFC Editor sync (changed abstract to 'This document describes a new resource record for the Domain Name System (DNS). This record may …
Received changes through RFC Editor sync (changed abstract to 'This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question.

This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]')
2015-10-14
12 (System) Notify list changed from sra@hactrn.net, weiler@tislabs.com to (None)
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Thomas Narten
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Bert Wijnen
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Harald Alvestrand
2005-04-05
12 Brian Carpenter Shepherding AD has been changed to Russ Housley from Brian Carpenter
2005-03-24
12 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-03-24
12 Amy Vezza [Note]: 'RFC 4025' added by Amy Vezza
2005-03-24
12 Amy Vezza Shepherding AD has been changed to Brian Carpenter from Steve Bellovin
2005-03-11
12 (System) RFC published
2005-01-20
12 (System) New version available: draft-ietf-ipseckey-rr-12.txt
2004-10-01
12 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-09-30
12 Amy Vezza IESG state changed to Approved-announcement sent
2004-09-30
12 Amy Vezza IESG has approved the document
2004-09-30
12 Amy Vezza Closed "Approve" ballot
2004-09-28
12 Steven Bellovin State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Steve Bellovin
2004-09-28
12 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen
2004-09-28
12 (System) Removed from agenda for telechat - 2004-09-27
2004-09-27
12 Thomas Narten [Ballot Position Update] Position for Thomas Narten has been changed to No Objection from Undefined by Thomas Narten
2004-09-27
12 Thomas Narten
[Ballot comment]
New text is better. Thanks. Some minor wordsmithing suggested for first
two paragraphs:

  Suppose we have a host which wishes (or is …
[Ballot comment]
New text is better. Thanks. Some minor wordsmithing suggested for first
two paragraphs:

  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 explicitely,
  by performing a DNS PTR query for a particular IP address, or
  through some other means, e.g., by extractng 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 will 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 storing such information.
2004-09-27
12 Thomas Narten [Ballot Position Update] Position for Thomas Narten has been changed to Undefined from Discuss by Thomas Narten
2004-09-27
12 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-09-24
12 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-09-23
12 Steven Bellovin [Note]: 'Back on the ballot to clear Thomas and Bert''s DISCUSS' added by Steve Bellovin
2004-09-23
12 Steven Bellovin Placed on agenda for telechat - 2004-09-27 by Steve Bellovin
2004-07-19
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-07-19
11 (System) New version available: draft-ietf-ipseckey-rr-11.txt
2004-04-28
10 (System) New version available: draft-ietf-ipseckey-rr-10.txt
2004-02-02
09 (System) New version available: draft-ietf-ipseckey-rr-09.txt
2003-12-16
08 (System) New version available: draft-ietf-ipseckey-rr-08.txt
2003-12-05
12 Thomas Narten
[Ballot discuss]
Meta issue (this is why I'm putting in a discuss):

Intro (actually no part of the document) actually explains what this
RR is …
[Ballot discuss]
Meta issue (this is why I'm putting in a discuss):

Intro (actually no part of the document) actually explains what this
RR is useful for. Consider a reader not familar with this effort who
would like to understand why this RR is needed, who uses it, and in
what situations its useful.  For instance, it would be useful to
include an example of how the RR is expected to be used. I.e., it's
not until halfway down the document that one figures out the RR could
identify a gateway one connects to to create an IPsec tunnel to a
particular site. But the RR is keyed by an address. Why does one need
to map from the address to a gateay? I suspect 1 or 2 paragraphs would
do the trick.

Specific comments:

Abstract could be a lot better. Reading it, one doesn't really know
what this document is about or how the RR is used.


>    The RDATA for an IPSECKEY RR consists of a precedence value, a public
>    key, algorithm type, and an optional gateway address.

picture also shows a 'gateway type' field...

> 2.2 RDATA format - precedence
>
>    This is an 8-bit precedence for this record.  This is interpreted in
>    the same way as the PREFERENCE field described in section 3.3.9 of
>    RFC1035 [2].

say "unsigned"? also, why not just specify the semantics of the
preference here, rather than pointing to a (rather unrelated) MX
record RR? Hunting for the MX text in another document seems
suboptimal (and results in an odd normative reference).

>    Gateways listed in IPSECKEY records with  lower precedence are to be
>    attempted first.  Where there is a tie in precedence, the order
>    should be non-deterministic.

Note: the above text seems out of place, given the previous paragraph
which just points to MX. Can't you just specify the behavior here (in
its entirety) and remove the normative dependency?

>    3  A wire-encoded domain name is present.  The wire-encoded format is
>      self-describing, so the length is implicit.  The domain name MUST
>      NOT be compressed.
>

"wire-encoded" could be made more precise. I.e., Refer to DNS spec
(and specific section?). (There is better text later in the draft, actually)


>    A 32-bit IPv4 address is present in the gateway field.  The data
>    portion is an IPv4 address as described in section 3.4.1 of RFC1035
>    [2].  This is a 32-bit number in network byte order.
>
>    A 128-bit IPv6 address is present in the gateway field.  The data
>    portion is an IPv6 address as described in section 2.2 of RFC1886
>    [7].  This is a 128-bit number in network byte order.

Why are (apparently normative) references to other RRs given here?
Can't the format just be written out here, since it's basically one
sentence saying N-bits in network byte order?


> 5. IANA Considerations
>
>    This document updates the IANA Registry for DNS Resource Record Types
>    by assigning type X to the IPSECKEY record.

Add:

This document creates two new IANA registries, both specific to the
IPSECKEY Resource Record.
2003-12-05
12 Thomas Narten [Ballot Position Update] New position, Discuss, has been recorded for  by Thomas Narten
2003-12-04
12 Amy Vezza Removed from agenda for telechat - 2003-12-04 by Amy Vezza
2003-12-04
12 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2003-12-04
12 Harald Alvestrand [Ballot Position Update] Position for Harald Alvestrand has been changed to No Objection from Discuss by Harald Alvestrand
2003-12-04
12 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for  by Alex Zinin
2003-12-04
12 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for  by Bill Fenner
2003-12-04
12 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for  by Margaret Wasserman
2003-12-04
12 Jon Peterson
[Ballot comment]
The end of Section 4 says:

  Any user of this resource record MUST carefully document their trust
  model, and why the …
[Ballot comment]
The end of Section 4 says:

  Any user of this resource record MUST carefully document their trust
  model, and why the trust model of DNSSEC is appropriate, if that is
  the secure channel used.

Does that really mean "any user"? Do we require end-users of our specifications to generate documentation these days? If this is instead referring to derivate specifications or IETF-shepherded operational models based on these RRs, it should say so explicitly here.

Nit: Should we encourage/require people who use xml2rfc to use the  directive? The amount of whitespace that is generated otherwise is a little bothersome.
2003-12-04
12 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for  by Jon Peterson
2003-12-04
12 Harald Alvestrand
[Ballot discuss]
This may have an easy reply, but....
if one is using unsecured DNS, a man-in-the-middle attack can be mounted. The document claims that …
[Ballot discuss]
This may have an easy reply, but....
if one is using unsecured DNS, a man-in-the-middle attack can be mounted. The document claims that this can only be done when there is a value in the gateway field.
If an attacker can attack the DNS for the IPSECKEY record, the attacker should also be able to attack the A record. Wouldn't that allow the same attack as for the case where a gateway field is present?
If so, shouldn't the security considerations say so?
2003-12-04
12 Harald Alvestrand [Ballot Position Update] New position, Discuss, has been recorded for  by Harald Alvestrand
2003-12-03
12 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to Yes from Undefined by Allison Mankin
2003-12-03
12 Allison Mankin
[Ballot comment]
Instead of RFC1521 for Base64 (v. old), reference RFC3548.

In the examples, replace ip6.int with ip6.arpa.

In the IANA Considerations, there's …
[Ballot comment]
Instead of RFC1521 for Base64 (v. old), reference RFC3548.

In the examples, replace ip6.int with ip6.arpa.

In the IANA Considerations, there's a typo:

This document creates an IANA registry for the algorithm type field.

  Values 0, 1 and 2 are defined in Section 2.3.  Algorithm numbers 3
  through 255 can be assigned by IETF Consensus (see RFC2434 [6]).

  This document creates an IANA registry for the gateway type field.

  Values 0, 1, 2 and 3 are defined in Section 2.4.  Algorithm numbers 4
                                                                                        ^ Gateway type
  through 255 can be assigned by Standards Action (see RFC2434 [6]).
2003-12-03
12 Allison Mankin
[Ballot comment]
Instead of RFC1521 for Base64 (v. old), reference RFC3548.

In the IANA Considerations, there's a typo:

This document creates an IANA registry …
[Ballot comment]
Instead of RFC1521 for Base64 (v. old), reference RFC3548.

In the IANA Considerations, there's a typo:

This document creates an IANA registry for the algorithm type field.

  Values 0, 1 and 2 are defined in Section 2.3.  Algorithm numbers 3
  through 255 can be assigned by IETF Consensus (see RFC2434 [6]).

  This document creates an IANA registry for the gateway type field.

  Values 0, 1, 2 and 3 are defined in Section 2.4.  Algorithm numbers 4
                                                                                        ^ Gateway type
  through 255 can be assigned by Standards Action (see RFC2434 [6]).
2003-12-03
12 Allison Mankin
[Ballot comment]
In the IANA Considerations, there's a typo:

This document creates an IANA registry for the algorithm type field.

  Values 0, 1 and …
[Ballot comment]
In the IANA Considerations, there's a typo:

This document creates an IANA registry for the algorithm type field.

  Values 0, 1 and 2 are defined in Section 2.3.  Algorithm numbers 3
  through 255 can be assigned by IETF Consensus (see RFC2434 [6]).

  This document creates an IANA registry for the gateway type field.

  Values 0, 1, 2 and 3 are defined in Section 2.4.  Algorithm numbers 4
                                                                                        ^ Gateway type
  through 255 can be assigned by Standards Action (see RFC2434 [6]).
2003-12-03
12 Allison Mankin [Ballot Position Update] New position, Undefined, has been recorded for  by Allison Mankin
2003-12-03
12 Bert Wijnen
[Ballot discuss]
DISCUSS.

From OPS directorate review:

> o draft-ietf-ipseckey-rr-07.txt
> A method for storing IPsec keying material in DNS (Proposed Standard) - 10
> …
[Ballot discuss]
DISCUSS.

From OPS directorate review:

> o draft-ietf-ipseckey-rr-07.txt
> A method for storing IPsec keying material in DNS (Proposed Standard) - 10
> of 14
> Token: Steve Bellovin

Bigger issue:

- The examples use the reverse DNS records to convey IPSECKEY record.
Does this have some unstated assumptions about the deployment of
IPSECKEY (e.g., to be usable, the participating nodes should record
the RRs in reverse records), or is this just a coincidence?
I note that the document does not discuss the deployment at all, but
that is probably intentional.

If there is no connection to the reverse records, I'd suggest
rewording at least 3 of the 5 examples to use e.g. "nodeX.example.com
IN IPSECKEY ..."; if there is a requirement for reverse records, this
issue needs to be explicitly discussed.. DNS deployment folks might
have something to say about that :-)

Nits:

- Reorder sections 2.3 and 2.4 to be in the saem order as the fields.

- Replace the references to RFC1886 with RFC3596.

- Add IPR section

- Rename the draft shortname (at each page header) from "ipsecrr" to
something else.

- Remove the dot from the title and upper-case it.
2003-12-03
12 Amy Vezza [Ballot Position Update] New position, Discuss, has been recorded for  by Amy Vezza
2003-12-02
12 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie
2003-12-02
12 Ted Hardie
[Ballot comment]
This text:

2.1 IPSECKEY RDATA format

  The RDATA for an IPSECKEY RR consists of a precedence value, a public
  key, algorithm …
[Ballot comment]
This text:

2.1 IPSECKEY RDATA format

  The RDATA for an IPSECKEY RR consists of a precedence value, a public
  key, algorithm type, and an optional gateway address.

seems to leave out gateway type, described in section 2.4.  The rest of
the document is clear, but it would probably be good to add it in here.
2003-12-02
12 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for  by Ted Hardie
2003-11-26
12 Ned Freed [Ballot comment]
No IPR boilerplate
2003-11-26
12 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded for  by Ned Freed
2003-11-25
12 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for  by Russ Housley
2003-11-25
12 Steven Bellovin State Changes to IESG Evaluation from Waiting for Writeup by Steve Bellovin
2003-11-25
12 Steven Bellovin State Change Notice email list have been change to sra@hactrn.net, weiler@tislabs.com from
2003-11-25
12 Steven Bellovin Placed on agenda for telechat - 2003-12-04 by Steve Bellovin
2003-11-25
12 Steven Bellovin [Ballot Position Update] New position, Yes, has been recorded for Steven Bellovin
2003-11-25
12 Steven Bellovin Ballot has been issued by Steve Bellovin
2003-11-25
12 Steven Bellovin Created "Approve" ballot
2003-11-25
12 (System) Ballot writeup text was added
2003-11-25
12 (System) Last call text was added
2003-11-25
12 (System) Ballot approval text was added
2003-11-17
12 (System) State has been changed to Waiting for Writeup from In Last Call by system
2003-11-03
12 Amy Vezza Last call sent
2003-11-03
12 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2003-11-01
12 Steven Bellovin Intended Status has been changed to Proposed Standard from None
2003-10-24
12 Steven Bellovin State Changes to Last Call Requested from AD Evaluation by Steve Bellovin
2003-09-12
12 Steven Bellovin
Remaining nits:

Remaining nits, for reference:

> Just read -07.  One final nit, sigh: s/ip6.int/ip6.arpa/

And in the IANA section, for the second registry: …
Remaining nits:

Remaining nits, for reference:

> Just read -07.  One final nit, sigh: s/ip6.int/ip6.arpa/

And in the IANA section, for the second registry:
s/Algorithm numbers/Gateway type numbers/
2003-09-12
12 Steven Bellovin Draft Added by Steve Bellovin
2003-09-05
07 (System) New version available: draft-ietf-ipseckey-rr-07.txt
2003-08-22
06 (System) New version available: draft-ietf-ipseckey-rr-06.txt
2003-07-02
05 (System) New version available: draft-ietf-ipseckey-rr-05.txt
2003-06-17
04 (System) New version available: draft-ietf-ipseckey-rr-04.txt
2003-05-29
03 (System) New version available: draft-ietf-ipseckey-rr-03.txt
2003-05-23
02 (System) New version available: draft-ietf-ipseckey-rr-02.txt
2003-04-29
01 (System) New version available: draft-ietf-ipseckey-rr-01.txt
2003-03-31
00 (System) New version available: draft-ietf-ipseckey-rr-00.txt