2 <!DOCTYPE rfc SYSTEM
"rfc2629.dtd">
5 <rfc ipr=
"full2026" docName=
"draft-ietf-ipseckey-rr-07.txt">
9 <workgroup>IPSECKEY WG
</workgroup>
10 <title abbrev=
"ipsecrr">
11 A method for storing IPsec keying material in DNS.
14 <author initials=
"M." surname=
"Richardson" fullname=
"Michael C. Richardson">
15 <organization abbrev=
"SSW">Sandelman Software Works
</organization>
18 <street>470 Dawson Avenue
</street>
24 <email>mcr@sandelman.ottawa.on.ca
</email>
25 <uri>http://www.sandelman.ottawa.on.ca/
</uri>
29 <date month=
"September" year=
"2003" />
33 This document describes a new resource record for DNS. This record may be
34 used to store public keys for use in IPsec systems.
38 This record replaces the functionality of the sub-type #
1 of the KEY Resource
39 Record, which has been obsoleted by RFC3445.
47 <section title=
"Introduction">
49 The type number for the IPSECKEY RR is TBD.
52 <section title=
"Overview">
54 The IPSECKEY resource record (RR) is used to publish a public key that is
55 to be associated with a Domain Name System (DNS) name for use with the
56 IPsec protocol suite. This can be the public key of a host,
57 network, or application (in the case of per-port keying).
61 The key words
"MUST",
"MUST NOT",
"REQUIRED",
"SHALL",
"SHALL
62 NOT",
"SHOULD",
"SHOULD NOT",
"RECOMMENDED",
"MAY", and
63 "OPTIONAL" in this document are to be interpreted as described in
64 RFC2119
<xref target=
"RFC2119" />.
68 <section title=
"Usage Criteria">
70 An IPSECKEY resource record SHOULD be used in combination with DNSSEC
71 unless some other means of authenticating the IPSECKEY resource record
76 It is expected that there will often be multiple IPSECKEY resource
77 records at the same name. This will be due to the presence
78 of multiple gateways and the need to rollover keys.
83 This resource record is class independent.
88 <section title=
"Storage formats">
90 <section title=
"IPSECKEY RDATA format">
93 The RDATA for an IPSECKEY RR consists of a precedence value, a public key,
94 algorithm type, and an optional gateway address.
99 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
101 | precedence | gateway type | algorithm | gateway |
102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ +
104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
112 <section title=
"RDATA format - precedence">
114 This is an
8-bit precedence for this record. This is interpreted in
115 the same way as the PREFERENCE field described in section
116 3.3.9 of RFC1035
<xref target=
"RFC1035" />.
119 Gateways listed in IPSECKEY records with lower precedence are
120 to be attempted first. Where there is a tie in precedence, the order
121 should be non-deterministic.
125 <section anchor=
"algotype" title=
"RDATA format - algorithm type">
127 The algorithm type field identifies the public key's cryptographic
128 algorithm and determines the format of the public key field.
132 A value of
0 indicates that no key is present.
136 The following values are defined:
137 <list style=
"hanging">
138 <t hangText=
"1">A DSA key is present, in the format defined in RFC2536
<xref target=
"RFC2536" /></t>
139 <t hangText=
"2">A RSA key is present, in the format defined in RFC3110
<xref target=
"RFC3110" /></t>
145 <section anchor=
"gatewaytype" title=
"RDATA format - gateway type">
147 The gateway type field indicates the format of the information that
148 is stored in the gateway field.
152 The following values are defined:
153 <list style=
"hanging">
154 <t hangText=
"0">No gateway is present
</t>
155 <t hangText=
"1">A
4-byte IPv4 address is present
</t>
156 <t hangText=
"2">A
16-byte IPv6 address is present
</t>
157 <t hangText=
"3">A wire-encoded domain name is present. The wire-encoded
158 format is self-describing, so the length is implicit. The domain name
159 MUST NOT be compressed.
</t>
165 <section title=
"RDATA format - gateway">
167 The gateway field indicates a gateway to which an IPsec tunnel may be
168 created in order to reach the entity named by this resource record.
171 There are three formats:
175 A
32-bit IPv4 address is present in the gateway field. The data
176 portion is an IPv4 address as described in section
3.4.1 of
177 <xref target=
"RFC1035">RFC1035
</xref>. This is a
32-bit number in network byte order.
180 <t>A
128-bit IPv6 address is present in the gateway field.
181 The data portion is an IPv6 address as described in section
2.2 of
182 <xref target=
"RFC1886">RFC1886
</xref>. This is a
128-bit number in network byte order.
186 The gateway field is a normal wire-encoded domain name, as described
187 in section
3.3 of RFC1035
<xref target=
"RFC1035" />. Compression MUST NOT be used.
192 <section title=
"RDATA format - public keys">
194 Both of the public key types defined in this document (RSA and DSA)
195 inherit their public key formats from the corresponding KEY RR formats.
196 Specifically, the public key field contains the algorithm-specific
197 portion of the KEY RR RDATA, which is all of the KEY RR DATA after the
198 first four octets. This is the same portion of the KEY RR that must be
199 specified by documents that define a DNSSEC algorithm.
200 Those documents also specify a message digest to be used for generation
201 of SIG RRs; that specification is not relevant for IPSECKEY RR.
205 Future algorithms, if they are to be used by both DNSSEC (in the KEY
206 RR) and IPSECKEY, are likely to use the same public key encodings in
207 both records. Unless otherwise specified, the IPSECKEY public key
208 field will contain the algorithm-specific portion of the KEY RR RDATA
209 for the corresponding algorithm. The algorithm must still be
210 designated for use by IPSECKEY, and an IPSECKEY algorithm type number
211 (which might be different than the DNSSEC algorithm number) must be
215 <t>The DSA key format is defined in RFC2536
<xref target=
"RFC2536" /></t>.
217 <t>The RSA key format is defined in RFC3110
<xref target=
"RFC3110" />,
218 with the following changes:
</t>
221 The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
222 modulus to
2552 bits in length. RFC3110 extended that limit to
4096
223 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on
224 RSA public keys, other than the
65535 octet limit imposed by the
225 two-octet length encoding. This length extension is applicable only
226 to IPSECKEY and not to KEY RRs.
235 <section title=
"Presentation formats">
237 <section title=
"Representation of IPSECKEY RRs">
239 IPSECKEY RRs may appear in a zone data master file.
240 The precedence, gateway type and algorithm and gateway fields are REQUIRED.
241 The base64 encoded public key block is OPTIONAL; if not present,
242 then the public key field of the resource record MUST be construed
243 as being zero octets in length.
246 The algorithm field is an unsigned integer. No mnemonics are defined.
249 If no gateway is to be indicated, then the gateway type field MUST
250 be zero, and the gateway field MUST be
"."
254 The Public Key field is represented as a Base64 encoding of the
255 Public Key. Whitespace is allowed within the Base64 text. For a
256 definition of Base64 encoding, see
257 <xref target=
"RFC1521">RFC1521
</xref> Section
5.2.
262 The general presentation for the record as as follows:
264 IN IPSECKEY ( precedence gateway-type algorithm
265 gateway base64-encoded-public-key )
271 <section title=
"Examples">
273 An example of a node
192.0.2.38 that will accept IPsec tunnels on its
276 38.2.0.192.in-addr.arpa.
7200 IN IPSECKEY (
10 1 2
278 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
283 An example of a node,
192.0.2.38 that has published its key only.
285 38.2.0.192.in-addr.arpa.
7200 IN IPSECKEY (
10 0 2
287 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
292 An example of a node,
192.0.2.38 that has delegated authority to the node
295 38.2.0.192.in-addr.arpa.
7200 IN IPSECKEY (
10 1 2
297 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
302 An example of a node,
192.0.1.38 that has delegated authority to the node
303 with the identity
"mygateway.example.com".
305 38.1.0.192.in-addr.arpa.
7200 IN IPSECKEY (
10 3 2
306 mygateway.example.com.
307 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
312 An example of a node,
2001:
0DB8:
0200:
1:
210:f3ff:fe03:
4d0 that has
313 delegated authority to the node
2001:
0DB8:c000:
0200:
2::
1
315 $ORIGIN
1.0.0.0.0.0.2.8.B.D
.0.1.0.0.2.ip6.int.
316 0.d
.4.0.3.0.e.f.f.f
.3.f
.0.1.2.0 7200 IN IPSECKEY (
10 2 2
317 2001:
0DB8:
0:
8002::
2000:
1
318 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
325 <section title=
"Security Considerations">
327 This entire memo pertains to the provision of public keying material
328 for use by key management protocols such as ISAKMP/IKE (RFC2407)
329 <xref target=
"RFC2407" />.
333 The IPSECKEY resource record contains information that SHOULD be
334 communicated to the end client in an integral fashion - i.e. free from
335 modification. The form of this channel is up to the consumer of the
336 data - there must be a trust relationship between the end consumer of this
337 resource record and the server. This relationship may be end-to-end
338 DNSSEC validation, a TSIG or SIG(
0) channel to another secure source,
339 a secure local channel on the host, or some combination of the above.
343 The keying material provided by the IPSECKEY resource record is not
344 sensitive to passive attacks. The keying material may be freely
345 disclosed to any party without any impact on the security properties
346 of the resulting IPsec session: IPsec and IKE provide for defense
347 against both active and passive attacks.
351 Any user of this resource record MUST carefully document their trust
352 model, and why the trust model of DNSSEC is appropriate, if that is
353 the secure channel used.
356 <section title=
"Active attacks against unsecured IPSECKEY resource records">
358 This section deals with active attacks against the DNS. These attacks
359 require that DNS requests and responses be intercepted and changed.
360 DNSSEC is designed to defend against attacks of this kind.
364 The first kind of active attack is when the attacker replaces the
365 keying material with either a key under its control or with garbage.
369 If the attacker is not able to mount a subsequent
370 man-in-the-middle attack on the IKE negotiation after replacing the
371 public key, then this will result in a denial of service, as the
372 authenticator used by IKE would fail.
376 If the attacker is able to both to mount active attacks against DNS
377 and is also in a position to perform a man-in-the-middle attack on IKE and
378 IPsec negotiations, then the attacker will be in a position to compromise
379 the resulting IPsec channel. Note that an attacker must be able to
380 perform active DNS attacks on both sides of the IKE negotiation in
381 order for this to succeed.
385 The second kind of active attack is one in which the attacker replaces
386 the the gateway address to point to a node under the attacker's
387 control. The attacker can then either replace the public key or remove
388 it, thus providing an IPSECKEY record of its own to match the
393 This later form creates a simple man-in-the-middle since the attacker
394 can then create a second tunnel to the real destination. Note that, as before,
395 this requires that the attacker also mount an active attack against
400 Note that the man-in-the-middle can not just forward cleartext
401 packets to the original destination. While the destination may be
402 willing to speak in the clear, replying to the original sender,
403 the sender will have already created a policy expecting ciphertext.
404 Thus, the attacker will need to intercept traffic from both sides. In some
405 cases, the attacker may be able to accomplish the full intercept by use
406 of Network Addresss/Port Translation (NAT/NAPT) technology.
410 Note that the danger here only applies to cases where the gateway
411 field of the IPSECKEY RR indicates a different entity than the owner
412 name of the IPSECKEY RR. In cases where the end-to-end integrity of
413 the IPSECKEY RR is suspect, the end client MUST restrict its use
414 of the IPSECKEY RR to cases where the RR owner name matches the
415 content of the gateway field.
421 <section title=
"IANA Considerations">
423 This document updates the IANA Registry for DNS Resource Record Types
424 by assigning type X to the IPSECKEY record.
428 This document creates an IANA registry for the algorithm type field.
431 Values
0,
1 and
2 are defined in
<xref target=
"algotype" />. Algorithm numbers
432 3 through
255 can be assigned by IETF Consensus (
<xref target=
"RFC2434">see RFC2434
</xref>).
436 This document creates an IANA registry for the gateway type field.
439 Values
0,
1,
2 and
3 are defined in
<xref target=
"gatewaytype" />.
440 Algorithm numbers
4 through
255 can be assigned by
441 Standards Action (
<xref target=
"RFC2434">see RFC2434
</xref>).
448 <section title=
"Acknowledgments">
450 My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob Austein,
451 and Olafur Gurmundsson who reviewed this document carefully.
452 Additional thanks to Olafur Gurmundsson for a reference implementation.
459 <references title=
"Normative references">
461 <?rfc include=
"reference.RFC.1034" ?>
462 <?rfc include=
"reference.RFC.1035" ?>
463 <?rfc include=
"reference.RFC.1521" ?>
464 <?rfc include=
"reference.RFC.2026" ?>
465 <?rfc include=
"reference.RFC.2065" ?>
466 <?rfc include=
"reference.RFC.2434" ?>
469 <references title=
"Non-normative references">
470 <?rfc include=
"reference.RFC.1886" ?>
471 <?rfc include=
"reference.RFC.2119" ?>
472 <?rfc include=
"reference.RFC.2407" ?>
473 <?rfc include=
"reference.RFC.2535" ?>
474 <?rfc include=
"reference.RFC.2536" ?>
475 <?rfc include=
"reference.RFC.3110" ?>
476 <?rfc include=
"reference.RFC.3445" ?>
481 $Id: draft-richardson-ipsec-rr.xml,v 1.1 2004/03/15 20:35:24 as Exp $
483 $Log: draft-richardson-ipsec-rr.xml,v $
484 Revision 1.1 2004/03/15 20:35:24 as
485 added files from freeswan-2.04-x509-1.5.3
487 Revision 1.23 2003/09/04 23:26:09 mcr
490 Revision 1.22 2003/08/16 15:55:35 mcr
491 fixed version to -06.
493 Revision 1.21 2003/08/16 15:52:32 mcr
494 Sam's comments on IANA considerations.
496 Revision 1.20 2003/07/27 22:57:54 mcr
497 updated document with new text about a seperate registry
498 for the algorithm type.
500 Revision 1.19 2003/06/30 01:51:50 mcr
503 Revision 1.18 2003/06/16 17:45:00 mcr
504 adjusted date on rev-04.
506 Revision 1.17 2003/06/16 17:41:30 mcr
509 Revision 1.16 2003/06/16 17:39:20 mcr
510 adjusted typos, and adjusted IANA considerations.
512 Revision 1.15 2003/05/26 19:31:23 mcr
513 updates to drafts - IPSEC RR - SC versions, and RFC3526
514 reference in OE draft.
516 Revision 1.14 2003/05/23 13:57:40 mcr
519 Revision 1.13 2003/05/23 13:54:45 mcr
520 updated month on draft.
522 Revision 1.12 2003/05/21 15:42:49 mcr
523 new SC section with comments from Rob Austein.
525 Revision 1.11 2003/05/20 20:52:22 mcr
526 new security considerations section.
528 Revision 1.10 2003/05/20 19:07:47 mcr
529 rewrote Security Considerations.
531 Revision 1.9 2003/05/20 18:17:09 mcr
532 nits from Rob Austein.
534 Revision 1.8 2003/04/29 00:44:59 mcr
535 updates according to WG consensus: restored three-way
538 Revision 1.7 2003/03/30 17:00:29 mcr
539 updates according to community feedback.
541 Revision 1.6 2003/03/19 02:20:24 mcr
542 updated draft based upon comments from working group
544 Revision 1.5 2003/02/23 22:39:22 mcr
545 updates to IPSECKEY draft.
547 Revision 1.4 2003/02/21 04:39:04 mcr
548 updated drafts, and added crosscompile.html
550 Revision 1.3 2003/01/17 16:26:34 mcr
551 updated IPSEC KEY draft with restrictions.
553 Revision 1.2 2002/08/26 18:20:54 mcr
556 Revision 1.1 2002/08/10 20:05:33 mcr
557 document proposing IPSECKEY Resource Record