diff options
Diffstat (limited to 'doc/src/draft-richardson-ipsec-rr.xml')
| -rw-r--r-- | doc/src/draft-richardson-ipsec-rr.xml | 560 |
1 files changed, 560 insertions, 0 deletions
diff --git a/doc/src/draft-richardson-ipsec-rr.xml b/doc/src/draft-richardson-ipsec-rr.xml new file mode 100644 index 000000000..e51b32615 --- /dev/null +++ b/doc/src/draft-richardson-ipsec-rr.xml @@ -0,0 +1,560 @@ +<?xml version="1.0"?> +<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> +<?rfc toc="yes"?> + +<rfc ipr="full2026" docName="draft-ietf-ipseckey-rr-07.txt"> + +<front> + <area>Security</area> + <workgroup>IPSECKEY WG</workgroup> + <title abbrev="ipsecrr"> + A method for storing IPsec keying material in DNS. + </title> + + <author initials="M." surname="Richardson" fullname="Michael C. Richardson"> + <organization abbrev="SSW">Sandelman Software Works</organization> + <address> + <postal> + <street>470 Dawson Avenue</street> + <city>Ottawa</city> + <region>ON</region> + <code>K1Z 5V7</code> + <country>CA</country> + </postal> + <email>mcr@sandelman.ottawa.on.ca</email> + <uri>http://www.sandelman.ottawa.on.ca/</uri> + </address> + </author> + + <date month="September" year="2003" /> + +<abstract> + <t> +This document describes a new resource record for DNS. This record may be +used to store public keys for use in IPsec systems. +</t> + +<t> +This record replaces the functionality of the sub-type #1 of the KEY Resource +Record, which has been obsoleted by RFC3445. +</t> +</abstract> + +</front> + +<middle> + +<section title="Introduction"> +<t> + The type number for the IPSECKEY RR is TBD. +</t> + +<section title="Overview"> +<t> + The IPSECKEY resource record (RR) is used to publish a public key that is + to be associated with a Domain Name System (DNS) name for use with the + IPsec protocol suite. This can be the public key of a host, + network, or application (in the case of per-port keying). +</t> + +<t> + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + RFC2119 <xref target="RFC2119" />. +</t> +</section> + +<section title="Usage Criteria"> +<t> + An IPSECKEY resource record SHOULD be used in combination with DNSSEC +unless some other means of authenticating the IPSECKEY resource record +is available. +</t> + +<t> + It is expected that there will often be multiple IPSECKEY resource + records at the same name. This will be due to the presence + of multiple gateways and the need to rollover keys. + +</t> + +<t> + This resource record is class independent. +</t> +</section> +</section> + +<section title="Storage formats"> + +<section title="IPSECKEY RDATA format"> + +<t> + The RDATA for an IPSECKEY RR consists of a precedence value, a public key, + algorithm type, and an optional gateway address. +</t> + +<artwork><![CDATA[ + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | precedence | gateway type | algorithm | gateway | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + + ~ gateway ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +]]></artwork> +</section> + +<section title="RDATA format - precedence"> +<t> +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 <xref target="RFC1035" />. +</t> +<t> +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. +</t> +</section> + +<section anchor="algotype" title="RDATA format - algorithm type"> +<t> +The algorithm type field identifies the public key's cryptographic +algorithm and determines the format of the public key field. +</t> + +<t> +A value of 0 indicates that no key is present. +</t> + +<t> +The following values are defined: + <list style="hanging"> + <t hangText="1">A DSA key is present, in the format defined in RFC2536 <xref target="RFC2536" /></t> + <t hangText="2">A RSA key is present, in the format defined in RFC3110 <xref target="RFC3110" /></t> + </list> +</t> + +</section> + +<section anchor="gatewaytype" title="RDATA format - gateway type"> +<t> +The gateway type field indicates the format of the information that +is stored in the gateway field. +</t> + +<t> +The following values are defined: + <list style="hanging"> + <t hangText="0">No gateway is present</t> + <t hangText="1">A 4-byte IPv4 address is present</t> + <t hangText="2">A 16-byte IPv6 address is present</t> + <t hangText="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.</t> + </list> +</t> + +</section> + +<section title="RDATA format - gateway"> +<t> +The gateway field indicates a gateway to which an IPsec tunnel may be +created in order to reach the entity named by this resource record. +</t> +<t> +There are three formats: +</t> + +<t> +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 +<xref target="RFC1035">RFC1035</xref>. This is a 32-bit number in network byte order. +</t> + +<t>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 +<xref target="RFC1886">RFC1886</xref>. This is a 128-bit number in network byte order. +</t> + +<t> +The gateway field is a normal wire-encoded domain name, as described +in section 3.3 of RFC1035 <xref target="RFC1035" />. Compression MUST NOT be used. +</t> + +</section> + +<section title="RDATA format - public keys"> +<t> +Both of the public key types defined in this document (RSA and DSA) +inherit their public key formats from the corresponding KEY RR formats. +Specifically, the public key field contains the algorithm-specific +portion of the KEY RR RDATA, which is all of the KEY RR DATA after the +first four octets. This is the same portion of the KEY RR that must be +specified by documents that define a DNSSEC algorithm. +Those documents also specify a message digest to be used for generation +of SIG RRs; that specification is not relevant for IPSECKEY RR. +</t> + +<t> +Future algorithms, if they are to be used by both DNSSEC (in the KEY +RR) and IPSECKEY, are likely to use the same public key encodings in +both records. Unless otherwise specified, the IPSECKEY public key +field will contain the algorithm-specific portion of the KEY RR RDATA +for the corresponding algorithm. The algorithm must still be +designated for use by IPSECKEY, and an IPSECKEY algorithm type number +(which might be different than the DNSSEC algorithm number) must be +assigned to it. +</t> + +<t>The DSA key format is defined in RFC2536 <xref target="RFC2536" /></t>. + +<t>The RSA key format is defined in RFC3110 <xref target="RFC3110" />, +with the following changes:</t> + +<t> +The earlier definition of RSA/MD5 in RFC2065 limited the exponent and +modulus to 2552 bits in length. RFC3110 extended that limit to 4096 +bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on +RSA public keys, other than the 65535 octet limit imposed by the +two-octet length encoding. This length extension is applicable only +to IPSECKEY and not to KEY RRs. +</t> + +</section> + +</section> + + + +<section title="Presentation formats"> + +<section title="Representation of IPSECKEY RRs"> +<t> + IPSECKEY RRs may appear in a zone data master file. + The precedence, gateway type and algorithm and gateway fields are REQUIRED. + The base64 encoded public key block is OPTIONAL; if not present, + then the public key field of the resource record MUST be construed + as being zero octets in length. +</t> +<t> + The algorithm field is an unsigned integer. No mnemonics are defined. +</t> +<t> + If no gateway is to be indicated, then the gateway type field MUST + be zero, and the gateway field MUST be "." +</t> + +<t> + The Public Key field is represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see +<xref target="RFC1521">RFC1521</xref> Section 5.2. +</t> + + +<t> + The general presentation for the record as as follows: +<artwork><![CDATA[ +IN IPSECKEY ( precedence gateway-type algorithm + gateway base64-encoded-public-key ) +]]></artwork> +</t> +</section> + + +<section title="Examples"> +<t> +An example of a node 192.0.2.38 that will accept IPsec tunnels on its +own behalf. +<artwork><![CDATA[ +38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.38 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) +]]></artwork> +</t> + +<t> +An example of a node, 192.0.2.38 that has published its key only. +<artwork><![CDATA[ +38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 + . + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) +]]></artwork> +</t> + +<t> +An example of a node, 192.0.2.38 that has delegated authority to the node +192.0.2.3. +<artwork><![CDATA[ +38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.3 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) +]]></artwork> +</t> + +<t> +An example of a node, 192.0.1.38 that has delegated authority to the node +with the identity "mygateway.example.com". +<artwork><![CDATA[ +38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 + mygateway.example.com. + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) +]]></artwork> +</t> + +<t> +An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has +delegated authority to the node 2001:0DB8:c000:0200:2::1 +<artwork><![CDATA[ +$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int. +0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 + 2001:0DB8:0:8002::2000:1 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) +]]></artwork> +</t> + +</section> +</section> + +<section title="Security Considerations"> +<t> + This entire memo pertains to the provision of public keying material + for use by key management protocols such as ISAKMP/IKE (RFC2407) + <xref target="RFC2407" />. +</t> + +<t> +The IPSECKEY resource record contains information that SHOULD be +communicated to the end client in an integral fashion - i.e. free from +modification. The form of this channel is up to the consumer of the +data - there must be a trust relationship between the end consumer of this +resource record and the server. This relationship may be end-to-end +DNSSEC validation, a TSIG or SIG(0) channel to another secure source, +a secure local channel on the host, or some combination of the above. +</t> + +<t> +The keying material provided by the IPSECKEY resource record is not +sensitive to passive attacks. The keying material may be freely +disclosed to any party without any impact on the security properties +of the resulting IPsec session: IPsec and IKE provide for defense +against both active and passive attacks. +</t> + +<t> + 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. +</t> + +<section title="Active attacks against unsecured IPSECKEY resource records"> +<t> +This section deals with active attacks against the DNS. These attacks +require that DNS requests and responses be intercepted and changed. +DNSSEC is designed to defend against attacks of this kind. +</t> + +<t> +The first kind of active attack is when the attacker replaces the +keying material with either a key under its control or with garbage. +</t> + +<t> +If the attacker is not able to mount a subsequent +man-in-the-middle attack on the IKE negotiation after replacing the +public key, then this will result in a denial of service, as the +authenticator used by IKE would fail. +</t> + +<t> +If the attacker is able to both to mount active attacks against DNS +and is also in a position to perform a man-in-the-middle attack on IKE and +IPsec negotiations, then the attacker will be in a position to compromise +the resulting IPsec channel. Note that an attacker must be able to +perform active DNS attacks on both sides of the IKE negotiation in +order for this to succeed. +</t> + +<t> +The second kind of active attack is one in which the attacker replaces +the the gateway address to point to a node under the attacker's +control. The attacker can then either replace the public key or remove +it, thus providing an IPSECKEY record of its own to match the +gateway address. +</t> + +<t> +This later form creates a simple man-in-the-middle since the attacker +can then create a second tunnel to the real destination. Note that, as before, +this requires that the attacker also mount an active attack against +the responder. +</t> + +<t> +Note that the man-in-the-middle can not just forward cleartext +packets to the original destination. While the destination may be +willing to speak in the clear, replying to the original sender, +the sender will have already created a policy expecting ciphertext. +Thus, the attacker will need to intercept traffic from both sides. In some +cases, the attacker may be able to accomplish the full intercept by use +of Network Addresss/Port Translation (NAT/NAPT) technology. +</t> + +<t> +Note that the danger here only applies to cases where the gateway +field of the IPSECKEY RR indicates a different entity than the owner +name of the IPSECKEY RR. In cases where the end-to-end integrity of +the IPSECKEY RR is suspect, the end client MUST restrict its use +of the IPSECKEY RR to cases where the RR owner name matches the +content of the gateway field. +</t> +</section> + +</section> + +<section title="IANA Considerations"> +<t> +This document updates the IANA Registry for DNS Resource Record Types +by assigning type X to the IPSECKEY record. +</t> + +<t> +This document creates an IANA registry for the algorithm type field. +</t> +<t> +Values 0, 1 and 2 are defined in <xref target="algotype" />. Algorithm numbers +3 through 255 can be assigned by IETF Consensus (<xref target="RFC2434">see RFC2434</xref>). +</t> + +<t> +This document creates an IANA registry for the gateway type field. +</t> +<t> +Values 0, 1, 2 and 3 are defined in <xref target="gatewaytype" />. +Algorithm numbers 4 through 255 can be assigned by +Standards Action (<xref target="RFC2434">see RFC2434</xref>). +</t> + + + +</section> + +<section title="Acknowledgments"> +<t> +My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob Austein, +and Olafur Gurmundsson who reviewed this document carefully. +Additional thanks to Olafur Gurmundsson for a reference implementation. +</t> +</section> + +</middle> + +<back> +<references title="Normative references"> +<!-- DNSSEC --> +<?rfc include="reference.RFC.1034" ?> +<?rfc include="reference.RFC.1035" ?> +<?rfc include="reference.RFC.1521" ?> +<?rfc include="reference.RFC.2026" ?> +<?rfc include="reference.RFC.2065" ?> +<?rfc include="reference.RFC.2434" ?> +</references> + +<references title="Non-normative references"> +<?rfc include="reference.RFC.1886" ?> +<?rfc include="reference.RFC.2119" ?> +<?rfc include="reference.RFC.2407" ?> +<?rfc include="reference.RFC.2535" ?> +<?rfc include="reference.RFC.2536" ?> +<?rfc include="reference.RFC.3110" ?> +<?rfc include="reference.RFC.3445" ?> +</references> +</back> +</rfc> +<!-- + $Id: draft-richardson-ipsec-rr.xml,v 1.1 2004/03/15 20:35:24 as Exp $ + + $Log: draft-richardson-ipsec-rr.xml,v $ + Revision 1.1 2004/03/15 20:35:24 as + added files from freeswan-2.04-x509-1.5.3 + + Revision 1.23 2003/09/04 23:26:09 mcr + more nits. + + Revision 1.22 2003/08/16 15:55:35 mcr + fixed version to -06. + + Revision 1.21 2003/08/16 15:52:32 mcr + Sam's comments on IANA considerations. + + Revision 1.20 2003/07/27 22:57:54 mcr + updated document with new text about a seperate registry + for the algorithm type. + + Revision 1.19 2003/06/30 01:51:50 mcr + minor typo fixes. + + Revision 1.18 2003/06/16 17:45:00 mcr + adjusted date on rev-04. + + Revision 1.17 2003/06/16 17:41:30 mcr + revision -04 + + Revision 1.16 2003/06/16 17:39:20 mcr + adjusted typos, and adjusted IANA considerations. + + Revision 1.15 2003/05/26 19:31:23 mcr + updates to drafts - IPSEC RR - SC versions, and RFC3526 + reference in OE draft. + + Revision 1.14 2003/05/23 13:57:40 mcr + updated draft ##. + + Revision 1.13 2003/05/23 13:54:45 mcr + updated month on draft. + + Revision 1.12 2003/05/21 15:42:49 mcr + new SC section with comments from Rob Austein. + + Revision 1.11 2003/05/20 20:52:22 mcr + new security considerations section. + + Revision 1.10 2003/05/20 19:07:47 mcr + rewrote Security Considerations. + + Revision 1.9 2003/05/20 18:17:09 mcr + nits from Rob Austein. + + Revision 1.8 2003/04/29 00:44:59 mcr + updates according to WG consensus: restored three-way + gateway field type. + + Revision 1.7 2003/03/30 17:00:29 mcr + updates according to community feedback. + + Revision 1.6 2003/03/19 02:20:24 mcr + updated draft based upon comments from working group + + Revision 1.5 2003/02/23 22:39:22 mcr + updates to IPSECKEY draft. + + Revision 1.4 2003/02/21 04:39:04 mcr + updated drafts, and added crosscompile.html + + Revision 1.3 2003/01/17 16:26:34 mcr + updated IPSEC KEY draft with restrictions. + + Revision 1.2 2002/08/26 18:20:54 mcr + updated documents + + Revision 1.1 2002/08/10 20:05:33 mcr + document proposing IPSECKEY Resource Record + + +!> |