diff options
Diffstat (limited to 'doc/src/draft-richardson-ipsec-rr.html')
| -rw-r--r-- | doc/src/draft-richardson-ipsec-rr.html | 659 |
1 files changed, 659 insertions, 0 deletions
diff --git a/doc/src/draft-richardson-ipsec-rr.html b/doc/src/draft-richardson-ipsec-rr.html new file mode 100644 index 000000000..08473104f --- /dev/null +++ b/doc/src/draft-richardson-ipsec-rr.html @@ -0,0 +1,659 @@ +<html><head><title>A method for storing IPsec keying material in DNS.</title> +<STYLE type='text/css'> + .title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right; + font-family: helvetica, arial, sans-serif } + .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right; + font-family: helvetica, arial, sans-serif } + p.copyright { color: #000000; font-size: 10px; + font-family: verdana, charcoal, helvetica, arial, sans-serif } + p { margin-left: 2em; margin-right: 2em; } + li { margin-left: 3em; } + ol { margin-left: 2em; margin-right: 2em; } + ul.text { margin-left: 2em; margin-right: 2em; } + pre { margin-left: 3em; color: #333333 } + ul.toc { color: #000000; line-height: 16px; + font-family: verdana, charcoal, helvetica, arial, sans-serif } + H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif } + H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif } + TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top } + TD.author-text { color: #000000; font-size: 10px; + font-family: verdana, charcoal, helvetica, arial, sans-serif } + TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif } + A:link { color: #990000; font-weight: bold; + font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } + A:visited { color: #333333; font-weight: bold; + font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } + A:name { color: #333333; font-weight: bold; + font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } + .link2 { color:#ffffff; font-weight: bold; text-decoration: none; + font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; + font-size: 9px } + .RFC { color:#666666; font-weight: bold; text-decoration: none; + font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; + font-size: 9px } + .hotText { color:#ffffff; font-weight: normal; text-decoration: none; + font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; + font-size: 9px } +</style> +</head> +<body bgcolor="#ffffff" text="#000000" alink="#000000" vlink="#666666" link="#990000"> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1"> +<tr valign="top"><td width="33%" bgcolor="#666666" class="header">IPSECKEY WG</td><td width="33%" bgcolor="#666666" class="header">M. Richardson</td></tr> +<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">SSW</td></tr> +<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: March 4, 2004</td><td width="33%" bgcolor="#666666" class="header">September 4, 2003</td></tr> +</table></td></tr></table> +<div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">A method for storing IPsec keying material in DNS.</span></b></font></div> +<div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-ietf-ipseckey-rr-07.txt</span></b></font></div> +<font face="verdana, helvetica, arial, sans-serif" size="2"> + +<h3>Status of this Memo</h3> +<p> +This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p> +<p> +Internet-Drafts are working documents of the Internet Engineering +Task Force (IETF), its areas, and its working groups. +Note that other groups may also distribute working documents as +Internet-Drafts.</p> +<p> +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any time. +It is inappropriate to use Internet-Drafts as reference material or to cite +them other than as "work in progress."</p> +<p> +The list of current Internet-Drafts can be accessed at +<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p> +<p> +The list of Internet-Draft Shadow Directories can be accessed at +<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p> +<p> +This Internet-Draft will expire on March 4, 2004.</p> + +<h3>Copyright Notice</h3> +<p> +Copyright (C) The Internet Society (2003). All Rights Reserved.</p> + +<h3>Abstract</h3> + +<p> +This document describes a new resource record for DNS. This record may be +used to store public keys for use in IPsec systems. + +</p> +<p> +This record replaces the functionality of the sub-type #1 of the KEY Resource +Record, which has been obsoleted by RFC3445. + +</p><a name="toc"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<h3>Table of Contents</h3> +<ul compact class="toc"> +<b><a href="#anchor1">1.</a> +Introduction<br></b> +<b><a href="#anchor2">1.1</a> +Overview<br></b> +<b><a href="#anchor3">1.2</a> +Usage Criteria<br></b> +<b><a href="#anchor4">2.</a> +Storage formats<br></b> +<b><a href="#anchor5">2.1</a> +IPSECKEY RDATA format<br></b> +<b><a href="#anchor6">2.2</a> +RDATA format - precedence<br></b> +<b><a href="#algotype">2.3</a> +RDATA format - algorithm type<br></b> +<b><a href="#gatewaytype">2.4</a> +RDATA format - gateway type<br></b> +<b><a href="#anchor7">2.5</a> +RDATA format - gateway<br></b> +<b><a href="#anchor8">2.6</a> +RDATA format - public keys<br></b> +<b><a href="#anchor9">3.</a> +Presentation formats<br></b> +<b><a href="#anchor10">3.1</a> +Representation of IPSECKEY RRs<br></b> +<b><a href="#anchor11">3.2</a> +Examples<br></b> +<b><a href="#anchor12">4.</a> +Security Considerations<br></b> +<b><a href="#anchor13">4.1</a> +Active attacks against unsecured IPSECKEY resource records<br></b> +<b><a href="#anchor14">5.</a> +IANA Considerations<br></b> +<b><a href="#anchor15">6.</a> +Acknowledgments<br></b> +<b><a href="#rfc.references1">§</a> +Normative references<br></b> +<b><a href="#rfc.references2">§</a> +Non-normative references<br></b> +<b><a href="#rfc.authors">§</a> +Author's Address<br></b> +<b><a href="#rfc.copyright">§</a> +Full Copyright Statement<br></b> +</ul> +<br clear="all"> + +<a name="anchor1"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<a name="rfc.section.1"></a><h3>1. Introduction</h3> + +<p> + The type number for the IPSECKEY RR is TBD. + +</p> +<a name="rfc.section.1.1"></a><h4><a name="anchor2">1.1</a> Overview</h4> + +<p> + 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). + +</p> +<p> + 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 <a href="#RFC2119">[8]</a>. + +</p> +<a name="rfc.section.1.2"></a><h4><a name="anchor3">1.2</a> Usage Criteria</h4> + +<p> + An IPSECKEY resource record SHOULD be used in combination with DNSSEC +unless some other means of authenticating the IPSECKEY resource record +is available. + +</p> +<p> + 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. + + +</p> +<p> + This resource record is class independent. + +</p> +<a name="anchor4"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<a name="rfc.section.2"></a><h3>2. Storage formats</h3> + +<a name="rfc.section.2.1"></a><h4><a name="anchor5">2.1</a> IPSECKEY RDATA format</h4> + +<p> + The RDATA for an IPSECKEY RR consists of a precedence value, a public key, + algorithm type, and an optional gateway address. + +</p></font><pre> + 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 / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> + +<a name="rfc.section.2.2"></a><h4><a name="anchor6">2.2</a> RDATA format - precedence</h4> + +<p> +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 <a href="#RFC1035">[2]</a>. + +</p> +<p> +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. + +</p> +<a name="rfc.section.2.3"></a><h4><a name="algotype">2.3</a> RDATA format - algorithm type</h4> + +<p> +The algorithm type field identifies the public key's cryptographic +algorithm and determines the format of the public key field. + +</p> +<p> +A value of 0 indicates that no key is present. + +</p> +<p> +The following values are defined: + +<blockquote class="text"><dl> +<dt>1</dt> +<dd>A DSA key is present, in the format defined in RFC2536 <a href="#RFC2536">[11]</a> +</dd> +<dt>2</dt> +<dd>A RSA key is present, in the format defined in RFC3110 <a href="#RFC3110">[12]</a> +</dd> +</dl></blockquote><p> +</p> +<a name="rfc.section.2.4"></a><h4><a name="gatewaytype">2.4</a> RDATA format - gateway type</h4> + +<p> +The gateway type field indicates the format of the information that +is stored in the gateway field. + +</p> +<p> +The following values are defined: + +<blockquote class="text"><dl> +<dt>0</dt> +<dd>No gateway is present +</dd> +<dt>1</dt> +<dd>A 4-byte IPv4 address is present +</dd> +<dt>2</dt> +<dd>A 16-byte IPv6 address is present +</dd> +<dt>3</dt> +<dd>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. +</dd> +</dl></blockquote><p> +</p> +<a name="rfc.section.2.5"></a><h4><a name="anchor7">2.5</a> RDATA format - gateway</h4> + +<p> +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. + +</p> +<p> +There are three formats: + +</p> +<p> +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 +<a href="#RFC1035">RFC1035</a>[2]. This is a 32-bit number in network byte order. + +</p> +<p>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 +<a href="#RFC1886">RFC1886</a>[7]. This is a 128-bit number in network byte order. + +</p> +<p> +The gateway field is a normal wire-encoded domain name, as described +in section 3.3 of RFC1035 <a href="#RFC1035">[2]</a>. Compression MUST NOT be used. + +</p> +<a name="rfc.section.2.6"></a><h4><a name="anchor8">2.6</a> RDATA format - public keys</h4> + +<p> +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. + +</p> +<p> +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. + +</p> +<p>The DSA key format is defined in RFC2536 <a href="#RFC2536">[11]</a> +</p> +<p>The RSA key format is defined in RFC3110 <a href="#RFC3110">[12]</a>, +with the following changes: +</p> +<p> +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. + +</p> +<a name="anchor9"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<a name="rfc.section.3"></a><h3>3. Presentation formats</h3> + +<a name="rfc.section.3.1"></a><h4><a name="anchor10">3.1</a> Representation of IPSECKEY RRs</h4> + +<p> + 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. + +</p> +<p> + The algorithm field is an unsigned integer. No mnemonics are defined. + +</p> +<p> + If no gateway is to be indicated, then the gateway type field MUST + be zero, and the gateway field MUST be "." + +</p> +<p> + 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 +<a href="#RFC1521">RFC1521</a>[3] Section 5.2. + +</p> +<p> + The general presentation for the record as as follows: +</p> +</font><pre> +IN IPSECKEY ( precedence gateway-type algorithm + gateway base64-encoded-public-key ) +</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> +<p> + +</p> +<a name="rfc.section.3.2"></a><h4><a name="anchor11">3.2</a> Examples</h4> + +<p> +An example of a node 192.0.2.38 that will accept IPsec tunnels on its +own behalf. +</p> +</font><pre> +38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.38 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) +</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> +<p> + +</p> +<p> +An example of a node, 192.0.2.38 that has published its key only. +</p> +</font><pre> +38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 + . + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) +</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> +<p> + +</p> +<p> +An example of a node, 192.0.2.38 that has delegated authority to the node +192.0.2.3. +</p> +</font><pre> +38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.3 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) +</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> +<p> + +</p> +<p> +An example of a node, 192.0.1.38 that has delegated authority to the node +with the identity "mygateway.example.com". +</p> +</font><pre> +38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 + mygateway.example.com. + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) +</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> +<p> + +</p> +<p> +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 +</p> +</font><pre> +$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== ) +</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> +<p> + +</p> +<a name="anchor12"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<a name="rfc.section.4"></a><h3>4. Security Considerations</h3> + +<p> + This entire memo pertains to the provision of public keying material + for use by key management protocols such as ISAKMP/IKE (RFC2407) + <a href="#RFC2407">[9]</a>. + +</p> +<p> +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. + +</p> +<p> +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. + +</p> +<p> + 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. + +</p> +<a name="rfc.section.4.1"></a><h4><a name="anchor13">4.1</a> Active attacks against unsecured IPSECKEY resource records</h4> + +<p> +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. + +</p> +<p> +The first kind of active attack is when the attacker replaces the +keying material with either a key under its control or with garbage. + +</p> +<p> +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. + +</p> +<p> +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. + +</p> +<p> +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. + +</p> +<p> +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. + +</p> +<p> +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. + +</p> +<p> +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. + +</p> +<a name="anchor14"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<a name="rfc.section.5"></a><h3>5. IANA Considerations</h3> + +<p> +This document updates the IANA Registry for DNS Resource Record Types +by assigning type X to the IPSECKEY record. + +</p> +<p> +This document creates an IANA registry for the algorithm type field. + +</p> +<p> +Values 0, 1 and 2 are defined in <a href="#algotype">RDATA format - algorithm type</a>. Algorithm numbers +3 through 255 can be assigned by IETF Consensus (<a href="#RFC2434">see RFC2434</a>[6]). + +</p> +<p> +This document creates an IANA registry for the gateway type field. + +</p> +<p> +Values 0, 1, 2 and 3 are defined in <a href="#gatewaytype">RDATA format - gateway type</a>. +Algorithm numbers 4 through 255 can be assigned by +Standards Action (<a href="#RFC2434">see RFC2434</a>[6]). + +</p> +<a name="anchor15"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<a name="rfc.section.6"></a><h3>6. Acknowledgments</h3> + +<p> +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. + +</p> +<a name="rfc.references1"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<h3>Normative references</h3> +<table width="99%" border="0"> +<tr><td class="author-text" valign="top"><b><a name="RFC1034">[1]</a></b></td> +<td class="author-text">Mockapetris, P., "<a href="ftp://ftp.isi.edu/in-notes/rfc1034.txt">Domain names - concepts and facilities</a>", STD 13, RFC 1034, November 1987.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC1035">[2]</a></b></td> +<td class="author-text"><a href="mailto:">Mockapetris, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1035.txt">Domain names - implementation and specification</a>", STD 13, RFC 1035, November 1987.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC1521">[3]</a></b></td> +<td class="author-text"><a href="mailto:nsb@bellcore.com">Borenstein, N.</a> and <a href="mailto:">N. Freed</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1521.txt">MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies</a>", RFC 1521, September 1993.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC2026">[4]</a></b></td> +<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2026.txt">The Internet Standards Process -- Revision 3</a>", BCP 9, RFC 2026, October 1996.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC2065">[5]</a></b></td> +<td class="author-text"><a href="mailto:dee@cybercash.com">Eastlake, D.</a> and <a href="mailto:charlie_kaufman@iris.com">C. Kaufman</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2065.txt">Domain Name System Security Extensions</a>", RFC 2065, January 1997.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC2434">[6]</a></b></td> +<td class="author-text"><a href="mailto:narten@raleigh.ibm.com">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no">H. Alvestrand</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2434.txt">Guidelines for Writing an IANA Considerations Section in RFCs</a>", BCP 26, RFC 2434, October 1998.</td></tr> +</table> + +<a name="rfc.references2"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<h3>Non-normative references</h3> +<table width="99%" border="0"> +<tr><td class="author-text" valign="top"><b><a name="RFC1886">[7]</a></b></td> +<td class="author-text"><a href="mailto:set@thumper.bellcore.com">Thomson, S.</a> and <a href="mailto:Christian.Huitema@MIRSA.INRIA.FR">C. Huitema</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1886.txt">DNS Extensions to support IP version 6</a>", RFC 1886, December 1995.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC2119">[8]</a></b></td> +<td class="author-text"><a href="mailto:-">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC2407">[9]</a></b></td> +<td class="author-text"><a href="mailto:ddp@network-alchemy.com">Piper, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2407.txt">The Internet IP Security Domain of Interpretation for ISAKMP</a>", RFC 2407, November 1998.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC2535">[10]</a></b></td> +<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2535.txt">Domain Name System Security Extensions</a>", RFC 2535, March 1999.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC2536">[11]</a></b></td> +<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2536.txt">DSA KEYs and SIGs in the Domain Name System (DNS)</a>", RFC 2536, March 1999.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC3110">[12]</a></b></td> +<td class="author-text">Eastlake, D., "<a href="ftp://ftp.isi.edu/in-notes/rfc3110.txt">RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</a>", RFC 3110, May 2001.</td></tr> +<tr><td class="author-text" valign="top"><b><a name="RFC3445">[13]</a></b></td> +<td class="author-text">Massey, D. and S. Rose, "<a href="ftp://ftp.isi.edu/in-notes/rfc3445.txt">Limiting the Scope of the KEY Resource Record (RR)</a>", RFC 3445, December 2002.</td></tr> +</table> + +<a name="rfc.authors"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<h3>Author's Address</h3> +<table width="99%" border="0" cellpadding="0" cellspacing="0"> +<tr><td class="author-text"> </td> +<td class="author-text">Michael C. Richardson</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Sandelman Software Works</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">470 Dawson Avenue</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Ottawa, ON K1Z 5V7</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">CA</td></tr> +<tr><td class="author" align="right">EMail: </td> +<td class="author-text"><a href="mailto:mcr@sandelman.ottawa.on.ca">mcr@sandelman.ottawa.on.ca</a></td></tr> +<tr><td class="author" align="right">URI: </td> +<td class="author-text"><a href="http://www.sandelman.ottawa.on.ca/">http://www.sandelman.ottawa.on.ca/</a></td></tr> +</table> +<a name="rfc.copyright"><br><hr size="1" shade="0"></a> +<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> +<h3>Full Copyright Statement</h3> +<p class='copyright'> +Copyright (C) The Internet Society (2003). All Rights Reserved.</p> +<p class='copyright'> +This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it +or assist in its implementation may be prepared, copied, published and +distributed, in whole or in part, without restriction of any kind, +provided that the above copyright notice and this paragraph are +included on all such copies and derivative works. However, this +document itself may not be modified in any way, such as by removing +the copyright notice or references to the Internet Society or other +Internet organizations, except as needed for the purpose of +developing Internet standards in which case the procedures for +copyrights defined in the Internet Standards process must be +followed, or as required to translate it into languages other than +English.</p> +<p class='copyright'> +The limited permissions granted above are perpetual and will not be +revoked by the Internet Society or its successors or assigns.</p> +<p class='copyright'> +This document and the information contained herein is provided on an +"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING +TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING +BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION +HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF +MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p> +<h3>Acknowledgement</h3> +<p class='copyright'> +Funding for the RFC Editor function is currently provided by the +Internet Society.</p> +</font></body></html> |