rfc8945xml2.original.xml   rfc8945.xml 
<?xml version="1.0"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<?rfc tocappendix="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?rfc comments="no" ?>
<?rfc inline="yes" ?>
<!-- includes pre RFC 5378 (2008) material --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
<rfc category="std" docName="draft-ietf-dnsop-rfc2845bis-09" category="std" consensus="true" docName="draft-ietf-dnsop-rfc2845bis-09"
ipr="pre5378Trust200902" obsoletes="2845, 4635" > number="8945" ipr="pre5378Trust200902" obsoletes="2845, 4635" updates=""
xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true"
sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.46.0 -->
<front> <front>
<title abbrev="DNS TSIG">Secret Key Transaction Authentication for DNS (TSIG )</title> <title abbrev="DNS TSIG">Secret Key Transaction Authentication for DNS (TSIG )</title>
<seriesInfo name="RFC" value="8945"/>
<seriesInfo name="STD" value="93"/>
<author fullname="Francis Dupont" initials="F" surname="Dupont"> <author fullname="Francis Dupont" initials="F" surname="Dupont">
<organization abbrev="ISC">Internet Systems Consortium, Inc.</organization > <organization abbrev="ISC">Internet Systems Consortium, Inc.</organization >
<address> <address>
<postal> <postal>
<street>PO Box 360</street> <street>PO Box 360</street>
<city>Newmarket</city> <city>Newmarket</city>
<region>NH</region> <region>NH</region>
<code>03857</code> <code>03857</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>Francis.Dupont@fdupont.fr</email> <email>Francis.Dupont@fdupont.fr</email>
</address> </address>
</author> </author>
<author fullname="Stephen Morris" initials="S" surname="Morris"> <author fullname="Stephen Morris" initials="S" surname="Morris">
<organization abbrev="ISC">Internet Systems Consortium, Inc.</organization > <organization abbrev="Unaffiliated">Unaffiliated</organization>
<address> <address>
<postal> <postal>
<street>PO Box 360</street> <country>United Kingdom</country>
<city>Newmarket</city> </postal>
<region>NH</region>
<code>03857</code>
<country>United States of America</country>
</postal>
<email>sa.morris8@gmail.com</email> <email>sa.morris8@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Paul Vixie" initials="P" surname="Vixie"> <author fullname="Paul Vixie" initials="P" surname="Vixie">
<organization abbrev="Farsight">Farsight Security Inc</organization> <organization abbrev="Farsight">Farsight Security Inc</organization>
<address> <address>
<postal> <postal>
<street>177 Bovet Road, Suite 180</street> <street>177 Bovet Road</street>
<extaddr>Suite 180</extaddr>
<city>San Mateo</city> <city>San Mateo</city>
<region>CA</region> <region>CA</region>
<code>94402</code> <code>94402</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>paul@redbarn.org</email> <email>paul@redbarn.org</email>
</address> </address>
</author> </author>
<author fullname="Donald E. Eastlake 3rd" initials="D" surname="Eastlake 3rd "> <author fullname="Donald E. Eastlake 3rd" initials="D" surname="Eastlake 3rd ">
<organization abbrev="Futurewei">Futurewei Technologies</organization> <organization abbrev="Futurewei">Futurewei Technologies</organization>
<address> <address>
<postal> <postal>
<street>2386 Panoramic Circle</street> <street>2386 Panoramic Circle</street>
<city>Apopka</city> <city>Apopka</city>
<region>FL</region> <region>FL</region>
<code>32703</code> <code>32703</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
skipping to change at line 96 skipping to change at line 66
<postal> <postal>
<street>2386 Panoramic Circle</street> <street>2386 Panoramic Circle</street>
<city>Apopka</city> <city>Apopka</city>
<region>FL</region> <region>FL</region>
<code>32703</code> <code>32703</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>d3e3e3@gmail.com</email> <email>d3e3e3@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Olafur Gudmundsson" initials="O" surname="Gudmundsson"> <author fullname="Olafur Gudmundsson" initials="O" surname="Gudmundsson">
<organization abbrev="Cloudflare">Cloudflare</organization> <organization abbrev="Cloudflare">Cloudflare</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>San Francisco</city> <city></city>
<region>CA</region> <region></region>
<code>94107</code> <code></code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>olafur+ietf@cloudflare.com</email> <email>olafur+ietf@cloudflare.com</email>
</address> </address>
</author> </author>
<author fullname="Brian Wellington" initials="B" surname="Wellington"> <author fullname="Brian Wellington" initials="B" surname="Wellington">
<organization abbrev="Akamai">Akamai</organization> <organization abbrev="Akamai">Akamai</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>bwelling@akamai.com</email> <email>bwelling@akamai.com</email>
</address> </address>
</author> </author>
skipping to change at line 121 skipping to change at line 89
<author fullname="Brian Wellington" initials="B" surname="Wellington"> <author fullname="Brian Wellington" initials="B" surname="Wellington">
<organization abbrev="Akamai">Akamai</organization> <organization abbrev="Akamai">Akamai</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>bwelling@akamai.com</email> <email>bwelling@akamai.com</email>
</address> </address>
</author> </author>
<date year="2020" month="November" />
<date/>
<area>Operations and Management Area</area> <area>Operations and Management Area</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>Internet Engineering Task Force</workgroup>
<abstract> <abstract>
<t>This document describes a protocol for transaction level authentication <t>This document describes a protocol for transaction-level authentication
using shared secrets and one way hashing. It can be used to authenticate using shared secrets and one-way hashing. It can be used to authenticate
dynamic updates to a DNS zone as coming from an approved client, or to aut dynamic updates to a DNS zone as coming from an approved client or to
henticate authenticate responses as coming from an approved name server.</t>
responses as coming from an approved name server.</t> <t>No recommendation is made here for distributing the shared secrets;
<t>No recommendation is made here for distributing the shared secrets:
it is expected that a network administrator will statically configure it is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism.</t> name servers and clients using some out-of-band mechanism.</t>
<t>This document obsoletes RFCs 2845 and 4635.</t>
<t>This document obsoletes RFC2845 and RFC4635.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<section title="Background"> <name>Introduction</name>
<t>The Domain Name System (DNS, <xref target="RFC1034"/>, <xref <section numbered="true" toc="default">
target="RFC1035"/>) is a replicated hierarchical distributed <name>Background</name>
<t>The Domain Name System (DNS) (<xref target="RFC1034"
format="default"/> <xref target="RFC1035" format="default"/>) is a
replicated hierarchical distributed
database system that provides information fundamental to Internet database system that provides information fundamental to Internet
operations, such as name to address translation and mail operations, such as name-to-address translation and mail-handling
handling information.</t> information.</t>
<t>This document specifies use of a message authentication code <t>This document specifies use of a message authentication code
(MAC), generated using certain keyed hash functions, to (MAC), generated using certain keyed hash functions, to
provide an efficient means of point-to-point authentication and provide an efficient means of point-to-point authentication and
integrity checking for DNS transactions. Such transactions include integrity checking for DNS transactions. Such transactions include
DNS update requests and responses for which this can provide a lightweig ht DNS update requests and responses for which this can provide a lightweig ht
alternative to the secure DNS dynamic update protocol described by <xref alternative to the secure DNS dynamic update protocol described by
target="RFC3007"/>.</t> <xref target="RFC3007" format="default"/>.</t>
<t>A further use of this mechanism is to protect zone transfers. <t>A further use of this mechanism is to protect zone transfers.
In this case the data covered would be the whole zone transfer In this case, the data covered would be the whole zone transfer
including any glue records sent. The protocol described by DNSSEC including any glue records sent. The protocol described by DNSSEC
(<xref target="RFC4033"/>, <xref target="RFC4034"/>, (<xref target="RFC4033" format="default"/>, <xref target="RFC4034" forma
<xref target="RFC4035"/>) does not protect glue records and unsigned t="default"/>,
<xref target="RFC4035" format="default"/>) does not protect glue records
and unsigned
records.</t> records.</t>
<t>The authentication mechanism proposed here provides a <t>The authentication mechanism proposed here provides a
simple and efficient authentication between clients and servers, simple and efficient authentication between clients and servers,
by using shared secret keys to establish a trust relationship between by using shared secret keys to establish a trust relationship between
two entities. Such keys must be protected in a manner similar to two entities. Such keys must be protected in a manner similar to
private keys, lest a third party masquerade as one of the intended private keys, lest a third party masquerade as one of the intended
parties (by forging the MAC). The proposal is unsuitable for general parties (by forging the MAC). The proposal is unsuitable for general
server to server authentication and for servers which speak with many server-to-server authentication and for servers that speak with many
other servers, since key management would become unwieldy with the other servers, since key management would become unwieldy with the
number of shared keys going up quadratically. But it is suitable for number of shared keys going up quadratically. But it is suitable for
many resolvers on hosts that only talk to a few recursive servers.</t> many resolvers on hosts that only talk to a few recursive servers.</t>
</section>
</section> <section numbered="true" toc="default">
<section title="Protocol Overview"> <name>Protocol Overview</name>
<t>Secret Key Transaction Authentication makes use of signatures <t>Secret Key Transaction Authentication makes use of signatures
on messages sent between the parties involved (e.g. resolver and on messages sent between the parties involved (e.g., resolver and
server). These are known as "transaction signatures", or TSIG. server). These are known as "transaction signatures", or TSIG.
For historical reasons, in this document they are referred to as For historical reasons, in this document, they are referred to as
message authentication codes (MAC).</t> message authentication codes (MACs).</t>
<t>Use of TSIG presumes prior agreement between the
<t>Use of TSIG presumes prior agreement between the
two parties involved (e.g., resolver and server) as to any two parties involved (e.g., resolver and server) as to any
algorithm and key to be used. The way that this agreement algorithm and key to be used. The way that this agreement
is reached is outside the scope of the document.</t> is reached is outside the scope of the document.</t>
<t>A DNS message exchange involves the sending of a query and the
<t>A DNS message exchange involves the sending of a query and the
receipt of one of more DNS messages in response. For receipt of one of more DNS messages in response. For
the query, the MAC is calculated based on the hash of the contents the query, the MAC is calculated based on the hash of the contents
and the agreed TSIG key. The MAC for the response is similar, but and the agreed TSIG key. The MAC for the response is similar but
also includes the MAC of the query as part of the calculation. also includes the MAC of the query as part of the calculation.
Where a response comprises multiple packets, the calculation of Where a response comprises multiple packets, the calculation of
the MAC associated with the second and subsequent packets includes in the MAC associated with the second and subsequent packets includes in
its inputs the MAC for the preceding packet. its inputs the MAC for the preceding packet.
In this way it is possible to detect any interruption in the In this way, it is possible to detect any interruption in the
packet sequence, although not its premature termination.</t> packet sequence, although not its premature termination.</t>
<t>The MAC is contained in a TSIG resource record included
<t>The MAC is contained in a TSIG resource record included in the additional section of the DNS message.</t>
in the Additional Section of the DNS message.</t> </section>
</section> <section numbered="true" toc="default">
<section title="Document History"> <name>Document History</name>
<t>TSIG was originally specified by <xref target="RFC2845"/>. <t>TSIG was originally specified by <xref target="RFC2845" format="defau
In 2017, two nameserver implementations strictly following that documen lt"/>.
t (and In 2017, two name server implementations strictly following that docume
the related <xref target="RFC4635"/>) were discovered to have nt (and
security problems related to this feature (<xref target="CVE-2017-3142" the related <xref target="RFC4635" format="default"/>) were discovered
/>, to have
<xref target="CVE-2017-3143"/>, <xref target="CVE-2017-11104"/>). The security problems related to this feature (<xref
implementations target="CVE-2017-3142" format="default"/>,
were fixed but, to avoid similar problems in the future, the <xref target="CVE-2017-3143" format="default"/>, <xref
target="CVE-2017-11104" format="default"/>). The implementations
were fixed, but to avoid similar problems in the future, the
two documents were updated and merged, producing this revised two documents were updated and merged, producing this revised
specification for TSIG.</t> specification for TSIG.</t>
<t>While TSIG implemented according to this RFC provides for enhanced
security, there are no changes in interoperability. TSIG on the wire
is still the same mechanism described in <xref target="RFC2845"
format="default"/>; only the checking semantics have been
changed.
<t>While TSIG implemented according to this RFC provides for enhanced See <xref target="issuesfixed" format="default"/> for
security, there are no changes in interoperability. TSIG is on the wire further details.</t>
still the same mechanism described in <xref target="RFC2845"/>; only </section>
the checking semantics have been changed. See <xref target="issuesfixed
"/>
for further details.</t>
</section>
</section>
<section title="Key Words" anchor="keywords">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="keywords" numbered="true" toc="default">
<section title="Assigned Numbers" anchor="numbers"> <name>Key Words</name>
<t>This document defines the following RR type and associated value:</t> <t>
<t><list style="hanging" hangIndent="6"> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>TSIG (250)</t> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
</list></t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="numbers" numbered="true" toc="default">
<name>Assigned Numbers</name>
<t>This document defines the following Resource Record (RR) type and
associated value:</t>
<ul empty="true">
<li>TSIG (250)</li>
</ul>
<t>In addition, the document also defines the following DNS RCODEs <t>In addition, the document also defines the following DNS RCODEs
and associated names:</t> and associated names:</t>
<t><list style="hanging" hangIndent="6"> <ul empty="true" spacing="compact">
<t>16 (BADSIG)<vspace/> <li>16 (BADSIG)</li>
17 (BADKEY)<vspace/> <li>17 (BADKEY)</li>
18 (BADTIME)<vspace/> <li>18 (BADTIME)</li>
22 (BADTRUNC)</t> <li>22 (BADTRUNC)</li>
</list></t> </ul>
<t>(See <xref target="RFC6895"/> Section 2.3 concerning the assignment <t>(See <xref target="RFC6895" sectionFormat="of" section="2.3"/>
of the value 16 to BADSIG.)</t> concerning the assignment of the value 16 to BADSIG.)</t>
<t>These RCODES may appear within the "Error" field of a TSIG RR.</t> <t>These RCODES may appear within the "Error" field of a TSIG RR.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="TSIG RR Format"> <name>TSIG RR Format</name>
<section title="TSIG RR Type"> <section numbered="true" toc="default">
<name>TSIG RR Type</name>
<t>To provide secret key authentication, we use an RR <t>To provide secret key authentication, we use an RR
type whose mnemonic is TSIG and whose type code is 250. type whose mnemonic is TSIG and whose type code is 250.
TSIG is a meta-RR and MUST NOT be cached. TSIG RRs are TSIG is a meta-RR and <bcp14>MUST NOT</bcp14> be cached. TSIG RRs are
used for authentication between DNS entities that have used for authentication between DNS entities that have
established a shared secret key. TSIG RRs are dynamically established a shared secret key. TSIG RRs are dynamically
computed to cover a particular DNS transaction and are not computed to cover a particular DNS transaction and are not
DNS RRs in the usual sense.</t> DNS RRs in the usual sense.</t>
<t>As the TSIG RRs are related to one DNS request/response, <t>As the TSIG RRs are related to one DNS request/response,
there is no value in storing or retransmitting them, thus the there is no value in storing or retransmitting them; thus, the
TSIG RR is discarded once it has been used to authenticate a DNS TSIG RR is discarded once it has been used to authenticate a DNS
message.</t> message.</t>
</section> </section>
<section anchor="format" numbered="true" toc="default">
<section title="TSIG Record Format" anchor="format"> <name>TSIG Record Format</name>
<t>The fields of the TSIG RR are described below. As is usual, <t>The fields of the TSIG RR are described below. All multi-octet integ
all multi-octet integers in the record are sent in network byte ers in the record are sent in network byte
order (see <xref target="RFC1035"/> 2.3.2).</t> order (see <xref target="RFC1035" sectionFormat="of" section="2.3.2"/>).
</t>
<t><list style="hanging" hangIndent="6"> <dl newline="false" spacing="normal">
<dt>NAME:</dt>
<t hangText="NAME">The name of the key used, in domain <dd><t>The name of the key used, in domain
name syntax. The name should reflect the names of the name syntax. The name should reflect the names of the
hosts and uniquely identify the key among a set of keys hosts and uniquely identify the key among a set of keys
these two hosts may share at any given time. For example, these two hosts may share at any given time. For example,
if hosts if hosts
A.site.example and B.example.net share a key, possibilities A.site.example and B.example.net share a key, possibilities
for the key name include &lt;id&gt;.A.site.example, for the key name include &lt;id&gt;.A.site.example,
&lt;id&gt;.B.example.net, and &lt;id&gt;.B.example.net, and
&lt;id&gt;.A.site.example.B.example.net. It should be &lt;id&gt;.A.site.example.B.example.net. It should be
possible for more than one key to be in simultaneous use possible for more than one key to be in simultaneous use
among a set of interacting hosts. This allows for periodic among a set of interacting hosts. This allows for periodic
key rotation as per best operational practices, as well as key rotation as per best operational practices, as well as
algorithm agility as indicated by <xref target="BCP201"/>.</t> algorithm agility as indicated by <xref target="RFC7696" format="defau
lt"/>.</t>
<t>The name may be used as a local index <t>The name may be used as a local index
to the key involved but it is recommended that it be to the key involved, but it is recommended that it be
globally unique. Where a key is just shared between two globally unique. Where a key is just shared between two
hosts, its name actually need only be meaningful to hosts, its name actually need only be meaningful to
them but it is recommended that the key name be mnemonic them, but it is recommended that the key name be mnemonic
and incorporates the names of participating agents or and incorporate the names of participating agents or
resources as suggested above.</t> resources as suggested above.</t></dd>
<dt>TYPE:</dt>
<t hangText="TYPE">This MUST be TSIG (250: Transaction SIGnature)</t> <dd>This <bcp14>MUST</bcp14> be TSIG (250: Transaction SIGnature).</dd
>
<t hangText="CLASS">This MUST be ANY</t> <dt>CLASS:</dt>
<dd>This <bcp14>MUST</bcp14> be ANY.</dd>
<t hangText="TTL">This MUST be 0</t> <dt>TTL:</dt>
<dd>This <bcp14>MUST</bcp14> be 0.</dd>
<t hangText="RdLen">(variable)</t> <dt>RDLENGTH:</dt>
<dd>(variable)</dd>
<t hangText="RDATA">The RDATA for a TSIG RR consists of a <dt>RDATA:</dt>
number of fields, described below:</t> <dd>The RDATA for a TSIG RR consists of a
</list></t> number of fields, described below:</dd>
</dl>
<figure><artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Algorithm Name / / Algorithm Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Time Signed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Signed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Fudge | | | Fudge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Size | / | MAC Size | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original ID | Error | | Original ID | Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Len | / | Other Len | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Other Data / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Other Data /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure> ]]></artwork>
<t>The contents of the RDATA fields are:</t>
<t><list style="hanging" hangIndent="6"> <dl newline="true" spacing="normal">
<t>The contents of the RDATA fields are: <dt>Algorithm Name:</dt>
<list style="symbols"> <dd>an octet sequence identifying the TSIG algorithm in the
domain name syntax. (Allowed names are listed in <xref
<t>Algorithm Name - a octet sequence identifying the TSIG algorith target="allowed-algorithms" format="default"/>.) The name is stored
m name in in the DNS name wire format as described in <xref target="RFC1034"
the domain name syntax. (Allowed names are listed in format="default"/>. As per <xref target="RFC3597"
<xref target="allowed-algorithms"/>.) The name is stored in the format="default"/>, this name <bcp14>MUST NOT</bcp14> be
DNS name wire format as described in <xref target="RFC1034"/>. compressed.</dd>
As per <xref target="RFC3597"/>, this name MUST NOT be <dt>Time Signed:</dt>
compressed.</t> <dd>an unsigned 48-bit integer containing the time the message was
signed as seconds since 00:00 on 1970-01-01 UTC, ignoring leap
<t>Time Signed - an unsigned 48-bit integer containing seconds.</dd>
the time the message was signed as seconds since <dt>Fudge:</dt>
00:00 on 1970-01-01 UTC, ignoring leap seconds.</t> <dd>an unsigned 16-bit integer specifying the allowed time
difference in seconds permitted in the Time Signed field.</dd>
<t>Fudge - an unsigned 16-bit integer specifying the allowed <dt>MAC Size:</dt>
time difference in <dd>an unsigned 16-bit integer giving the length of the MAC field in
seconds permitted in the Time Signed field.</t> octets. Truncation is indicated by a MAC Size less than the size of
the keyed hash produced by the algorithm specified by the Algorithm
<t>MAC Size - an unsigned 16-bit integer giving the length of MAC Name.</dd>
field in octets. Truncation is indicated by a MAC size less <dt>MAC:</dt>
than the size of the keyed hash produced by the algorithm <dd>a sequence of octets whose contents are defined by the TSIG
specified by the Algorithm Name.</t> algorithm used, possibly truncated as specified by the MAC Size. The
length of this field is given by the MAC Size. Calculation of the
<t>MAC - a sequence of octets whose contents are defined by the MAC is detailed in <xref target="mac_computation"
TSIG algorithm used, possibly truncated as specified by format="default"/>.</dd>
MAC Size. The length of this field is given by the Mac Size. <dt>Original ID:</dt>
Calculation of the MAC is detailed in <xref target="mac_computatio <dd>an unsigned 16-bit integer holding the message ID of the
n"/>.</t> original request message. For a TSIG RR on a request, it is set
equal to the DNS message ID. In a TSIG attached to a response -- or
<t>Original ID - An unsigned 16-bit integer holding in cases such as the forwarding of a dynamic update request -- the
the message ID of the original request message. field contains the ID of the original DNS request.</dd>
For a TSIG RR on a request, it is set equal to the DNS message ID. <dt>Error:</dt>
In a TSIG attached to a response - or in cases such as the <dd>in responses, an unsigned 16-bit integer containing the extended
forwarding of a dynamic update request - the field contains the RCODE covering TSIG processing. In requests, this
ID of the original DNS request.</t> <bcp14>MUST</bcp14> be zero.</dd>
<dt>Other Len:</dt>
<t>Error - in responses, an unsigned 16-bit integer containing <dd>an unsigned 16-bit integer specifying the length of the Other
the extended RCODE covering TSIG processing. In requests, this Data field in octets.</dd>
MUST be zero.</t> <dt>Other Data:</dt>
<dd>additional data relevant to the TSIG record. In responses, this
<t>Other Len - an unsigned 16-bit integer specifying the length will be empty (i.e., Other Len will be zero) unless the content of
of the "Other Data" field in octets.</t> the Error field is BADTIME, in which case it will be a 48-bit
unsigned integer containing the server's current time as the number
<t>Other Data - additional data relevant to the TSIG record. of seconds since 00:00 on 1970-01-01 UTC, ignoring leap seconds (see
In responses, this will be empty (i.e. "Other Len" will be zero) <xref target="time_check" format="default"/>). This document assigns
unless the content of the Error field is BADTIME, in which case it no meaning to its contents in requests.</dd>
will be a 48-bit unsigned integer containing the server's current </dl>
time as the number of seconds since 00:00 on 1970-01-01 UTC, ignor
ing
leap seconds (see <xref target="time_check"/>). This document assi
gns
no meaning to its contents in requests.</t>
</list>
</t>
</list></t>
</section> </section>
<section title="MAC Computation" anchor="mac_computation"> <section anchor="mac_computation" numbered="true" toc="default">
<name>MAC Computation</name>
<t>When generating or verifying the contents of a TSIG record, <t>When generating or verifying the contents of a TSIG record,
the data listed in the rest of this section are passed, the data listed in the rest of this section are passed,
in the order listed below, as input to MAC computation. The in the order listed below, as input to MAC computation. The
data are passed in network byte order or wire format, data are passed in network byte order or wire format,
as appropriate, and are fed into the hashing function as appropriate and are fed into the hashing function
as a continuous octet sequence with no inter-field separator or as a continuous octet sequence with no interfield separator or
padding.</t> padding.</t>
<section numbered="true" toc="default">
<section title="Request MAC"> <name>Request MAC</name>
<t>Only included in the computation of a MAC for a response message <t>Only included in the computation of a MAC for a response message
(or the first message in a multi-message response), (or the first message in a multi-message response),
the validated request MAC MUST be included in the MAC the validated request MAC <bcp14>MUST</bcp14> be included in the MAC
computation. If the request MAC failed to validate, an unsigned computation. If the request MAC failed to validate, an unsigned
error message MUST be returned instead. (<xref error message <bcp14>MUST</bcp14> be returned instead (<xref
target="on_error"/>).</t> target="on_error" format="default"/>).</t>
<t>The request's MAC, comprising the following fields, is digested in <t>The request's MAC, comprising the following fields, is digested in
wire format:</t> wire format:</t>
<table anchor="mac-field" align="center">
<name>Request's MAC</name>
<thead>
<tr>
<th align="left">Field</th>
<th align="left">Type</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">MAC Size</td>
<td align="left">Unsigned 16-bit integer</td>
<td align="left">in network byte order</td>
</tr>
<tr>
<td align="left">MAC Data</td>
<td align="left">octet sequence</td>
<td align="left">exactly as transmitted</td>
</tr>
</tbody>
</table>
<t>Special considerations apply to the TSIG calculation for the
second and subsequent messages in a response that consists of multiple
DNS messages (e.g., a zone transfer).
<texttable style="headers"> These are described in <xref
<ttcol>Field</ttcol> target="tcp" format="default"/>.</t>
<ttcol>Type</ttcol>
<ttcol>Description</ttcol>
<c>MAC Length</c>
<c>Unsigned 16-bit integer</c>
<c>in network byte order</c>
<c>MAC Data</c>
<c>octet sequence</c>
<c>exactly as transmitted</c>
</texttable>
<t>Special considerations apply to the TSIG calculation for the
second and subsequent messages a response
that consists of multiple DNS messages (e.g. a zone transfer).
These are described in <xref target="tcp"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<name>DNS Message</name>
<t>In the MAC computation, the whole/complete DNS message in
wire format is used.</t>
<section title="DNS Message"> <t>When creating an outgoing message, the TSIG is based on
<t>The DNS message used in the MAC computation is the message content before
a whole and complete DNS message in wire format.</t> the TSIG
RR has been added to the additional section and before the
<t>When creating a TSIG, it is the message before DNS Message Header's ARCOUNT has been incremented to include
the TSIG RR has been added to the additional data section the TSIG RR.</t>
and before the DNS Message Header's ARCOUNT field has
been incremented to contain the TSIG RR.</t>
<t>When verifying an incoming message, it is the message after
the TSIG RR has been removed and the ARCOUNT field
decremented. If the message ID differs from the original
message ID, the original message ID is substituted for the
message ID. (This could happen, for example, when forwarding
a dynamic update request.)</t>
<t>When verifying an incoming message, the TSIG is checked against
the message after the TSIG RR has been removed, the ARCOUNT
decremented, and the message ID replaced by the original message
ID from the TSIG if those IDs differ. (This could happen, for
example, when forwarding a dynamic update request.)</t>
</section> </section>
<section numbered="true" toc="default">
<section title="TSIG Variables"> <name>TSIG Variables</name>
<t>Also included in the digest is certain information present <t>Also included in the digest is certain information present
in the TSIG RR. Adding this data provides further protection against an in the TSIG RR. Adding this data provides further protection against an
attempt to interfere with the message.</t> attempt to interfere with the message.</t>
<table anchor="tisg-field-names" align="center">
<texttable style="headers" anchor="tisg-field-names"> <name>TSIG Variables</name>
<ttcol>Source</ttcol> <thead>
<ttcol>Field Name</ttcol> <tr>
<ttcol>Notes</ttcol> <th align="left">Source</th>
<th align="left">Field Name</th>
<c>TSIG RR</c> <th align="left">Notes</th>
<c>NAME</c> </tr>
<c>Key name, in canonical wire format</c> </thead>
<tbody>
<c>TSIG RR</c> <tr>
<c>CLASS</c> <td align="left">TSIG RR</td>
<c>(Always ANY in the current specification)</c> <td align="left">NAME</td>
<td align="left">Key name, in canonical wire format</td>
<c>TSIG RR</c> </tr>
<c>TTL</c> <tr>
<c>(Always 0 in the current specification)</c> <td align="left">TSIG RR</td>
<td align="left">CLASS</td>
<c>TSIG RDATA</c> <td align="left"><bcp14>MUST</bcp14> be ANY</td>
<c>Algorithm Name</c> </tr>
<c>in canonical wire format</c> <tr>
<td align="left">TSIG RR</td>
<c>TSIG RDATA</c> <td align="left">TTL</td>
<c>Time Signed</c> <td align="left"><bcp14>MUST</bcp14> be 0</td>
<c>in network byte order</c> </tr>
<tr>
<c>TSIG RDATA</c> <td align="left">TSIG RDATA</td>
<c>Fudge</c> <td align="left">Algorithm Name</td>
<c>in network byte order</c> <td align="left">in canonical wire format</td>
</tr>
<c>TSIG RDATA</c> <tr>
<c>Error</c> <td align="left">TSIG RDATA</td>
<c>in network byte order</c> <td align="left">Time Signed</td>
<td align="left">in network byte order</td>
<c>TSIG RDATA</c> </tr>
<c>Other Len</c> <tr>
<c>in network byte order</c> <td align="left">TSIG RDATA</td>
<td align="left">Fudge</td>
<c>TSIG RDATA</c> <td align="left">in network byte order</td>
<c>Other Data</c> </tr>
<c>exactly as transmitted</c> <tr>
</texttable> <td align="left">TSIG RDATA</td>
<td align="left">Error</td>
<t>The RR RDLEN and RDATA MAC Length are not included in the <td align="left">in network byte order</td>
input to MAC computation since they are not guaranteed to be </tr>
<tr>
<td align="left">TSIG RDATA</td>
<td align="left">Other Len</td>
<td align="left">in network byte order</td>
</tr>
<tr>
<td align="left">TSIG RDATA</td>
<td align="left">Other Data</td>
<td align="left">exactly as transmitted</td>
</tr>
</tbody>
</table>
<t>The RR RDLENGTH and RDATA MAC Size are not included in the
input to MAC computation, since they are not guaranteed to be
knowable before the MAC is generated.</t> knowable before the MAC is generated.</t>
<t>The Original ID field is not included in this section, <t>The Original ID field is not included in this section,
as it has already been substituted for the message ID in as it has already been substituted for the message ID in
the DNS header and hashed.</t> the DNS header and hashed.</t>
<t>For each label type, there must be a defined "Canonical <t>For each label type, there must be a defined "Canonical
wire format" that specifies how to express a label in an wire format" that specifies how to express a label in an
unambiguous way. For label type 00, this is defined in <xref unambiguous way. For label type 00, this is defined in <xref
target="RFC4034"/> Section 6.2. The use of label types other than target="RFC4034" sectionFormat="of" section="6.2"/>. The use of
00 is not defined for this specification.</t> label types other than 00 is not defined for this specification.</t>
<section numbered="true" toc="default">
<section title="Time Values Used in TSIG Calculations"> <name>Time Values Used in TSIG Calculations</name>
<t>The data digested includes the two timer values in the <t>The data digested includes the two timer values in the
TSIG header in order to defend against replay attacks. If TSIG header in order to defend against replay attacks. If
this were not done, an attacker could replay old messages this were not done, an attacker could replay old messages
but update the "Time Signed" and "Fudge" fields to make the but update the Time Signed and Fudge fields to make the
message look new. This data is named "TSIG Timers", and message look new. The two fields are collectively named "TSIG Timer
s", and
for the purpose of MAC calculation, they are hashed in for the purpose of MAC calculation, they are hashed in
their "on the wire" format, in the following order: first their wire format, in the following order: first
Time Signed, then Fudge.</t> Time Signed, then Fudge.</t>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="details" numbered="true" toc="default">
<section title="Protocol Details" anchor="details"> <name>Protocol Details</name>
<section numbered="true" toc="default">
<section title="Generation of TSIG on Requests"> <name>Generation of TSIG on Requests</name>
<t>Once the outgoing record has been constructed, the client performs <t>Once the outgoing record has been constructed, the client performs
the keyed hash (HMAC) computation, appends a TSIG the keyed hash (Hashed Message Authentication Code (HMAC))
record with the calculated MAC to the Additional Data section (increment computation, appends a TSIG record with the
ing calculated MAC to the additional section (incrementing the
the ARCOUNT ARCOUNT to reflect the additional RR), and transmits the request to
to reflect the additional RR), and transmits the request to the server. This TSIG record <bcp14>MUST</bcp14> be the only TSIG RR
the server. This TSIG record MUST be the only TSIG RR in the message in the message and <bcp14>MUST</bcp14> be the last record in the
and MUST be last record in the Additional Data section. The client MUST additional data section. The client <bcp14>MUST</bcp14> store the MAC
store the MAC and the key name from the request while awaiting an answer and the key name from the request while awaiting an answer.</t>
.</t>
<t>The digest components for a request are:</t> <t>The digest components for a request are:</t>
<ul empty="true" spacing="compact">
<t><list style="empty"> <li>DNS Message (request)</li>
<t>DNS Message (request)<vspace/> <li>TSIG Variables (request)</li>
TSIG Variables (request)</t> </ul>
</list></t>
</section> </section>
<section anchor="request_processing" numbered="true" toc="default">
<section title="Server Processing of Request" anchor="request_processing"> <name>Server Processing of Request</name>
<t>If an incoming message contains a TSIG record, it MUST <t>If an incoming message contains a TSIG record, it <bcp14>MUST</bcp14>
be the last record in the additional section. Multiple be the last record in the additional section. Multiple
TSIG records are not allowed. If multiple TSIG records are detected TSIG records are not allowed. If multiple TSIG records are detected
or a TSIG record is present or a TSIG record is present
in any other position, the DNS message is dropped and a response in any other position, the DNS message is dropped and a response
with RCODE 1 (FORMERR) MUST be returned. Upon receipt of with RCODE 1 (FORMERR) <bcp14>MUST</bcp14> be returned. Upon receipt of
a message with exactly one correctly placed TSIG RR, a copy of the a message with exactly one correctly placed TSIG RR, a copy of the
TSIG RR is stored, and the TSIG RR is removed from the DNS Message, TSIG RR is stored and the TSIG RR is removed from the DNS message
and decremented out of the DNS message header's ARCOUNT.</t> and decremented out of the DNS message header's ARCOUNT.</t>
<t>If the TSIG RR cannot be interpreted, the server <bcp14>MUST</bcp14>
<t>If the TSIG RR cannot be interpreted, the server MUST
regard the message as corrupt and return a FORMERR to the server. regard the message as corrupt and return a FORMERR to the server.
Otherwise the server is REQUIRED to return a TSIG RR in Otherwise, the server is <bcp14>REQUIRED</bcp14> to return a TSIG RR in
the response.</t> the response.</t>
<t>To validate the received TSIG RR, the server <bcp14>MUST</bcp14> perf
<t>To validate the received TSIG RR, the server MUST perform the orm the
following checks in the following order:</t> following checks in the following order:</t>
<ol type="1" spacing="normal">
<t><list style="hanging"> <li>Check key</li>
<t>1. Check KEY<vspace/> <li>Check MAC</li>
2. Check MAC<vspace/> <li>Check time values</li>
3. Check TIME values<vspace/> <li>Check truncation policy</li>
4. Check Truncation policy</t> </ol>
</list></t> <section numbered="true" toc="default">
<name>Key Check and Error Handling</name>
<section title="Key Check and Error Handling"> <t>If a non-forwarding server does not recognize the key or
<t>If a non-forwarding server does not recognize the key algorithm used by the client (or recognizes the algorithm but does
or algorithm used by the client (or recognizes the algorithm but does not implement it), the server <bcp14>MUST</bcp14> generate an error
not implement it), the server MUST generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 17 (BADKEY). This
response with RCODE 9 (NOTAUTH) and TSIG ERROR 17 (BADKEY). response <bcp14>MUST</bcp14> be unsigned as specified in <xref
This response MUST be unsigned as specified in <xref target= target="on_error" format="default"/>. The server
"on_error"/>. The server SHOULD log the error. (Special <bcp14>SHOULD</bcp14> log the error. (Special considerations apply
considerations apply to forwarding servers, see to forwarding servers; see <xref target="forwarding"
<xref target="forwarding"/>.)</t> format="default"/>.)</t>
</section> </section>
<section numbered="true" toc="default">
<section title="MAC Check and Error Handling"> <name>MAC Check and Error Handling</name>
<t>Using the information in the TSIG, the server MUST verify <t>Using the information in the TSIG, the server <bcp14>MUST</bcp14> v
erify
the MAC by doing its own calculation and comparing the result with the MAC by doing its own calculation and comparing the result with
the MAC received. If the MAC fails to the MAC received. If the MAC fails to
verify, the server MUST generate an verify, the server <bcp14>MUST</bcp14> generate an
error response as specified in <xref target="on_error"/> with error response as specified in <xref target="on_error" format="default
"/> with
RCODE 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG). This response RCODE 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG). This response
MUST be unsigned as specified in <xref target="on_error"/>. <bcp14>MUST</bcp14> be unsigned, as specified in <xref
The server SHOULD log the error.</t> target="on_error" format="default"/>.
The server <bcp14>SHOULD</bcp14> log the error.</t>
<section title="MAC Truncation" anchor="trunc"> <section anchor="trunc" numbered="true" toc="default">
<t>When space is at a premium and the strength of the full <name>MAC Truncation</name>
<t>When space is at a premium and the strength of the full
length of a MAC is not needed, it is reasonable to truncate length of a MAC is not needed, it is reasonable to truncate
the keyed hash and use the truncated value for the keyed hash and use the truncated value for
authentication. HMAC SHA-1 truncated to 96 bits is an option authentication. HMAC SHA-1 truncated to 96 bits is an option
available in several IETF protocols, including IPsec and TLS. available in several IETF protocols, including IPsec and TLS.
However, while this option is kept for backwards compatibility, However, while this option is kept for backwards compatibility,
it may not provide a security level appropriate for all cases it may not provide a security level appropriate for all cases
in the modern environment. In these cases, it is preferable to in the modern environment. In these cases, it is preferable to
use a hashing algorithm such as SHA-256-128, SHA-384-192 or use a hashing algorithm such as SHA-256-128, SHA-384-192, or
SHA-512-256 <xref target="RFC4868"/>. </t> SHA-512-256 <xref target="RFC4868" format="default"/>. </t>
<t>Processing of a truncated MAC follows these rules:</t>
<dl spacing="normal">
<dt>If the MAC Size field is greater than the keyed hash output
length:</dt><dd>This case <bcp14>MUST NOT</bcp14> be generated an
d, if
received, <bcp14>MUST</bcp14> cause the DNS message to be
dropped and RCODE 1 (FORMERR) to be returned.</dd>
<t>Processing of a truncated MAC follows these rules:</t> <dt>If the MAC Size field equals the keyed hash output length:</dt
<t><list style="numbers"> ><dd>The
<t>If "MAC size" field is greater than keyed hash output length: entire keyed hash output is present and used.</dd>
<vspace/><vspace/> <dt>If the MAC Size field is less than the larger of 10 (octets) a
This case MUST NOT be generated and, if received, nd
MUST cause the DNS message to be dropped and RCODE 1 half the length of the hash function in use:</dt><dd>With the
(FORMERR) to be returned. exception of certain TSIG error messages described
</t> in <xref target="on_error" format="default"/>, where it is
<t>If "MAC size" field equals keyed hash output length: permitted that the MAC Size be zero, this case <bcp14>MUST
<vspace/><vspace/> NOT</bcp14> be generated and, if received, <bcp14>MUST</bcp14>
The entire output keyed hash output is present and used. cause the DNS message to be dropped and RCODE 1 (FORMERR) to
</t> be returned.</dd>
<t>"MAC size" field is less than the larger of 10 (octets) and half <dt>Otherwise:</dt><dd>This is sent when the signer has truncated
the length of the hash function in use: the keyed hash
<vspace/><vspace/> output to an allowable length, as described in <xref
With the exception of certain TSIG error messages target="RFC2104" format="default"/>, taking initial octets and
described in <xref target="on_error"/>, where it is discarding trailing octets. TSIG truncation can only be to an
permitted that the MAC size be zero, this case MUST NOT integral number of octets. On receipt of a DNS message with
be generated and, if received, MUST cause the DNS message to truncation thus indicated, the locally calculated MAC is
be dropped and RCODE 1 (FORMERR) to be returned. similarly truncated, and only the truncated values are compared
</t> for authentication. The request MAC used when calculating the
<t>Otherwise: TSIG MAC for a reply is the truncated request MAC.</dd>
<vspace/><vspace/> </dl>
This is sent when the signer has truncated the keyed hash
output to an allowable length, as described in
<xref target="RFC2104"/>, taking initial octets and
discarding trailing octets. TSIG truncation can only be
to an integral number of octets. On receipt of a DNS message
with truncation thus indicated, the locally calculated
MAC is similarly truncated and only the truncated values
are compared for authentication. The request MAC used
when calculating the TSIG MAC for a reply is the
truncated request MAC.
</t>
</list></t>
</section> </section>
</section> </section>
<section anchor="time_check" numbered="true" toc="default">
<section title="Time Check and Error Handling" anchor="time_check"> <name>Time Check and Error Handling</name>
<t>If the server time is outside the time interval specified <t>If the server time is outside the time interval specified
by the request (which is: Time Signed, plus/minus Fudge), by the request (which is the Time Signed value plus/minus
the server MUST generate an error response with RCODE 9 the Fudge value),
(NOTAUTH) and TSIG ERROR 18 (BADTIME). The server SHOULD the server <bcp14>MUST</bcp14> generate an error response with RCODE 9
(NOTAUTH) and TSIG ERROR 18 (BADTIME). The server <bcp14>SHOULD</bcp1
4>
also cache the most recent Time Signed value in a message also cache the most recent Time Signed value in a message
generated by a key, and SHOULD return BADTIME if a message generated by a key and <bcp14>SHOULD</bcp14> return BADTIME if a messa ge
received later has an earlier Time Signed value. A received later has an earlier Time Signed value. A
response indicating a BADTIME error MUST be signed by the response indicating a BADTIME error <bcp14>MUST</bcp14> be signed by t
same key as the request. It MUST include the client's he
same key as the request. It <bcp14>MUST</bcp14> include the client's
current time in the Time Signed field, the server's current current time in the Time Signed field, the server's current
time (an unsigned 48-bit integer) in the Other Data field, and 6 in th e time (an unsigned 48-bit integer) in the Other Data field, and 6 in th e
Other Len field. This is done so that the client Other Len field. This is done so that the client
can verify a message with a BADTIME error without the can verify a message with a BADTIME error without the
verification failing due to another BADTIME error. In verification failing due to another BADTIME error. In
addition, the Fudge field MUST be set to the fudge value addition, the Fudge field <bcp14>MUST</bcp14> be set to the fudge valu e
received from the client. The data signed is specified in received from the client. The data signed is specified in
<xref target="on_error"/>. The server SHOULD log the error.</t> <xref target="on_error" format="default"/>. The server
<bcp14>SHOULD</bcp14> log the error.</t>
<t>Caching the most recent Time Signed value and rejecting <t>Caching the most recent Time Signed value and rejecting
requests with an earlier one could lead to valid messages requests with an earlier one could lead to valid messages
being rejected if transit through the network led to UDP being rejected if transit through the network led to UDP
packets arriving in a different order to the one in which packets arriving in a different order to the one in which
they were sent. Implementations should be aware of they were sent. Implementations should be aware of
this possibility and be prepared to deal with it, e.g. by this possibility and be prepared to deal with it, e.g., by
retransmitting the rejected request with a new TSIG once retransmitting the rejected request with a new TSIG once
outstanding requests have completed or the time given by their outstanding requests have completed or the time given by their
Time Signed plus fudge value has passed. If implementations Time Signed value plus the Fudge value has passed. If implementations
do retry requests in these cases, a limit SHOULD be placed do retry requests in these cases, a limit <bcp14>SHOULD</bcp14> be pla
ced
on the maximum number of retries.</t> on the maximum number of retries.</t>
</section> </section>
<section anchor="trunc_check" numbered="true" toc="default">
<section title="Truncation Check and Error Handling" <name>Truncation Check and Error Handling</name>
anchor="trunc_check">
<t>If a TSIG is received with truncation that is permitted <t>If a TSIG is received with truncation that is permitted
under <xref target="trunc"/> above but the MAC is too short per <xref target="trunc" format="default"/> but the MAC is too short
for the local policy in force, an RCODE 9 (NOTAUTH) and TSIG for the local policy in force, an RCODE 9 (NOTAUTH) and TSIG
ERROR 22 (BADTRUNC) MUST be returned. The server SHOULD ERROR 22 (BADTRUNC) <bcp14>MUST</bcp14> be returned. The server <bcp14 >SHOULD</bcp14>
log the error.</t> log the error.</t>
</section> </section>
</section> </section>
<section title="Generation of TSIG on Answers" anchor="answers"> <section anchor="answers" numbered="true" toc="default">
<name>Generation of TSIG on Answers</name>
<t>When a server has generated a response to a signed request, <t>When a server has generated a response to a signed request,
it signs the response using the same algorithm and key. The it signs the response using the same algorithm and key. The
server MUST NOT generate a signed response to a request if server <bcp14>MUST NOT</bcp14> generate a signed response to a request i
either the KEY is invalid (e.g. key name or algorithm name are unknown), f
or the MAC fails validation: see <xref target="on_error"/> for either the key is invalid (e.g., key name or algorithm name are unknown)
or the MAC fails validation; see <xref target="on_error" format="default
"/> for
details of responding in these cases.</t> details of responding in these cases.</t>
<t>It also <bcp14>MUST NOT</bcp14> generate a signed
<t>It also MUST NOT not generate a signed
response to an unsigned request, except in the case of a response to an unsigned request, except in the case of a
response to a client's unsigned TKEY request if the secret key response to a client's unsigned TKEY request if the secret key
is established on the server side after the server processed the is established on the server side after the server processed the
client's request. Signing responses to unsigned TKEY requests client's request. Signing responses to unsigned TKEY requests
MUST be explicitly specified in the description of an individual <bcp14>MUST</bcp14> be explicitly specified in the description of an ind
secret key establishment algorithm <xref target="RFC3645"/>.</t> ividual
secret key establishment algorithm <xref target="RFC3645" format="defaul
t"/>.</t>
<t>The digest components used to generate a TSIG on a response are:</t> <t>The digest components used to generate a TSIG on a response are:</t>
<ul empty="true" spacing="compact">
<t><list style="empty"> <li>Request MAC</li>
<t>Request MAC<vspace/> <li>DNS Message (response)</li>
DNS Message (response)<vspace/> <li>TSIG Variables (response)</li>
TSIG Variables (response)</t> </ul>
</list></t>
<t>(This calculation is different for the second and subsequent message <t>(This calculation is different for the second and subsequent message
in a multi-message answer, see below.)</t> in a multi-message answer; see below.)</t>
<t>If addition of the TSIG record will cause the message to be truncated , <t>If addition of the TSIG record will cause the message to be truncated ,
the server MUST alter the response so that a TSIG can be included. the server <bcp14>MUST</bcp14> alter the response so that a TSIG can be
This response consists of only the question and a TSIG included.
record, and has the TC bit set and an RCODE of 0 (NOERROR). The This response contains only the question and a TSIG
client SHOULD at this point retry the request using TCP record, has the TC bit set, and has an RCODE of 0 (NOERROR).
(as per <xref target="RFC1035"/> 4.2.2).</t> At this point, the
client <bcp14>SHOULD</bcp14> retry the request using TCP
<section title="TSIG on TCP Connections" (as per <xref target="RFC1035" sectionFormat="of" section="4.2.2"/>).</t
anchor="tcp"> >
<t>A DNS TCP session such as a zone transfer can include multiple <section anchor="tcp" numbered="true" toc="default">
<name>TSIG on TCP Connections</name>
<t>A DNS TCP session, such as a zone transfer, can include multiple
DNS messages. Using TSIG on such a connection can protect the DNS messages. Using TSIG on such a connection can protect the
connection from attack and provide data integrity. The TSIG connection from an attack and provide data integrity. The TSIG
MUST be included on all DNS messages in the response. For backward <bcp14>MUST</bcp14> be included on all DNS messages in the response. Fo
compatibility, a client which receives DNS messages and verifies r backward
TSIG MUST accept up to 99 intermediary messages without a TSIG and compatibility, a client that receives DNS messages and verifies
MUST verify that both the first and last message contain a TSIG.</t> TSIG <bcp14>MUST</bcp14> accept up to 99 intermediary messages without a
TSIG and
<t>The first message is processed as a standard answer <bcp14>MUST</bcp14> verify that both the first and last message contain
(see <xref target="answers"/>) but a TSIG.</t>
subsequent messages have the following digest components:</t> <t>The first message is processed as a standard answer (see <xref
target="answers" format="default"/>), but subsequent messages have
<t><list style="empty"> the following digest components:</t>
<t>Prior MAC (running)<vspace/> <ul empty="true" spacing="compact">
DNS Messages (any unsigned messages since the last TSIG)<vspace/> <li>Prior MAC (running)</li>
TSIG Timers (current message)</t> <li>DNS Messages (any unsigned messages since the last TSIG)</li>
</list></t> <li>TSIG Timers (current message)</li>
</ul>
<t>The "Prior MAC" is the MAC from the TSIG attached to the last <t>The "Prior MAC" is the MAC from the TSIG attached to the last
message containing a TSIG. "DNS Messages" comprises the message containing a TSIG. "DNS Messages" comprises the
concatenation (in message order) of all messages after the last concatenation (in message order) of all messages after the last
message that included a TSIG and includes the current message. message that included a TSIG and includes the current message.
"TSIG timers" comprises the "Time Signed" and "Fudge" fields (in "TSIG Timers" comprises the Time Signed and Fudge fields (in
that order) pertaining to the message for which the TSIG is being create that order) pertaining to the message for which the TSIG was created;
d:
this means that the successive TSIG records in the stream will have this means that the successive TSIG records in the stream will have
non-decreasing "Time Signed" fields. Note that only the non-decreasing Time Signed values. Note that only the
timers are included in the second and subsequent messages, not all timers are included in the second and subsequent messages, not all
the TSIG variables.</t> the TSIG variables.</t>
<t>This allows the client to rapidly detect when the session has
<t>This allows the client to rapidly detect when the session has been altered; at which point, it can close the connection and retry.
been altered; at which point it can close the connection and retry. If a client TSIG verification fails, the client <bcp14>MUST</bcp14> clos
If a client TSIG verification fails, the client MUST close the e the
connection. If the client does not receive TSIG records frequently connection. If the client does not receive TSIG records frequently
enough (as specified above) it SHOULD assume the connection has enough (as specified above), it <bcp14>SHOULD</bcp14> assume the connect
been hijacked and it SHOULD close the connection. The client SHOULD ion has
been hijacked, and it <bcp14>SHOULD</bcp14> close the connection. The
client <bcp14>SHOULD</bcp14>
treat this the same way as they would any other interrupted transfer treat this the same way as they would any other interrupted transfer
(although the exact behavior is not specified).</t> (although the exact behavior is not specified).</t>
</section> </section>
<section anchor="on_error" numbered="true" toc="default">
<section title="Generation of TSIG on Error Returns" anchor="on_error"> <name>Generation of TSIG on Error Returns</name>
<t>When a server detects an error relating to the key or MAC in the <t>When a server detects an error relating to the key or MAC in the
incoming request, the incoming request, the
server SHOULD send back an unsigned error message (MAC size == 0 server <bcp14>SHOULD</bcp14> send back an unsigned error message (MAC Si
and empty MAC). It MUST NOT send back a signed error message.</t> ze == 0
and empty MAC). It <bcp14>MUST NOT</bcp14> send back a signed error mess
<t>If an error is detected relating to the TSIG age.</t>
<t>If an error is detected relating to the TSIG
validity period or the MAC is too short for the local policy, validity period or the MAC is too short for the local policy,
the server SHOULD send back a signed error message. the server <bcp14>SHOULD</bcp14> send back a signed error message.
The digest components are:</t> The digest components are:</t>
<ul empty="true" spacing="compact">
<t><list style="empty"> <li>Request MAC (if the request MAC validated)</li>
<t>Request MAC (if the request MAC validated)<vspace/> <li>DNS Message (response)</li>
DNS Message (response)<vspace/> <li>TSIG Variables (response)</li>
TSIG Variables (response)</t> </ul>
</list></t> <t>The reason that the request MAC is not included in this MAC in
<t>The reason that the request MAC is not included in this MAC in
some cases is to make it possible for the client to verify the some cases is to make it possible for the client to verify the
error. If the error is not a TSIG error the response MUST be error. If the error is not a TSIG error, the response <bcp14>MUST</bcp1
generated as specified in <xref target="answers"/>.</t> 4> be
</section> generated as specified in <xref target="answers" format="default"/>.</t>
</section>
</section> </section>
<section anchor="client_proc_answer" numbered="true" toc="default">
<section title="Client Processing of Answer" anchor="client_proc_answer"> <name>Client Processing of Answer</name>
<t>When a client receives a response from a server and <t>When a client receives a response from a server and
expects to see a TSIG, it first checks if the TSIG RR is expects to see a TSIG, it first checks if the TSIG RR is
present in the response. If not, the response is treated as present in the response. If not, the response is treated as
having a format error and is discarded.</t> having a format error and is discarded.</t>
<t>If the TSIG RR is present, the client performs the same checks as <t>If the TSIG RR is present, the client performs the same checks as
described in <xref target="request_processing"/>. If the TSIG RR is described in <xref target="request_processing" format="default"/>. If t
unsigned as specified in <xref target="on_error"/> or does not he TSIG RR is
validate, the message MUST be discarded unless the RCODE is 9 (NOAUTH). unsigned as specified in <xref target="on_error" format="default"/> or d
In this case, the client SHOULD attempt to verify the response as if it oes not
validate, the message <bcp14>MUST</bcp14> be discarded unless the RCODE
is 9 (NOAUTH).
In this case, the client <bcp14>SHOULD</bcp14> attempt to verify the res
ponse as if it
were a TSIG error, as described in the following subsections.</t> were a TSIG error, as described in the following subsections.</t>
<t>Regardless of the RCODE, a message containing a TSIG RR that is <t>Regardless of the RCODE, a message containing a TSIG RR that is
unsigned as specified in <xref target="on_error"/> or which fails unsigned as specified in <xref target="on_error" format="default"/> or t
verification SHOULD NOT be considered an acceptable response as it hat fails
verification <bcp14>SHOULD NOT</bcp14> be considered an acceptable respo
nse, as it
may have been spoofed or manipulated. Instead, the may have been spoofed or manipulated. Instead, the
client SHOULD log an error and continue to wait for a signed response client <bcp14>SHOULD</bcp14> log an error and continue to wait for a sig ned response
until the request times out.</t> until the request times out.</t>
<section numbered="true" toc="default">
<section title="Key Error Handling"> <name>Key Error Handling</name>
<t>If an RCODE on a response is 9 (NOTAUTH), but the response <t>If an RCODE on a response is 9 (NOTAUTH), but the response
TSIG validates and the TSIG key is recognized by the client TSIG validates and the TSIG key is recognized by the client
but different from that used on the request, then this is a but is different from that used on the request, then this is a
Key Error. The client MAY retry the request using the key key-related error. The client <bcp14>MAY</bcp14> retry the request us
ing the key
specified by the server. However, this should never occur, as specified by the server. However, this should never occur, as
a server MUST NOT sign a response with a different key to that a server <bcp14>MUST NOT</bcp14> sign a response with a different key to that
used to sign the request.</t> used to sign the request.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="MAC Error Handling"> <name>MAC Error Handling</name>
<t>If the response RCODE is 9 (NOTAUTH) and TSIG ERROR <t>If the response RCODE is 9 (NOTAUTH) and TSIG ERROR
is 16 (BADSIG), this is a MAC error, and client MAY retry is 16 (BADSIG), this is a MAC-related error, and clients <bcp14>MAY</b
the request with a new request ID but it would be better cp14> retry
the request with a new request ID, but it would be better
to try a different shared key if one is available. Clients to try a different shared key if one is available. Clients
SHOULD keep track of how many MAC errors are associated <bcp14>SHOULD</bcp14> keep track of how many MAC errors are associated
with each key. Clients SHOULD log this event.</t> with each key. Clients <bcp14>SHOULD</bcp14> log this event.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Time Error Handling"> <name>Time Error Handling</name>
<t>If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR <t>If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR
is 18 (BADTIME), or the current time does not fall in the is 18 (BADTIME) or the current time does not fall in the
range specified in the TSIG record, then this is a Time range specified in the TSIG record, then this is a time-related
error. This is an indication that the client and server error. This is an indication that the client and server
clocks are not synchronized. In this case the client clocks are not synchronized. In this case, the client
SHOULD log the event. DNS resolvers MUST NOT adjust any <bcp14>SHOULD</bcp14> log the event. DNS resolvers <bcp14>MUST
clocks in the client based on BADTIME errors, but the NOT</bcp14> adjust any clocks in the client based on BADTIME errors,
server's time in the Other Data field SHOULD be logged.</t> but the server's time in the Other Data field <bcp14>SHOULD</bcp14>
be logged.</t>
</section> </section>
<section anchor="trunc_err" numbered="true" toc="default">
<section title="Truncation Error Handling" anchor="trunc_err"> <name>Truncation Error Handling</name>
<t>If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR <t>If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR
is 22 (BADTRUNC) then this is a Truncation error. The client is 22 (BADTRUNC), then this is a truncation-related error. The client
MAY retry with a lesser truncation up to the full HMAC output <bcp14>MAY</bcp14> retry with a lesser truncation up to the full
(no truncation), using the truncation used in the response HMAC output (no truncation), using the truncation used in the
as a hint for what the server policy allowed response as a hint for what the server policy allowed (<xref
(<xref target="trunc_pol"/>). Clients SHOULD log this event.</t> target="trunc_pol" format="default"/>). Clients
<bcp14>SHOULD</bcp14> log this event.</t>
</section> </section>
</section> </section>
<section anchor="forwarding" numbered="true" toc="default">
<section title="Special Considerations for Forwarding Servers" <name>Special Considerations for Forwarding Servers</name>
anchor="forwarding">
<t>A server acting as a forwarding server of a DNS message <t>A server acting as a forwarding server of a DNS message
SHOULD check for the existence of a TSIG record. If the name on <bcp14>SHOULD</bcp14> check for the existence of a TSIG record. If the name on
the TSIG is not of a secret that the server shares with the the TSIG is not of a secret that the server shares with the
originator the server MUST forward the message unchanged originator, the server <bcp14>MUST</bcp14> forward the message unchanged
including the TSIG. If the name of the TSIG is of a key this including the TSIG. If the name of the TSIG is of a key this
server shares with the originator, it MUST process the TSIG. If server shares with the originator, it <bcp14>MUST</bcp14> process the TS
the TSIG passes all checks, the forwarding server MUST, if IG. If
possible, include a TSIG of its own, to the destination or the the TSIG passes all checks, the forwarding server <bcp14>MUST</bcp14>, i
f
possible, include a TSIG of its own to the destination or the
next forwarder. If no transaction security is available to the next forwarder. If no transaction security is available to the
destination and the message is a query then, if the destination and the message is a query, and if the
corresponding response has the AD flag (see <xref corresponding response has the AD flag (see <xref target="RFC4035"
target="RFC4035"/>) set, the forwarder MUST clear the AD flag format="default"/>) set, the forwarder <bcp14>MUST</bcp14> clear the
AD flag
before adding the TSIG to the response and returning the result before adding the TSIG to the response and returning the result
to the system from which it received the query.</t> to the system from which it received the query.</t>
</section> </section>
</section> </section>
<section anchor="algorithm_id" numbered="true" toc="default">
<section title="Algorithms and Identifiers" anchor="algorithm_id"> <name>Algorithms and Identifiers</name>
<t>The only message digest algorithm specified in the first <t>The only message digest algorithm specified in the first
version of these specifications <xref target="RFC2845"/> was version of these specifications <xref target="RFC2845" format="default"/>
"HMAC-MD5" (see <xref target="RFC1321"/>, <xref target="RFC2104"/>). was
Although a review of its security some years ago <xref target="RFC6151"/> "HMAC-MD5" (see <xref target="RFC1321" format="default"/> and <xref
concluded target="RFC2104" format="default"/>).
Although a review of its security some years ago <xref target="RFC6151"
format="default"/> concluded
that "it may not be urgent to remove HMAC-MD5 from the existing that "it may not be urgent to remove HMAC-MD5 from the existing
protocols", with the availability of more secure alternatives the protocols", with the availability of more secure alternatives, the
opportunity has been taken to make the implementation of this opportunity has been taken to make the implementation of this
algorithm optional. </t> algorithm optional. </t>
<t><xref target="RFC4635" format="default"/> added mandatory support in
<t><xref target="RFC4635"/> added mandatory support in TSIG for TSIG for SHA-1 <xref target="FIPS180-4" format="default"/> <xref
SHA-1 <xref target="FIPS180-4"/>, <xref target="RFC3174"/>. target="RFC3174" format="default"/>. SHA-1 collisions have been
SHA-1 collisions have been demonstrated <xref demonstrated <xref target="SHA1SHAMBLES" format="default"/>, so the MD5
target="SHA1SHAMBLES"/> so the MD5 security considerations security considerations described in <xref target="RFC6151"
described in section 2 of <xref target="RFC6151"/> apply to SHA-1 in a sim sectionFormat="of" section="2"/> apply to SHA-1 in a similar manner.
ilar Although support for hmac-sha1 in TSIG is still mandatory for
manner. Although support for hmac-sha1 in TSIG is still mandatory compatibility reasons, existing uses <bcp14>SHOULD</bcp14> be replaced
for compatibility reasons, existing uses SHOULD be replaced with with hmac-sha256 or other SHA-2 digest algorithms (<xref
hmac-sha256 or other SHA-2 digest algorithms <xref target="FIPS180-4" format="default"/>, <xref target="RFC3874"
target="FIPS180-4"/>, <xref target="RFC3874"/>, <xref format="default"/>, <xref target="RFC6234" format="default"/>).</t>
target="RFC6234"/>.</t>
<t>Use of TSIG between two DNS agents is by mutual <t>Use of TSIG between two DNS agents is by mutual
agreement. That agreement can include the support of additional agreement. That agreement can include the support of additional
algorithms and criteria as to which algorithms and truncations are algorithms and criteria as to which algorithms and truncations are
acceptable, subject to the restriction and guidelines in acceptable, subject to the restriction and guidelines in
<xref target="trunc"/> above. <xref target="trunc" format="default"/>.
Key agreement can be by the TKEY mechanism <xref target="RFC2930"/> Key agreement can be by the TKEY mechanism <xref target="RFC2930" format="
default"/>
or some other mutually agreeable method.</t> or some other mutually agreeable method.</t>
<t>Implementations that support TSIG <bcp14>MUST</bcp14>
<t>Implementations that support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and <bcp14>MAY</bcp14> implement
also implement HMAC SHA1 and HMAC SHA256 and MAY implement
gss-tsig and the other algorithms listed below. SHA-1 truncated gss-tsig and the other algorithms listed below. SHA-1 truncated
to 96 bits (12 octets) SHOULD be implemented.</t> to 96 bits (12 octets) <bcp14>SHOULD</bcp14> be implemented.</t>
<!--
<texttable style="headers" anchor="allowed_algs">
<ttcol>Requirement</ttcol>
<ttcol>Name</ttcol>
<c>Optional</c> <c>HMAC-MD5.SIG-ALG.REG.INT</c>
<c>Optional</c> <c>gss-tsig</c>
<c>Mandatory</c> <c>hmac-sha1</c>
<c>Optional</c> <c>hmac-sha224</c>
<c>Optional</c> <c>hmac-sha256-128</c>
<c>Mandatory</c> <c>hmac-sha256</c>
<c>Optional</c> <c>hmac-sha384-192</c>
<c>Optional</c> <c>hmac-sha384</c>
<c>Optional</c> <c>hmac-sha512-256</c>
<c>Optional</c> <c>hmac-sha512</c>
</texttable>
<texttable style="headers" anchor="allowed-algorithms">
<ttcol>Name</ttcol>
<ttcol>Implementation</ttcol>
<ttcol>Use</ttcol>
<c>HMAC-MD5.SIG-ALG.REG.INT</c> <c>MAY</c> <c>MUST NOT</c>
<c>gss-tsig</c> <c>MAY</c> <c>MAY</c>
<c>hmac-sha1</c> <c>MUST</c> <c>NOT RECOMMENDED</c>
<c>hmac-sha224</c> <c>MAY</c> <c>MAY</c>
<c>hmac-sha256</c> <c>MUST</c> <c>RECOMMENDED</c>
<c>hmac-sha256-128</c> <c>MAY</c> <c>MAY</c>
<c>hmac-sha384</c> <c>MAY</c> <c>MAY</c>
<c>hmac-sha384-192</c> <c>MAY</c> <c>MAY</c>
<c>hmac-sha512</c> <c>MAY</c> <c>MAY</c>
<c>hmac-sha512-256</c> <c>MAY</c> <c>MAY</c>
</texttable>
<table anchor="allowed-algorithms" align="center">
<name>Algorithms for Implementations Supporting TSIG</name>
<thead>
<tr>
<th align="left">Algorithm Name</th>
<th align="left">Implementation</th>
<th align="left">Use</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">HMAC-MD5.SIG-ALG.REG.INT</td>
<td align="left"><bcp14>MAY</bcp14></td>
<td align="left"><bcp14>MUST NOT</bcp14></td>
</tr>
<tr>
<td align="left">gss-tsig</td>
<td align="left"><bcp14>MAY</bcp14></td>
<td align="left"><bcp14>MAY</bcp14></td>
</tr>
<tr>
<td align="left">hmac-sha1</td>
<td align="left"><bcp14>MUST</bcp14></td>
<td align="left"><bcp14>NOT RECOMMENDED</bcp14></td>
</tr>
<tr>
<td align="left">hmac-sha224</td>
<td align="left"><bcp14>MAY</bcp14></td>
<td align="left"><bcp14>MAY</bcp14></td>
</tr>
<tr>
<td align="left">hmac-sha256</td>
<td align="left"><bcp14>MUST</bcp14></td>
<td align="left"><bcp14>RECOMMENDED</bcp14></td>
</tr>
<tr>
<td align="left">hmac-sha256-128</td>
<td align="left"><bcp14>MAY</bcp14></td>
<td align="left"><bcp14>MAY</bcp14></td>
</tr>
<tr>
<td align="left">hmac-sha384</td>
<td align="left"><bcp14>MAY</bcp14></td>
<td align="left"><bcp14>MAY</bcp14></td>
</tr>
<tr>
<td align="left">hmac-sha384-192</td>
<td align="left"><bcp14>MAY</bcp14></td>
<td align="left"><bcp14>MAY</bcp14></td>
</tr>
<tr>
<td align="left">hmac-sha512</td>
<td align="left"><bcp14>MAY</bcp14></td>
<td align="left"><bcp14>MAY</bcp14></td>
</tr>
<tr>
<td align="left">hmac-sha512-256</td>
<td align="left"><bcp14>MAY</bcp14></td>
<td align="left"><bcp14>MAY</bcp14></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="trunc_pol" numbered="true" toc="default">
<section title="TSIG Truncation Policy" anchor="trunc_pol"> <name>TSIG Truncation Policy</name>
<t>As noted above, two DNS agents (e.g., resolver and server) must <t>As noted above, two DNS agents (e.g., resolver and server) must
mutually agree to use TSIG. mutually agree to use TSIG.
Implicit in such an "agreement" are criteria as to acceptable keys and Implicit in such an "agreement" are criteria as to acceptable keys,
algorithms and, with the extensions in this document, truncations. algorithms, and (with the extensions in this document) truncations.
Local policies MAY require the rejection of TSIGs, even though Local policies <bcp14>MAY</bcp14> require the rejection of TSIGs, even tho
ugh
they use an algorithm for which implementation is mandatory.</t> they use an algorithm for which implementation is mandatory.</t>
<t>When a local policy permits acceptance of a TSIG with a particular <t>When a local policy permits acceptance of a TSIG with a particular
algorithm and a particular non-zero amount of truncation, it SHOULD algorithm and a particular non-zero amount of truncation, it <bcp14>SHOULD </bcp14>
also permit the use of that algorithm with lesser truncation (a also permit the use of that algorithm with lesser truncation (a
longer MAC) up to the full keyed hash output.</t> longer MAC) up to the full keyed hash output.</t>
<t>Regardless of a lower acceptable truncated MAC length specified by <t>Regardless of a lower acceptable truncated MAC length specified by
local policy, a reply SHOULD be sent with a MAC at least as long as local policy, a reply <bcp14>SHOULD</bcp14> be sent with a MAC at least as
that in the corresponding request. Note if the request specified a MAC long as
length longer than the keyed hash output it will be rejected by that in the corresponding request. Note, if the request specified a MAC
processing rules <xref target="trunc"/> case 1.</t> length longer than the keyed hash output, it will be rejected by
processing rules (<xref target="trunc" format="default"/>, case 1).</t>
<t>Implementations permitting multiple acceptable algorithms and/or <t>Implementations permitting multiple acceptable algorithms and/or
truncations SHOULD permit this list to be ordered by presumed truncations <bcp14>SHOULD</bcp14> permit this list to be ordered by presum
strength and SHOULD allow different truncations for the same ed
strength and <bcp14>SHOULD</bcp14> allow different truncations for the sam
e
algorithm to be treated as separate entities in this list. When so algorithm to be treated as separate entities in this list. When so
implemented, policies SHOULD accept a presumed stronger algorithm and implemented, policies <bcp14>SHOULD</bcp14> accept a presumed stronger alg orithm and
truncation than the minimum strength required by the policy.</t> truncation than the minimum strength required by the policy.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Shared Secrets"> <name>Shared Secrets</name>
<t>Secret keys are very sensitive information and all available <t>Secret keys are very sensitive information and all available
steps should be taken to protect them on every host on which they steps should be taken to protect them on every host on which they
are stored. Generally such hosts need to be physically protected. are stored. Generally, such hosts need to be physically protected.
If they are multi-user machines, great care should be taken that If they are multi-user machines, great care should be taken so that
unprivileged users have no access to keying material. Resolvers unprivileged users have no access to keying material. Resolvers
often run unprivileged, which means all users of a host would be often run unprivileged, which means all users of a host would be
able to see whatever configuration data is used by the resolver.</t> able to see whatever configuration data are used by the resolver.</t>
<t>A name server usually runs privileged, which means its <t>A name server usually runs privileged, which means its
configuration data need not be visible to all users of the host. configuration data need not be visible to all users of the host.
For this reason, a host that implements transaction-based For this reason, a host that implements transaction-based
authentication should probably be configured with a "stub authentication should probably be configured with a "stub
resolver" and a local caching and forwarding name server. This resolver" and a local caching and forwarding name server. This
presents a special problem for <xref target="RFC2136"/> which presents a special problem for <xref target="RFC2136" format="default"/>, which
otherwise depends on clients to communicate only with a zone's otherwise depends on clients to communicate only with a zone's
authoritative name servers.</t> authoritative name servers.</t>
<t>Use of strong, random shared secrets is essential to the
<t>Use of strong random shared secrets is essential to the security of TSIG. See <xref target="RFC4086" format="default"/> for a dis
security of TSIG. See <xref target="RFC4086"/> for a discussion cussion
of this issue. The secret SHOULD be at least as long as the keyed hash of this issue. The secret <bcp14>SHOULD</bcp14> be at least as long as th
output <xref target="RFC2104"/>.</t> e keyed hash
output <xref target="RFC2104" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA maintains a registry of algorithm names to be used as <t>IANA maintains a registry of algorithm names to be used as
"Algorithm Names" as defined in <xref target="format"/>. Algorithm "Algorithm Names", as defined in <xref target="format"
format="default"/> <xref target="IANA-TSIG"/>. Algorithm
names are text strings encoded using the syntax of a domain name. There names are text strings encoded using the syntax of a domain name. There
is no structure to the names, and algorithm names are compared is no structure to the names, and algorithm names are compared
as if they were DNS names, i.e., comparison is case as if they were DNS names, i.e., comparison is case
insensitive. Previous specifications <xref target="RFC2845"/> and <xref insensitive. Previous specifications (<xref target="RFC2845"
target="RFC4635"/> defined values for the HMAC-MD5 and some HMAC-SHA format="default"/> and <xref target="RFC4635" format="default"/>)
defined values for the HMAC-MD5 and some HMAC-SHA
algorithms. IANA has also registered "gss-tsig" as an identifier for TSIG algorithms. IANA has also registered "gss-tsig" as an identifier for TSIG
authentication where the cryptographic operations are delegated to the authentication where the cryptographic operations are delegated to the
Generic Security Service (GSS) <xref target="RFC3645"/>. This document Generic Security Service (GSS) <xref target="RFC3645" format="default"/>.
adds to allowed algorithms, and the registry should be updated with the This document
names listed in <xref target="allowed-algorithms"/>.</t> adds to the allowed algorithms, and the registry has been updated with the
names listed in <xref target="allowed-algorithms" format="default"/>.</t>
<t>New algorithms are assigned using <t>New algorithms are assigned using
the IETF Review policy defined in <xref target="RFC8126"/>. the IETF Review policy defined in <xref target="RFC8126" format="default"/ >.
The algorithm name The algorithm name
HMAC-MD5.SIG-ALG.REG.INT looks like a fully-qualified domain HMAC-MD5.SIG-ALG.REG.INT looks like a fully qualified domain
name for historical reasons; name for historical reasons;
other algorithm names are simple, single-component names.</t> other algorithm names are simple, single-component names.</t>
<t>IANA maintains a registry of RCODES (error codes), including <t>IANA maintains a registry of RCODEs (error codes) (see <xref
"TSIG Error values" to be used for "Error" values as defined in target="IANA-RCODEs"/>, including
<xref target="format"/>. New error codes are assigned and "TSIG Error values" to be used for "Error" values, as defined in
specified as in <xref target="RFC6895"/>.</t> <xref target="format" format="default"/>. This document defines the RCODE
s as
described in <xref target="numbers"/>. New error codes are assigned and
specified as in <xref target="RFC6895" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>The approach specified here is computationally much less <t>The approach specified here is computationally much less
expensive than the signatures specified in DNSSEC. As long as expensive than the signatures specified in DNSSEC. As long as
the shared secret key is not compromised, strong authentication the shared secret key is not compromised, strong authentication
is provided between two DNS systems, e.g., for the last hop from is provided between two DNS systems, e.g., for the last hop from
a local name server to the user resolver, or between primary and a local name server to the user resolver or between primary and
secondary nameservers.</t> secondary name servers.</t>
<t>Recommendations for choosing and maintaining secret keys can be found <t>Recommendations for choosing and maintaining secret keys can be found
in <xref target="RFC2104"/>. If the client host has been compromised, in <xref target="RFC2104" format="default"/>. If the client host has been compromised,
the server should suspend the use of all secrets known to that client. the server should suspend the use of all secrets known to that client.
If possible, secrets should be stored in encrypted form. Secrets should If possible, secrets should be stored in an encrypted form. Secrets shoul d
never be transmitted in the clear over any network. This document does never be transmitted in the clear over any network. This document does
not address the issue on how to distribute secrets except that it not address the issue on how to distribute secrets except that it
mentions the possibilities of manual configuration and the use of TKEY mentions the possibilities of manual configuration and the use of TKEY
<xref target="RFC2930"/>. Secrets SHOULD NOT be shared by more than two <xref target="RFC2930" format="default"/>. Secrets <bcp14>SHOULD
NOT</bcp14> be shared by more than two
entities; any such additional sharing would allow any party knowing the entities; any such additional sharing would allow any party knowing the
key to impersonate any other such party to members of the group.</t> key to impersonate any other such party to members of the group.</t>
<t>This mechanism does not authenticate source data, only its <t>This mechanism does not authenticate source data, only its
transmission between two parties who share some secret. The transmission between two parties who share some secret. The
original source data can come from a compromised zone master or original source data can come from a compromised zone master or
can be corrupted during transit from an authentic zone master to can be corrupted during transit from an authentic zone master to
some "caching forwarder." However, if the server is faithfully some "caching forwarder". However, if the server is faithfully
performing the full DNSSEC security checks, then performing the full DNSSEC security checks, then
only security checked data will be available to the client.</t> only security-checked data will be available to the client.</t>
<t>A Fudge value that is too large may leave the server open
<t>A fudge value that is too large may leave the server open to replay attacks. A Fudge value that is too small may cause
to replay attacks. A fudge value that is too small may cause
failures if machines are not time synchronized or there are unexpected failures if machines are not time synchronized or there are unexpected
network delays. The RECOMMENDED value in most situations is 300 network delays. The <bcp14>RECOMMENDED</bcp14> value in most situations i s 300
seconds.</t> seconds.</t>
<t>To prevent cross-algorithm attacks, there <bcp14>SHOULD</bcp14> only be
<t>To prevent cross-algorithm attacks, there SHOULD only be one one
algorithm associated with any given key name.</t> algorithm associated with any given key name.</t>
<t>In several cases where errors are detected, an unsigned error <t>In several cases where errors are detected, an unsigned error
message must be returned. This can allow for an attacker to spoof message must be returned. This can allow for an attacker to spoof
or manipulate these responses. <xref target="client_proc_answer"/> or manipulate these responses. <xref target="client_proc_answer" format=" default"/>
recommends logging these as errors and continuing to wait for a recommends logging these as errors and continuing to wait for a
signed response until the request times out.</t> signed response until the request times out.</t>
<t>Although the strength of an algorithm determines its security, <t>Although the strength of an algorithm determines its security,
there have been some arguments that mild truncation can there have been some arguments that mild truncation can
strengthen a MAC by reducing the information available to an strengthen a MAC by reducing the information available to an
attacker. However, excessive truncation clearly weakens authentication by attacker. However, excessive truncation clearly weakens authentication by
reducing the number of bits an attacker has to try to break the reducing the number of bits an attacker has to try to break the
authentication by brute force <xref target="RFC2104"/>.</t> authentication by brute force <xref target="RFC2104" format="default"/>.</
t>
<t>Significant progress has been made recently in cryptanalysis of hash <t>Significant progress has been made recently in cryptanalysis of hash
functions of the types used here. While the results so far should not functions of the types used here. While the results so far should not
affect HMAC, the stronger SHA-256 algorithm is being made mandatory as a affect HMAC, the stronger SHA-256 algorithm is being made mandatory as a
precaution.</t> precaution.</t>
<t>See also the Security Considerations section of <xref <t>See also the Security Considerations section of <xref
target="RFC2104"/> from which the limits on truncation in this target="RFC2104" format="default"/> from which the limits on truncation
RFC were taken.</t> in this RFC were taken.</t>
<section anchor="issuesfixed" numbered="true" toc="default">
<section title="Issue Fixed in this Document" anchor="issuesfixed"> <name>Issue Fixed in This Document</name>
<t>When signing a DNS reply message using TSIG, the MAC <t>When signing a DNS reply message using TSIG, the MAC
computation uses the request message's MAC as an input to computation uses the request message's MAC as an input to
cryptographically relate the reply to the request. The cryptographically relate the reply to the request. The
original TSIG specification <xref target="RFC2845"/> required original TSIG specification <xref target="RFC2845" format="default"/> r
that the TIME values be checked before the request's MAC. If equired
the TIME was invalid, some implementations failed to carry out that the time values be checked before the request's MAC. If
the time was invalid, some implementations failed to carry out
further checks and could use an invalid request MAC in the further checks and could use an invalid request MAC in the
signed reply.</t> signed reply.</t>
<t>This document makes it mandatory that the request MAC
<t>This document makes it a mandatory that the request MAC is considered to be invalid until it has been validated;
is considered to be invalid until it has been validated:
until then, any answer must be unsigned. For this reason, the until then, any answer must be unsigned. For this reason, the
request MAC is now checked before the TIME value.</t> request MAC is now checked before the time values.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Why Not DNSSEC?</name>
<section title="Why not DNSSEC?"> <t>DNS has been extended by DNSSEC
<t>These extracts from the original document <xref target="RFC2845"/> (<xref target="RFC4033" format="default"/>, <xref target="RFC4034"
(updated to reference current standards) analyze DNSSEC in order to format="default"/>, and
justify the introduction of TSIG.</t> <xref target="RFC4035" format="default"/>) to provide for data origin
<t><list style="empty" hangIndent="10">
<t>DNS has recently been extended by DNSSEC
(<xref target="RFC4033"/>, <xref target="RFC4034"/> and
<xref target="RFC4035"/>) to provide for data origin
authentication, and public key distribution, all based on authentication, and public key distribution, all based on
public key cryptography and public key based digital public key cryptography and public key based digital
signatures. To be practical, this form of security signatures. To be practical, this form of security
generally requires extensive local caching of keys and generally requires extensive local caching of keys and
tracing of authentication through multiple keys and tracing of authentication through multiple keys and
signatures to a pre-trusted locally configured key.</t> signatures to a pre-trusted locally configured key.</t>
<t>One difficulty with the DNSSEC scheme is that common DNS
<t>One difficulty with the DNSSEC scheme is that common DNS
implementations include simple "stub" resolvers which do not implementations include simple "stub" resolvers which do not
have caches. Such resolvers typically rely on a caching DNS have caches. Such resolvers typically rely on a caching DNS
server on another host. It is impractical for these stub server on another host. It is impractical for these stub
resolvers to perform general DNSSEC authentication and they resolvers to perform general DNSSEC authentication and they
would naturally depend on their caching DNS server to would naturally depend on their caching DNS server to
perform such services for them. To do so securely requires perform such services for them. To do so securely requires
secure communication of queries and responses. DNSSEC secure communication of queries and responses. DNSSEC
provides public key transaction signatures to support this, provides public key transaction signatures to support this,
but such signatures are very expensive computationally to but such signatures are very expensive computationally to
generate. In general, these require the same complex public generate. In general, these require the same complex public
key logic that is impractical for stubs.</t> key logic that is impractical for stubs.</t>
</list></t>
<t>and</t> <t>A second area where use of straight DNSSEC public key based
mechanisms may be impractical is authenticating dynamic update <xref
target="RFC2136" format="default"/> requests. DNSSEC provides for
request signatures but with DNSSEC they, like transaction
signatures, require computationally expensive public key
cryptography and complex authentication logic. Secure Domain Name
System Dynamic Update (<xref target="RFC3007" format="default"/>)
describes how different keys are used in dynamically updated
zones.</t>
<t><list style="empty" hangIndent="10">
<t>A second area where use of straight DNSSEC public key
based mechanisms may be impractical is authenticating
dynamic update <xref target="RFC2136"/> requests. DNSSEC
provides for request signatures but with DNSSEC they, like
transaction signatures, require computationally expensive
public key cryptography and complex authentication logic.
Secure Domain Name System Dynamic Update
(<xref target="RFC3007"/>) describes how different keys are
used in dynamically updated zones.</t>
</list></t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<reference anchor="FIPS180-4" target=""> <references>
<front> <name>References</name>
<references>
<name>Normative References</name>
<reference anchor="FIPS180-4" target="">
<front>
<title>Secure Hash Standard (SHS)</title> <title>Secure Hash Standard (SHS)</title>
<seriesInfo name="FIPS" value="PUB 180-4"/>
<author> <author>
<organization>National Institute of Standards and <organization>National Institute of Standards and
Technology</organization> Technology</organization>
</author> </author>
<date month="August" year="2015"/> <date month="August" year="2015"/>
</front> </front>
<seriesInfo name="FIPS" value="PUB 180-4"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference> </reference>
<?rfc include="reference.RFC.1034.xml"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.1035.xml"?> ence.RFC.1034.xml"/>
<?rfc include="reference.RFC.2119.xml"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.2845.xml"?> ence.RFC.1035.xml"/>
<?rfc include="reference.RFC.3597.xml"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.4635.xml"?> ence.RFC.2119.xml"/>
<?rfc include="reference.RFC.8174.xml"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</references> ence.RFC.2845.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3597.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4635.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<references title="Informative References"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<!-- ence.RFC.7696.xml"/>
<reference anchor="FIPS202" target=""> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<front> ence.RFC.1321.xml"/>
<title>SHA-3 Standard</title> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2104.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2136.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2930.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3007.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3645.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3874.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4033.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4034.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4035.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4868.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6151.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6895.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8126.xml"/>
<reference anchor="CVE-2017-3142" target="https://cve.mitre.org/cgi-bin/
cvename.cgi?name=CVE-2017-3142">
<front>
<title>CVE-2017-3142: An error in TSIG authentication can permit una
uthorized zone transfers</title>
<author> <author>
<organization>National Institute of Standards and <organization>Common Vulnerabilities and Exposures</organization>
Technology</organization>
</author> </author>
<date month="August" year="2015"/> <date month="June" year="2017"/>
</front> </front>
<seriesInfo name="FIPS" value="PUB 202"/> </reference>
</reference> <reference anchor="CVE-2017-3143" target="https://cve.mitre.org/cgi-bin/
<reference anchor="BCP201" target="https://www.rfc-editor.org/info/bcp201" cvename.cgi?name=CVE-2017-3143">
> <front>
<front> <title>CVE-2017-3143: An error in TSIG authentication can permit una
<title>Guidelines for Cryptographic Algorithm Agility and Selecting Ma uthorized dynamic updates</title>
ndatory-to-Implement Algorithms</title> <author>
<author initials="R." surname="Housley" fullname="R. Housley"> <organization>Common Vulnerabilities and Exposures</organization>
<organization/> </author>
</author> <date month="June" year="2017"/>
<date year="2015" month="November"/> </front>
</front> </reference>
<seriesInfo name="BCP" value="201"/> <reference anchor="CVE-2017-11104" target="https://cve.mitre.org/cgi-bin
<seriesInfo name="RFC" value="7696"/> /cvename.cgi?name=CVE-2017-11104">
<seriesInfo name="DOI" value="10.17487/RFC7696"/> <front>
</reference> <title>CVE-2017-11104: Improper TSIG validity period check can allow
<?rfc include="reference.RFC.1321.xml"?> TSIG forgery</title>
<?rfc include="reference.RFC.2104.xml"?> <author>
<?rfc include="reference.RFC.2136.xml"?> <organization>Common Vulnerabilities and Exposures</organization>
<?rfc include="reference.RFC.2930.xml"?> </author>
<?rfc include="reference.RFC.3007.xml"?> <date month="June" year="2017"/>
<?rfc include="reference.RFC.3174.xml"?> </front>
<?rfc include="reference.RFC.3645.xml"?> </reference>
<?rfc include="reference.RFC.3874.xml"?> <reference anchor="SHA1SHAMBLES" target="https://eprint.iacr.org/2020/01
<?rfc include="reference.RFC.4033.xml"?> 4.pdf">
<?rfc include="reference.RFC.4034.xml"?> <front>
<?rfc include="reference.RFC.4035.xml"?> <title>SHA-1 is a Shambles</title>
<?rfc include="reference.RFC.4086.xml"?> <author surname="Leurent" initials="G" fullname="Gaetan Leurent"/>
<?rfc include="reference.RFC.4868.xml"?> <author surname="Peyrin" initials="T" fullname="Thomas Peyrin"/>
<?rfc include="reference.RFC.6151.xml"?> <date month="January" year="2020"/>
<?rfc include="reference.RFC.6234.xml"?> </front>
<?rfc include="reference.RFC.6895.xml"?> </reference>
<?rfc include="reference.RFC.8126.xml"?>
<reference anchor="CVE-2017-3142" target="https://cve.mitre.org/cgi-bin/cv
ename.cgi?name=CVE-2017-3142">
<front>
<title>CVE-2017-3142: An error in TSIG authentication can permit unaut
horized zone transfers</title>
<author>
<organization>Common Vulnerabilities and Exposures</organization>
</author>
<date month="June" year="2017"/>
</front>
</reference>
<reference anchor="CVE-2017-3143" target="https://cve.mitre.org/cgi-bin/cv
ename.cgi?name=CVE-2017-3143">
<front>
<title>CVE-2017-3143: An error in TSIG authentication can permit unaut
horized dynamic updates</title>
<author>
<organization>Common Vulnerabilities and Exposures</organization>
</author>
<date month="June" year="2017"/>
</front>
</reference>
<reference anchor="CVE-2017-11104" target="https://cve.mitre.org/cgi-bin/c
vename.cgi?name=CVE-2017-11104">
<front>
<title>CVE-2017-11104: Improper TSIG validity period check can allow T
SIG forgery</title>
<author>
<organization>Common Vulnerabilities and Exposures</organization>
</author>
<date month="June" year="2017"/>
</front>
</reference>
<reference anchor="SHA1SHAMBLES" target="https://eprint.iacr.org/2020/014.
pdf">
<front>
<title>SHA-1 is a Shambles</title>
<author surname="Leurent" initials="G"/>
<author surname="Peyrin" initials="T"/>
<date month="January" year="2020"/>
</front>
</reference>
<!-- <reference anchor="TRANCOLL" target="https://eprint.iacr.org/2020/014.
pdf">
<front>
<title>SHA-1 is a Shambles</title>
<author surname="Leurent" initials="G"/>
<author surname="Peyrin" initials="T"/>
<date month="January" year="2016"/>
</front>
</reference> -->
</references>
<section title="Acknowledgments" anchor="acks">
<t>This document consolidates and updates the earlier documents
by the authors of <xref target="RFC2845"/> (Paul Vixie,
Olafur Gudmundsson, Donald E. Eastlake 3rd and Brian Wellington)
and <xref target="RFC4635"/> (Donald E. Eastlake 3rd).</t>
<t>The security problem addressed by this document was reported
by Clement Berthaux from Synacktiv.</t>
<t>Note for the RFC Editor (to be removed before publication):
the first 'e' in Clement is a fact a small 'e' with acute,
unicode code U+00E9. I do not know if xml2rfc supports non ASCII
characters so I prefer to not experiment with it. BTW I am French too
so I can help if you have questions like correct spelling...</t>
<t>Peter van Dijk, Benno Overeinder, Willem Toroop, Ondrej Sury,
Mukund Sivaraman and Ralph Dolmans participated in the discussions
that prompted this document. Mukund Sivaraman, Martin Hoffman and
Tony Finch made extremely helpful suggestions concerning the
structure and wording of the updated document.</t>
<!-- If we get the reporter correctly spelled we can try to fix some
others here: I can't believe unicode is not required for at least
another name! -->
</section>
<section title="Change History (to be removed before publication)">
<t>RFC EDITOR: Please remove this appendix before publication.</t>
<t>draft-dupont-dnsop-rfc2845bis-00</t>
<t><list>
<t><xref target="RFC4635"/> was merged.</t>
<t>Authors of original documents were moved to
Acknowledgments (<xref target="acks"/>).</t>
<t><xref target="keywords"/> was updated to
<xref target="RFC8174"/> style.</t>
<t>Spit references into normative and informative references
and updated them.</t>
<t>Added a text explaining why this document was written
in the Abstract and at the beginning of the introduction.</t>
<t>Clarified the layout of TSIG RDATA.</t>
<t>Moved the text about using DNSSEC from the Introduction
to the end of Security Considerations.</t>
<t>Added the security clarifications:
<list style="numbers">
<t>Emphasized that MAC is invalid until it is successfully
validated.</t>
<t>Added requirement that a request MAC that has not been
successfully validated MUST NOT be included into a
response.</t>
<t>Added requirement that a request that has not been
validated MUST NOT generate a signed response.</t>
<t>Added note about MAC too short for the local policy to
<xref target="on_error"/>.</t>
<t>Changed the order of server checks and swapped corresponding
sections.</t>
<t>Removed the truncation size limit "also case" as it does not
apply and added confusion.</t>
<t>Relocated the error provision for TSIG truncation to the new
<xref target="trunc_check"/>. Moved from RCODE 22
to RCODE 9 and TSIG ERROR 22, i.e., aligned with other TSIG
error cases.</t>
<t>Added <xref target="trunc_err"/> about truncation error
handling by clients.</t>
<t>Removed the limit to HMAC output in replies as a request
which specified a MAC length longer than the HMAC output
is invalid according to the first processing rule in <xref
target="trunc"/>.</t>
<t>Promoted the requirement that a secret length should be
at least as long as the HMAC output to a SHOULD
<xref target="RFC2119"/> key word.</t>
<t>Added a short text to explain the security issue.</t>
</list></t>
</list></t>
<t>draft-dupont-dnsop-rfc2845bis-01</t>
<t><list>
<t>Improved wording (post-publication comments).</t>
<t>Specialized and renamed the "TSIG on TCP connection"
(<xref target="tcp"/>) to "TSIG on zone transfer over a TCP
connection". Added a SHOULD for a TSIG in each message
(was envelope) for new implementations.</t>
<!-- No other usage than zone transfer -->
<!-- Is a current implementation not adding a TSIG to each message -->
</list></t>
<t>draft-ietf-dnsop-rfc2845bis-00</t>
<t><list>
<t>Adopted by the IETF DNSOP working group: title updated
and version counter reset to 00.</t>
</list></t>
<t>draft-ietf-dnsop-rfc2845bis-01</t>
<t><list>
<t>Relationship between protocol change and principle of
assuming the request MAC is invalid until validated clarified.
(Jinmei Tatuya)</t>
<t>Cross reference to considerations for forwarding servers
added. (Bob Harold)</t>
<t>Added text from <xref target="RFC3645"/> concerning the
signing behavior if a secret key is added during a multi-message
exchange.</t>
<t>Added reference to <xref target="RFC6895"/>.</t>
<t>Many improvements in the wording.</t>
<t>Added RFC 2845 authors as co-authors of this document.</t>
</list></t>
<t>draft-ietf-dnsop-rfc2845bis-02</t>
<t><list>
<t>Added a recommendation to copy time fields in BADKEY errors.
(Mark Andrews)</t>
</list></t>
<t>draft-ietf-dnsop-rfc2845bis-03</t>
<t><list>
<t>Further changes as a result of comments by Mukund Sivaraman.</t>
<t>Miscellaneous changes to wording.</t>
</list></t>
<t>draft-ietf-dnsop-rfc2845bis-04</t>
<t><list>
<t>Major restructuring as a result of comprehensive review by Martin Hoff
man.
Amongst the more significant changes:
<list style="symbols">
<t>More comprehensive introduction.</t>
<t>Merged "Protocol Description" and "Protocol Details" sections.</t>
<t>Reordered sections so as to follow message exchange through "client
"sending", "server receipt", "server sending", "client receipt".</t>
<t>Added miscellaneous clarifications.</t>
</list></t>
</list></t>
<t>draft-ietf-dnsop-rfc2845bis-05</t> <reference anchor="IANA-TSIG"
<t><list> target="https://www.iana.org/assignments/tsig-algorithm-names/">
<t>Make implementation of HMAC-MD5 optional.</t> <front>
<t>Require that the Fudge field in BADTIME response be equal to the <title>TSIG Algorithm Names</title>
Fudge field received from the client.</t> <author><organization>IANA</organization></author>
<t>Added comment concerning the handling of BADTIME messages due to out </front>
of order packet reception.</t> </reference>
</list></t>
<t>draft-ietf-dnsop-rfc2845bis-06</t> <reference anchor="IANA-RCODEs"
<t><list> target="https://www.iana.org/assignments/dns-parameters/">
<t>Wording changes and minor corrections after feedback.</t> <front>
</list></t> <title>DNS RCODEs</title>
<author><organization>IANA</organization></author>
</front>
</reference>
<t>draft-ietf-dnsop-rfc2845bis-07</t> </references>
<t><list> </references>
<t>Updated text about use of hmac-sha1 using suggestion from
Tony Finch.</t>
<t>Corrected name of review policy used for new algorithms.</t>
</list></t>
<t>draft-ietf-dnsop-rfc2845bis-08</t> <section anchor="acks" numbered="false" toc="default">
<t><list> <name>Acknowledgements</name>
<t>Addressed comments from IESG review. These can be found at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ballot.
Significant changes are:
<list style="symbols">
<t>Added references to CVEs that initiated this draft.</t>
<t>Added reference to paper describing SHA1 collisions.</t>
<t>Modified some paragraphs to remove language that has not "aged well"
.</t>
<t>Mentioned that multiple keys allows for periodic key rotation.</t>
<t>Noted that TSIG detects interruption of packet sequence but not prem
ature termination.</t>
<t>Added new algorithms to the algorithm list.</t>
<t>Marked hmac-sha224 as NOT RECOMMENDED.</t>
<t>Added recommendation that there should only be one algorithm for eac
h key.</t>
<t>Added some paragraphs to the security recommendations section.</t>
</list></t>
<t>Other changes: <t>The security problem addressed by this document was reported by
<list style="symbols"> <contact fullname="Clément Berthaux"/> from Synacktiv.</t>
<t>Explicitly define contents Error field in requests. State that "Oth <t><contact fullname="Peter van Dijk"/>, <contact fullname="Benno
er Data" currently has no Overeinder"/>, <contact fullname="Willem Toroop"/>, <contact
meaning in requests.</t> fullname="Ondrej Sury"/>, <contact fullname="Mukund Sivaraman"/>, and
<t>Reworked the section on client processing of response to remove ambi <contact fullname="Ralph Dolmans"/> participated in the discussions that
guity.</t> prompted this document. <contact fullname="Mukund Sivaraman"/>,
<t>Section on TSIG over TCP now mentions zone transfer as an example, r <contact fullname="Martin Hoffman"/>, and <contact fullname="Tony
ather than the entire section Finch"/> made extremely helpful suggestions concerning the structure and
being about zone transfers.</t> wording of the updated document.</t>
<t>Note that quote from RFC2845 in "What is DNSSEC?" section has been e
dited to
refer to the latest standards.</t>
</list></t>
</list></t>
<t>draft-ietf-dnsop-rfc2845bis-09</t> <t>Stephen Morris would like to thank Internet Systems Consortium for its
<t><list> support of his participation in the creation of this document.</t>
<t>Change use of hmac-224 from NOT RECOMMENDED to MAY.</t>
</list></t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 196 change blocks. 
1051 lines changed or deleted 875 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/