draft-dupont-dnsop-rfc2845bis-00.txt   draft-dupont-dnsop-rfc2845bis-01.txt 
Internet Engineering Task Force F. Dupont, Ed. Internet Engineering Task Force F. Dupont, Ed.
Internet-Draft S. Morris Internet-Draft S. Morris
Obsoletes: 2845, 4635 (if approved) ISC Obsoletes: 2845, 4635 (if approved) ISC
Intended status: Standards Track October 30, 2017 Intended status: Standards Track March 5, 2018
Expires: May 3, 2018 Expires: September 6, 2018
Secret Key Transaction Authentication for DNS (TSIG) Secret Key Transaction Authentication for DNS (TSIG)
draft-dupont-dnsop-rfc2845bis-00 draft-dupont-dnsop-rfc2845bis-01
Abstract Abstract
This protocol allows for transaction level authentication using This protocol allows for transaction level authentication using
shared secrets and one way hashing. It can be used to authenticate shared secrets and one way hashing. It can be used to authenticate
dynamic updates as coming from an approved client, or to authenticate dynamic updates as coming from an approved client, or to authenticate
responses as coming from an approved recursive name server. responses as coming from an approved name server.
No provision has been made here for distributing the shared secrets: No provision has been 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 such as name servers and clients using some out of band mechanism.
sneaker-net until a secure automated mechanism for key distribution
is available.
This document includes revised original TSIG specifications (RFC2845) This document includes revised original TSIG specifications (RFC2845)
and the extension for HMAC-SHA (RFC4635). and its extension for HMAC-SHA (RFC4635).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 36 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Key words . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. New Assigned Numbers . . . . . . . . . . . . . . . . . . . . 4 3. New Assigned Numbers . . . . . . . . . . . . . . . . . . . . 4
4. TSIG RR Format . . . . . . . . . . . . . . . . . . . . . . . 5 4. TSIG RR Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. TSIG RR Type . . . . . . . . . . . . . . . . . . . . . . 5 4.1. TSIG RR Type . . . . . . . . . . . . . . . . . . . . . . 5
4.2. TSIG Calculation . . . . . . . . . . . . . . . . . . . . 5 4.2. TSIG Calculation . . . . . . . . . . . . . . . . . . . . 5
4.3. TSIG Record Format . . . . . . . . . . . . . . . . . . . 5 4.3. TSIG Record Format . . . . . . . . . . . . . . . . . . . 5
4.3.1. TSIG RDATA Wire Format . . . . . . . . . . . . . . . 6
4.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
5.1. Effects of adding TSIG to outgoing message . . . . . . . 8 5.1. Effects of adding TSIG to outgoing message . . . . . . . 7
5.2. TSIG processing on incoming messages . . . . . . . . . . 8 5.2. TSIG processing on incoming messages . . . . . . . . . . 8
5.3. Time values used in TSIG calculations . . . . . . . . . . 8 5.3. Time values used in TSIG calculations . . . . . . . . . . 8
5.4. TSIG Variables and Coverage . . . . . . . . . . . . . . . 9 5.4. TSIG Variables and Coverage . . . . . . . . . . . . . . . 8
5.4.1. DNS Message . . . . . . . . . . . . . . . . . . . . . 9 5.4.1. DNS Message . . . . . . . . . . . . . . . . . . . . . 9
5.4.2. TSIG Variables . . . . . . . . . . . . . . . . . . . 9 5.4.2. TSIG Variables . . . . . . . . . . . . . . . . . . . 9
5.4.3. Request MAC . . . . . . . . . . . . . . . . . . . . . 10 5.4.3. Request MAC . . . . . . . . . . . . . . . . . . . . . 9
5.5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10
6.1. TSIG generation on requests . . . . . . . . . . . . . . . 10 6.1. TSIG generation on requests . . . . . . . . . . . . . . . 10
6.2. TSIG on Answers . . . . . . . . . . . . . . . . . . . . . 10 6.2. TSIG on Answers . . . . . . . . . . . . . . . . . . . . . 10
6.3. TSIG on TSIG Error returns . . . . . . . . . . . . . . . 11 6.3. TSIG on TSIG Error returns . . . . . . . . . . . . . . . 10
6.4. TSIG on TCP connection . . . . . . . . . . . . . . . . . 11 6.4. TSIG on zone tranfer over a TCP connection . . . . . . . 11
6.5. Server TSIG checks . . . . . . . . . . . . . . . . . . . 12 6.5. Server TSIG checks . . . . . . . . . . . . . . . . . . . 11
6.5.1. Key check and error handling . . . . . . . . . . . . 12 6.5.1. Key check and error handling . . . . . . . . . . . . 11
6.5.2. Specifying Truncation . . . . . . . . . . . . . . . . 12 6.5.2. Specifying Truncation . . . . . . . . . . . . . . . . 12
6.5.3. MAC check and error handling . . . . . . . . . . . . 13 6.5.3. MAC check and error handling . . . . . . . . . . . . 12
6.5.4. Time check and error handling . . . . . . . . . . . . 13 6.5.4. Time check and error handling . . . . . . . . . . . . 13
6.5.5. Truncation check and error handling . . . . . . . . . 13 6.5.5. Truncation check and error handling . . . . . . . . . 13
6.6. Client processing of answer . . . . . . . . . . . . . . . 13 6.6. Client processing of answer . . . . . . . . . . . . . . . 13
6.6.1. Key error handling . . . . . . . . . . . . . . . . . 14 6.6.1. Key error handling . . . . . . . . . . . . . . . . . 13
6.6.2. MAC error handling . . . . . . . . . . . . . . . . . 14 6.6.2. MAC error handling . . . . . . . . . . . . . . . . . 14
6.6.3. Time error handling . . . . . . . . . . . . . . . . . 14 6.6.3. Time error handling . . . . . . . . . . . . . . . . . 14
6.6.4. Truncation error handling . . . . . . . . . . . . . . 14 6.6.4. Truncation error handling . . . . . . . . . . . . . . 14
6.7. Special considerations for forwarding servers . . . . . . 14 6.7. Special considerations for forwarding servers . . . . . . 14
7. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 15 7. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 14
8. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 15 8. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 15
9. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 16 9. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11.1. Issue fixed in this document . . . . . . . . . . . . . . 18 11.1. Issue fixed in this document . . . . . . . . . . . . . . 18
11.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 18 11.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 22 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
In 2017, security problems in two nameservers strictly following In 2017, security problems in two nameservers strictly following
[RFC2845] and [RFC4635] (i.e., TSIG and HMAC-SHA extension) [RFC2845] and [RFC4635] (i.e., TSIG and its HMAC-SHA extension)
specifications were discovered. The implementations were fixed but, specifications were discovered. The implementations were fixed but,
to avoid similar problems in the future, the two documents were to avoid similar problems in the future, the two documents were
updated and merged, producing these revised specifications for TSIG. updated and merged, producing these revised specifications for TSIG.
The Domain Name System (DNS) [RFC1034], [RFC1035] is a replicated The Domain Name System (DNS) [RFC1034], [RFC1035] is a replicated
hierarchical distributed database system that provides information hierarchical distributed database system that provides information
fundamental to Internet operations, such as name <=> address fundamental to Internet operations, such as name <=> address
translation and mail handling information. translation and mail handling information.
This document specifies use of a message authentication code (MAC), This document specifies use of a message authentication code (MAC),
skipping to change at page 4, line 14 skipping to change at page 4, line 10
A further use of this mechanism is to protect zone transfers. In A further use of this mechanism is to protect zone transfers. In
this case the data covered would be the whole zone transfer including this case the data covered would be the whole zone transfer including
any glue records sent. The protocol described by DNSSEC does not any glue records sent. The protocol described by DNSSEC does not
protect glue records and unsigned records unless SIG(0) (transaction protect glue records and unsigned records unless SIG(0) (transaction
signature) is used. signature) is used.
The authentication mechanism proposed in this document uses shared The authentication mechanism proposed in this document uses shared
secret keys to establish a trust relationship between two entities. secret keys to establish a trust relationship between two entities.
Such keys must be protected in a fashion similar to private keys, Such keys must be protected in a fashion similar to private keys,
lest a third party masquerade as one of the intended parties (forge lest a third party masquerade as one of the intended parties (by
MACs). There is an urgent need to provide simple and efficient forging the MAC). There is an urgent need to provide simple and
authentication between clients and local servers and this proposal efficient authentication between clients and local servers and this
addresses that need. This proposal is unsuitable for general server proposal addresses that need. The proposal is unsuitable for general
to server authentication for servers which speak with many other server to server authentication for servers which speak with many
servers, since key management would become unwieldy with the number other servers, since key management would become unwieldy with the
of shared keys going up quadratically. But it is suitable for many number of shared keys going up quadratically. But it is suitable for
resolvers on hosts that only talk to a few recursive servers. many resolvers on hosts that only talk to a few recursive servers.
A server acting as an indirect caching resolver -- a "forwarder" in A server acting as an indirect caching resolver -- a "forwarder" in
common usage -- might use transaction-based authentication when common usage -- might use transaction-based authentication when
communicating with its small number of preconfigured "upstream" communicating with its small number of preconfigured "upstream"
servers. Other uses of DNS secret key authentication and possible servers. Other uses of DNS secret key authentication and possible
systems for automatic secret key distribution may be proposed in systems for automatic secret key distribution may be proposed in
separate future documents. separate future documents.
Note that use of TSIG presumes prior agreement between the resolver Note that use of TSIG presumes prior agreement between the two
and server involved as to the algorithm and key to be used. parties involved (e.g., resolver and server) as to the algorithm and
key to be used.
Since the publication of first version of this document ([RFC2845]) a Since the publication of first version of this document ([RFC2845]) a
mechanism based on asymmetric signatures using the SIG RR was mechanism based on asymmetric signatures using the SIG RR was
specified (SIG(0) [RFC2931]) when this document uses symmetric specified (SIG(0) [RFC2931]) whereas this document uses symmetric
authentication codes calculated by HMAC [RFC2104] using strong hash authentication codes calculated by HMAC [RFC2104] using strong hash
functions. functions.
2. Key words 2. Key words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 5, line 22 skipping to change at page 5, line 20
mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and
MUST NOT be cached. TSIG RRs are used for authentication between DNS MUST NOT be cached. TSIG RRs are used for authentication between DNS
entities that have established a shared secret key. TSIG RRs are entities that have established a shared secret key. TSIG RRs are
dynamically computed to cover a particular DNS transaction and are dynamically computed to cover a particular DNS transaction and are
not DNS RRs in the usual sense. not DNS RRs in the usual sense.
4.2. TSIG Calculation 4.2. TSIG Calculation
As the TSIG RRs are related to one DNS request/response, there is no As the TSIG RRs are related to one DNS request/response, there is no
value in storing or retransmitting them, thus the TSIG RR is value in storing or retransmitting them, thus the TSIG RR is
discarded once it has been used to authenticate a DNS message. All discarded once it has been used to authenticate a DNS message.
multi-octet integers in the TSIG record are sent in network byte Recommendations concerning the message digest agorithm can be found
order (see [RFC1035] 2.3.2). in Section 7. All multi-octet integers in the TSIG record are sent
in network byte order (see [RFC1035] 2.3.2).
4.3. TSIG Record Format 4.3. TSIG Record Format
NAME The name of the key used in domain name syntax. The name NAME The name of the key used in domain name syntax. The name
should reflect the names of the hosts and uniquely identify the should reflect the names of the hosts and uniquely identify the
key among a set of keys these two hosts may share at any given key among a set of keys these two hosts may share at any given
time. If hosts A.site.example and B.example.net share a key, time. If hosts A.site.example and B.example.net share a key,
possibilities for the key name include <id>.A.site.example, possibilities for the key name include <id>.A.site.example,
<id>.B.example.net, and <id>.A.site.example.B.example.net. It <id>.B.example.net, and <id>.A.site.example.B.example.net. It
should be possible for more than one key to be in simultaneous should be possible for more than one key to be in simultaneous
use among a set of interacting hosts. The name only needs to use among a set of interacting hosts. The name only needs to
be meaningful to the communicating hosts but a meaningful be meaningful to the communicating hosts but a meaningful
mnemonic name as above is strongly recommended. mnemonic name as above is strongly recommended.
The name may be used as a local index to the key involved and The name may be used as a local index to the key involved and
it is recommended that it be globally unique. Where a key is it is recommended that it be globally unique. Where a key is
just shared between two hosts, its name actually only need only just shared between two hosts, its name actually need only be
be meaningful to them but it is recommended that the key name meaningful to them but it is recommended that the key name be
be mnemonic and incorporate the resolver and server host names mnemonic and incorporate the resolver and server host names in
in that order. that order.
TYPE TSIG (250: Transaction SIGnature) TYPE TSIG (250: Transaction SIGnature)
CLASS ANY CLASS ANY
TTL 0 TTL 0
RdLen (variable)
RDATA
4.3.1. TSIG RDATA Wire Format
The RDATA for a TSIG RR consists of an octet stream Algorithm Name RdLen (variable)
field, a uint48_t Time Signed field, a uint16_t Fudge field, a RDATA The RDATA for a TSIG RR consists of an octet stream Algorithm
uint16_t MAC Size field, a octet stream MAC field, a uint16_t Name field, a uint48_t Time Signed field, a uint16_t Fudge
Original ID, a uint16_t Error field, a uint16_t Other Len field and field, a uint16_t MAC Size field, a octet stream MAC field, a
an octet stream of Other Data. uint16_t Original ID, a uint16_t Error field, a uint16_t Other
Len field and an octet stream of Other Data.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 36 skipping to change at page 6, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original ID | Error | | Original ID | Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Len | / | Other Len | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Other Data / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Other Data /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.1.1. The Algorithm Name Field The contents of the RDATA fields are:
The Algorithm Name field identifies the TSIG algorithm name in the
domain name syntax.
4.3.1.2. The Time Signed Field
The Time Signed field specifies seconds since 1970-01-01 UTC.
4.3.1.3. The Fudge Field
The Fudge field specifies allowed time difference in seconds
permitted in the Time Signed field.
4.3.1.4. The MAC Size Field
The MAC Size field specifies the length of MAC field in octets.
Truncation is indicated by a MAC size less than the HMAC size.
4.3.1.5. The MAC Field * Algorithm Name - identifies the TSIG algorithm name in the
domain name syntax.
The MAC field contents are defined by the used Algorithm. * Time Signed - the The Time Signed field specifies seconds
since 00:00 on 1970-01-01 UTC.
4.3.1.6. The Error field * Fudge - specifies allowed time difference in seconds
permitted in the Time Signed field.
The Error field contains the Expanded RCODE covering TSIG processing. * MAC Size - the MAC Size field specifies the length of MAC
field in octets. Truncation is indicated by a MAC size less
than the HMAC size.
4.3.1.7. The Other Len Field * MAC - the contents of the MAC field are defined by the TSIG
algorithm used.
The Other Len field specifies the length of Other Data in octets. * Error - contains the expanded RCODE covering TSIG
processing.
4.3.1.8. The Other Data Field * Other Len - specifies the length of the "Other Data" field
in octets.
The Other Data field is empty unless Error == BADTIME. * Other Data - this field will be empty unless the content of
the Error field is BADTIME, in which case it will contain
the server's current time (see Section 6.5.4).
4.4. Example 4.4. Example
NAME HOST.EXAMPLE. NAME HOST.EXAMPLE.
TYPE TSIG TYPE TSIG
CLASS ANY CLASS ANY
TTL 0 TTL 0
skipping to change at page 8, line 9 skipping to change at page 7, line 42
MAC As appropriate MAC As appropriate
Original ID As appropriate Original ID As appropriate
Error 0 (NOERROR) Error 0 (NOERROR)
Other Len 0 Other Len 0
Other Data Empty Other Data Empty
5. Protocol Operation 5. Protocol Operation
5.1. Effects of adding TSIG to outgoing message 5.1. Effects of adding TSIG to outgoing message
Once the outgoing message has been constructed, the keyed message Once the outgoing message has been constructed, the HMAC computation
digest operation can be performed. The resulting message digest will can be performed. The resulting MAC will then be stored in a TSIG
then be stored in a TSIG which is appended to the additional data which is appended to the additional data section (the ARCOUNT is
section (the ARCOUNT is incremented to reflect this). If the TSIG incremented to reflect this). If the TSIG record cannot be added
record cannot be added without causing the message to be truncated, without causing the message to be truncated, the server MUST alter
the server MUST alter the response so that a TSIG can be included. the response so that a TSIG can be included. This response consists
This response consists of only the question and a TSIG record, and of only the question and a TSIG record, and has the TC bit set and
has the TC bit set and RCODE 0 (NOERROR). The client SHOULD at this RCODE 0 (NOERROR). The client SHOULD at this point retry the request
point retry the request using TCP (per [RFC1035] 4.2.2). using TCP (per [RFC1035] 4.2.2).
5.2. TSIG processing on incoming messages 5.2. TSIG processing on incoming messages
If an incoming message contains a TSIG record, it MUST be the last If an incoming message contains a TSIG record, it MUST be the last
record in the additional section. Multiple TSIG records are not record in the additional section. Multiple TSIG records are not
allowed. If a TSIG record is present in any other position, the allowed. If a TSIG record is present in any other position, the DNS
packet is dropped and a response with RCODE 1 (FORMERR) MUST be message is dropped and a response with RCODE 1 (FORMERR) MUST be
returned. Upon receipt of a message with a correctly placed TSIG RR, returned. Upon receipt of a message with a correctly placed TSIG RR,
the TSIG RR is copied to a safe location, removed from the DNS the TSIG RR is copied to a safe location, removed from the DNS
Message, and decremented out of the DNS message header's ARCOUNT. At Message, and decremented out of the DNS message header's ARCOUNT. At
this point the keyed message digest operation is performed: until this point the HMAC computation is performed: until this operation
this operation concludes that the signature is valid, the signature concludes that the signature is valid, the signature MUST be
MUST be considered to be invalid. If the algorithm name or key name considered to be invalid.
is unknown to the recipient, or if the message digests do not match,
the whole DNS message MUST be discarded. If the message is a query, If the algorithm name or key name is unknown to the recipient, or if
a response with RCODE 9 (NOTAUTH) MUST be sent back to the originator the MACs do not match, the whole DNS message MUST be discarded. If
with TSIG ERROR 17 (BADKEY) or TSIG ERROR 16 (BADSIG). If no key is the message is a query, a response with RCODE 9 (NOTAUTH) MUST be
available to sign this message it MUST be sent unsigned (MAC size == sent back to the originator with TSIG ERROR 17 (BADKEY) or TSIG ERROR
0 and empty MAC). A message to the system operations log SHOULD be 16 (BADSIG). If no key is available to sign this message it MUST be
generated, to warn the operations staff of a possible security sent unsigned (MAC size == 0 and empty MAC). A message to the system
incident in progress. Care should be taken to ensure that logging of operations log SHOULD be generated, to warn the operations staff of a
this type of event does not open the system to a denial of service possible security incident in progress. Care should be taken to
attack. ensure that logging of this type of event does not open the system to
a denial of service attack.
5.3. Time values used in TSIG calculations 5.3. Time values used in TSIG calculations
The data digested includes the two timer values in the TSIG header in The data digested includes the two timer values in the TSIG header in
order to defend against replay attacks. If this were not done, an order to defend against replay attacks. If this were not done, an
attacker could replay old messages but update the "Time Signed" and attacker could replay old messages but update the "Time Signed" and
"Fudge" fields to make the message look new. This data is named "Fudge" fields to make the message look new. This data is named
"TSIG Timers", and for the purpose of digest calculation they are "TSIG Timers", and for the purpose of MAC calculation they are
invoked in their "on the wire" format, in the following order: first invoked in their "on the wire" format, in the following order: first
Time Signed, then Fudge. For example: Time Signed, then Fudge. For example:
Field Name Value Wire Format Meaning Field Name Value Wire Format Meaning
----------- --------- ----------------- ------------------------ ----------- --------- ----------------- ------------------------
Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997 Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997
Fudge 300 01 2C 5 minutes Fudge 300 01 2C 5 minutes
5.4. TSIG Variables and Coverage 5.4. TSIG Variables and Coverage
When generating or verifying the contents of a TSIG record, the When generating or verifying the contents of a TSIG record, the
following data are digested, in network byte order or wire format, as following data are passed as input to MAC computation, in network
appropriate: byte order or wire format, as appropriate:
5.4.1. DNS Message 5.4.1. DNS Message
A whole and complete DNS message in wire format, before the TSIG RR A whole and complete DNS message in wire format, before the TSIG RR
has been added to the additional data section and before the DNS has been added to the additional data section and before the DNS
Message Header's ARCOUNT field has been incremented to contain the Message Header's ARCOUNT field has been incremented to contain the
TSIG RR. If the message ID differs from the original message ID, the TSIG RR. If the message ID differs from the original message ID, the
original message ID is substituted for the message ID. This could original message ID is substituted for the message ID. This could
happen when forwarding a dynamic update request, for example. happen when forwarding a dynamic update request, for example.
skipping to change at page 9, line 39 skipping to change at page 9, line 28
TSIG RR NAME Key name, in canonical wire format TSIG RR NAME Key name, in canonical wire format
TSIG RR CLASS (Always ANY in the current specification) TSIG RR CLASS (Always ANY in the current specification)
TSIG RR TTL (Always 0 in the current specification) TSIG RR TTL (Always 0 in the current specification)
TSIG RDATA Algorithm Name in canonical wire format TSIG RDATA Algorithm Name in canonical wire format
TSIG RDATA Time Signed in network byte order TSIG RDATA Time Signed in network byte order
TSIG RDATA Fudge in network byte order TSIG RDATA Fudge in network byte order
TSIG RDATA Error in network byte order TSIG RDATA Error in network byte order
TSIG RDATA Other Len in network byte order TSIG RDATA Other Len in network byte order
TSIG RDATA Other Data exactly as transmitted TSIG RDATA Other Data exactly as transmitted
The RR RDLEN and RDATA MAC Length are not included in the hash since The RR RDLEN and RDATA MAC Length are not included in the input to
they are not guaranteed to be knowable before the MAC is generated. MAC computation since they are not guaranteed to be knowable before
the MAC is generated.
The Original ID field is not included in this section, as it has The Original ID field is not included in this section, as it has
already been substituted for the message ID in the DNS header and already been substituted for the message ID in the DNS header and
hashed. hashed.
For each label type, there must be a defined "Canonical wire format" For each label type, there must be a defined "Canonical wire format"
that specifies how to express a label in an unambiguous way. For that specifies how to express a label in an unambiguous way. For
label type 00, this is defined in [RFC4034], for label type 01, this label type 00, this is defined in [RFC4034], for label type 01, this
is defined in [RFC6891]. The use of label types other than 00 and 01 is defined in [RFC6891]. The use of label types other than 00 and 01
is not defined for this specification. is not defined for this specification.
5.4.3. Request MAC 5.4.3. Request MAC
When generating the MAC to be included in a response, the validated When generating the MAC to be included in a response, the validated
request MAC MUST be included in the digest. If the request MAC request MAC MUST be included in the MAC computation. If the request
failed to validate, an unsigned error message MUST be returned MAC failed to validate, an unsigned error message MUST be returned
instead. (Section 6.3). instead. (Section 6.3).
The request's MAC is digested in wire format, including the following The request's MAC is digested in wire format, including the following
fields: fields:
Field Type Description Field Type Description
---------- ------------ ---------------------- ---------- ------------ ----------------------
MAC Length uint16_t in network byte order MAC Length uint16_t in network byte order
MAC Data octet stream exactly as transmitted MAC Data octet stream exactly as transmitted
5.5. Padding 5.5. Padding
Digested components are fed into the hashing function as a continuous Digested components (i.e., inputs to HMAC computation) are fed into
octet stream with no interfield padding. the hashing function as a continuous octet stream with no interfield
padding.
6. Protocol Details 6. Protocol Details
6.1. TSIG generation on requests 6.1. TSIG generation on requests
Client performs the message digest operation and appends a TSIG Client performs the HMAC computation and appends a TSIG record to the
record to the additional data section and transmits the request to additional data section and transmits the request to the server. The
the server. The client MUST store the message digest from the client MUST store the MAC from the request while awaiting an answer.
request while awaiting an answer. The digest components for a The digest components for a request are:
request are:
DNS Message (request) DNS Message (request)
TSIG Variables (request) TSIG Variables (request)
Note that some older name servers will not accept requests with a Note that some older name servers will not accept requests with a
nonempty additional data section. Clients SHOULD only attempt signed nonempty additional data section. Clients SHOULD only attempt signed
transactions with servers who are known to support TSIG and share transactions with servers who are known to support TSIG and share
some secret key with the client -- so, this is not a problem in some secret key with the client -- so, this is not a problem in
practice. practice.
skipping to change at page 11, line 18 skipping to change at page 11, line 9
When a server detects an error relating to the key or MAC, the server When a server detects an error relating to the key or MAC, the server
SHOULD send back an unsigned error message (MAC size == 0 and empty SHOULD send back an unsigned error message (MAC size == 0 and empty
MAC). If an error is detected relating to the TSIG validity period MAC). If an error is detected relating to the TSIG validity period
or the MAC is too short for the local policy, the server SHOULD send or the MAC is too short for the local policy, the server SHOULD send
back a signed error message. The digest components are: back a signed error message. The digest components are:
Request MAC (if the request MAC validated) Request MAC (if the request MAC validated)
DNS Message (response) DNS Message (response)
TSIG Variables (response) TSIG Variables (response)
The reason that the request is not included in this digest in some The reason that the request is not included in this MAC in some cases
cases is to make it possible for the client to verify the error. If is to make it possible for the client to verify the error. If the
the error is not a TSIG error the response MUST be generated as error is not a TSIG error the response MUST be generated as specified
specified in Section 6.2. in Section 6.2.
6.4. TSIG on TCP connection 6.4. TSIG on zone tranfer over a TCP connection
A DNS TCP session can include multiple DNS envelopes. This is, for A zone transfer over a DNS TCP session can include multiple DNS
example, commonly used by zone transfer. Using TSIG on such a messages. Using TSIG on such a connection can protect the connection
connection can protect the connection from hijacking and provide data from hijacking and provide data integrity. The TSIG MUST be included
integrity. The TSIG MUST be included on the first and last DNS on the first and last DNS messages, and for new implementations
envelopes. It can be optionally placed on any intermediary SHOULD be placed on all intermediary messages. For backward
envelopes. It is expensive to include it on every envelopes, but it compatibility the client which receives DNS messages and verifies
MUST be placed on at least every 100'th envelope. The first envelope TSIG MUST accept up to 99 intermediary messages without a TSIG. The
is processed as a standard answer, and subsequent messages have the first envelope is processed as a standard answer, and subsequent
following digest components: messages have the following digest components:
Prior Digest (running) Prior MAC (running)
DNS Messages (any unsigned messages since the last TSIG) DNS Messages (any unsigned messages since the last TSIG)
TSIG Timers (current message) TSIG Timers (current message)
This allows the client to rapidly detect when the session has been This allows the client to rapidly detect when the session has been
altered; at which point it can close the connection and retry. If a altered; at which point it can close the connection and retry. If a
client TSIG verification fails, the client MUST close the connection. client TSIG verification fails, the client MUST close the connection.
If the client does not receive TSIG records frequently enough (as If the client does not receive TSIG records frequently enough (as
specified above) it SHOULD assume the connection has been hijacked specified above) it SHOULD assume the connection has been hijacked
and it SHOULD close the connection. The client SHOULD treat this the and it SHOULD close the connection. The client SHOULD treat this the
same way as they would any other interrupted transfer (although the same way as they would any other interrupted transfer (although the
skipping to change at page 12, line 33 skipping to change at page 12, line 18
HMAC is not needed, it is reasonable to truncate the HMAC and use the HMAC is not needed, it is reasonable to truncate the HMAC and use the
truncated value for authentication. HMAC SHA-1 truncated to 96 bits truncated value for authentication. HMAC SHA-1 truncated to 96 bits
is an option available in several IETF protocols, including IPsec and is an option available in several IETF protocols, including IPsec and
TLS. TLS.
Processing of a truncated MAC follows these rules Processing of a truncated MAC follows these rules
1. If "MAC size" field is greater than HMAC output length: 1. If "MAC size" field is greater than HMAC output length:
This case MUST NOT be generated and, if received, MUST cause the This case MUST NOT be generated and, if received, MUST cause the
packet to be dropped and RCODE 1 (FORMERR) to be returned. DNS message to be dropped and RCODE 1 (FORMERR) to be returned.
2. If "MAC size" field equals HMAC output length: 2. If "MAC size" field equals HMAC output length:
The entire output HMAC output is present and used. The entire output HMAC output is present and used.
3. "MAC size" field is less than HMAC output length but greater than 3. "MAC size" field is less than HMAC output length but greater than
that specified in case 4, below: that specified in case 4, below:
This is sent when the signer has truncated the HMAC output to an This is sent when the signer has truncated the HMAC output to an
allowable length, as described in [RFC2104], taking initial allowable length, as described in [RFC2104], taking initial
octets and discarding trailing octets. TSIG truncation can only octets and discarding trailing octets. TSIG truncation can only
be to an integral number of octets. On receipt of a packet with be to an integral number of octets. On receipt of a DNS message
truncation thus indicated, the locally calculated MAC is with truncation thus indicated, the locally calculated MAC is
similarly truncated and only the truncated values are compared similarly truncated and only the truncated values are compared
for authentication. The request MAC used when calculating the for authentication. The request MAC used when calculating the
TSIG MAC for a reply is the truncated request MAC. TSIG MAC for a reply is the truncated request MAC.
4. "MAC size" field is less than the larger of 10 (octets) and half 4. "MAC size" field is less than the larger of 10 (octets) and half
the length of the hash function in use: the length of the hash function in use:
With the exception of certain TSIG error messages described in With the exception of certain TSIG error messages described in
Section 6.3, where it is permitted that the MAC size be zero, Section 6.3, where it is permitted that the MAC size be zero,
this case MUST NOT be generated and, if received, MUST cause the this case MUST NOT be generated and, if received, MUST cause the
packet to be dropped and RCODE 1 (FORMERR) to be returned. DNS message to be dropped and RCODE 1 (FORMERR) to be returned.
6.5.3. MAC check and error handling 6.5.3. MAC check and error handling
If a TSIG fails to verify, the server MUST generate an error response If a TSIG fails to verify, the server MUST generate an error response
as specified in Section 6.3 with RCODE 9 (NOTAUTH) and TSIG ERROR 16 as specified in Section 6.3 with RCODE 9 (NOTAUTH) and TSIG ERROR 16
(BADSIG). This response MUST be unsigned as specified in (BADSIG). This response MUST be unsigned as specified in
Section 6.3. The server SHOULD log the error. Section 6.3. The server SHOULD log the error.
6.5.4. Time check and error handling 6.5.4. Time check and error handling
skipping to change at page 13, line 46 skipping to change at page 13, line 34
Section 6.5.2 above but the MAC is too short for the local policy in Section 6.5.2 above but the MAC is too short for the local policy in
force, an RCODE 9 (NOTAUTH) and TSIG ERROR 22 (BADTRUNC) MUST be force, an RCODE 9 (NOTAUTH) and TSIG ERROR 22 (BADTRUNC) MUST be
returned. The server SHOULD log the error. returned. The server SHOULD log the error.
6.6. Client processing of answer 6.6. Client processing of answer
When a client receives a response from a server and expects to see a When a client receives a response from a server and expects to see a
TSIG, it first checks if the TSIG RR is present in the response. TSIG, it first checks if the TSIG RR is present in the response.
Otherwise, the response is treated as having a format error and Otherwise, the response is treated as having a format error and
discarded. The client then extracts the TSIG, adjusts the ARCOUNT, discarded. The client then extracts the TSIG, adjusts the ARCOUNT,
and calculates the keyed digest in the same way as the server, and calculates the MAC in the same way as the server, applying the
applying the same rules to decide if truncated MAC is valid. If the same rules to decide if truncated MAC is valid. If the TSIG does not
TSIG does not validate, that response MUST be discarded, unless the validate, that response MUST be discarded, unless the RCODE is 9
RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to (NOTAUTH), in which case the client SHOULD attempt to verify the
verify the response as if it were a TSIG Error response, as specified response as if it were a TSIG Error response, as specified in
in Section 6.3. A message containing an unsigned TSIG record or a Section 6.3. A message containing an unsigned TSIG record or a TSIG
TSIG record which fails verification SHOULD NOT be considered an record which fails verification SHOULD NOT be considered an
acceptable response; the client SHOULD log an error and continue to acceptable response; the client SHOULD log an error and continue to
wait for a signed response until the request times out. wait for a signed response until the request times out.
6.6.1. Key error handling 6.6.1. Key error handling
If an RCODE on a response is 9 (NOTAUTH), and the response TSIG If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
validates, and the TSIG key is different from the key used on the validates, and the TSIG key is different from the key used on the
request, then this is a Key error. The client MAY retry the request request, then this is a Key error. The client MAY retry the request
using the key specified by the server. This should never occur, as a using the key specified by the server. This should never occur, as a
server MUST NOT sign a response with a different key than signed the server MUST NOT sign a response with a different key than signed the
skipping to change at page 15, line 22 skipping to change at page 15, line 12
[RFC2104]). The "HMAC-MD5" algorithm is mandatory to implement for [RFC2104]). The "HMAC-MD5" algorithm is mandatory to implement for
interoperability. interoperability.
The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as
compared to the 128 bits for MD5), and additional hash algorithms in compared to the 128 bits for MD5), and additional hash algorithms in
the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384, the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384,
and 512 bits may be preferred in some cases. This is because and 512 bits may be preferred in some cases. This is because
increasingly successful cryptanalytic attacks are being made on the increasingly successful cryptanalytic attacks are being made on the
shorter hashes. shorter hashes.
Use of TSIG between a DNS resolver and server is by mutual agreement. Use of TSIG between two DNS agents is by mutual agreement. That
That agreement can include the support of additional algorithms and agreement can include the support of additional algorithms and
criteria as to which algorithms and truncations are acceptable, criteria as to which algorithms and truncations are acceptable,
subject to the restriction and guidelines in Section 6.5.2 above. subject to the restriction and guidelines in Section 6.5.2 above.
Key agreement can be by the TKEY mechanism [RFC2930] or some other Key agreement can be by the TKEY mechanism [RFC2930] or some other
mutually agreeable method. mutually agreeable method.
The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
included in the table below for convenience. Implementations that included in the table below for convenience. Implementations that
support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
implement gss-tsig and the other algorithms listed below. implement gss-tsig and the other algorithms listed below.
skipping to change at page 15, line 48 skipping to change at page 15, line 38
Mandatory hmac-sha1 Mandatory hmac-sha1
Optional hmac-sha224 Optional hmac-sha224
Mandatory hmac-sha256 Mandatory hmac-sha256
Optional hmac-sha384 Optional hmac-sha384
Optional hmac-sha512 Optional hmac-sha512
SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
8. TSIG Truncation Policy 8. TSIG Truncation Policy
Use of TSIG is by mutual agreement between a resolver and server. Use of TSIG is by mutual agreement between two DNS agents, e.g., a
Implicit in such an "agreement" are criteria as to acceptable keys resolver and server. Implicit in such an "agreement" are criteria as
and algorithms and, with the extensions in this document, to acceptable keys and algorithms and, with the extensions in this
truncations. Note that it is common for implementations to bind the document, truncations. Note that it is common for implementations to
TSIG secret key or keys that may be in place at a resolver and server bind the TSIG secret key or keys that may be in place at two parties
to particular algorithms. Thus, such implementations only permit the to particular algorithms. Thus, such implementations only permit the
use of an algorithm if there is an associated key in place. Receipt use of an algorithm if there is an associated key in place. Receipt
of an unknown, unimplemented, or disabled algorithm typically results of an unknown, unimplemented, or disabled algorithm typically results
in a BADKEY error. in a BADKEY error.
Local policies MAY require the rejection of TSIGs, even though they Local policies MAY require the rejection of TSIGs, even though they
use an algorithm for which implementation is mandatory. use an algorithm for which implementation is mandatory.
When a local policy permits acceptance of a TSIG with a particular 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 SHOULD
skipping to change at page 17, line 4 skipping to change at page 16, line 40
A name server usually runs privileged, which means its configuration A name server usually runs privileged, which means its configuration
data need not be visible to all users of the host. For this reason, data need not be visible to all users of the host. For this reason,
a host that implements transaction-based authentication should a host that implements transaction-based authentication should
probably be configured with a "stub resolver" and a local caching and probably be configured with a "stub resolver" and a local caching and
forwarding name server. This presents a special problem for forwarding name server. This presents a special problem for
[RFC2136] which otherwise depends on clients to communicate only with [RFC2136] which otherwise depends on clients to communicate only with
a zone's authoritative name servers. a zone's authoritative name servers.
Use of strong random shared secrets is essential to the security of Use of strong random shared secrets is essential to the security of
TSIG. See [RFC4086] for a discussion of this issue. The secret TSIG. See [RFC4086] for a discussion of this issue. The secret
SHOULD be at least as long as the keyed message digest, i.e., 16 SHOULD be at least as long as the HMAC output, i.e., 16 bytes for
bytes for HMAC-MD5 or 20 bytes for HMAC-SHA1. HMAC-MD5 or 20 bytes for HMAC-SHA1.
10. IANA Considerations 10. IANA Considerations
IANA maintains a registry of algorithm names to be used as "Algorithm IANA maintains a registry of algorithm names to be used as "Algorithm
Names" as defined in Section 4.3. Algorithm names are text strings Names" as defined in Section 4.3. Algorithm names are text strings
encoded using the syntax of a domain name. There is no structure encoded using the syntax of a domain name. There is no structure
required other than names for different algorithms must be unique required other than names for different algorithms must be unique
when compared as DNS names, i.e., comparison is case insensitive. when compared as DNS names, i.e., comparison is case insensitive.
Previous specifications [RFC2845] and [RFC4635] defined values for Previous specifications [RFC2845] and [RFC4635] defined values for
HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an
skipping to change at page 18, line 30 skipping to change at page 18, line 19
the design of MD4. While the results so far should not effect HMAC, the design of MD4. While the results so far should not effect HMAC,
the stronger SHA-1 and SHA-256 algorithms are being made mandatory the stronger SHA-1 and SHA-256 algorithms are being made mandatory
due to caution. Note that today SHA-3 [FIPS202] is available as an due to caution. Note that today SHA-3 [FIPS202] is available as an
alternative to SHA-2 using a very different design. alternative to SHA-2 using a very different design.
See also the Security Considerations section of [RFC2104] from which See also the Security Considerations section of [RFC2104] from which
the limits on truncation in this RFC were taken. the limits on truncation in this RFC were taken.
11.1. Issue fixed in this document 11.1. Issue fixed in this document
To bind an answer with its corresponding request the MAC of the When signing a DNS reply message using TSIG, its MAC computation uses
answer is computed using the MAC request. Unfortunately original the request message's MAC as an input to cryptographically relate the
specifications [RFC2845] failed to clearly require the MAC request to reply to the request. Unfortunately, the original TSIG specification
be successfully validated. [RFC2845] failed to clearly require the request MAC to be
successfully validated before using it.
This document proposes the principle that the MAC must be considered This document proposes the principle that the MAC must be considered
to be invalid until it was validated. This leads to the requirement to be invalid until it was validated. This leads to the requirement
that only a validated request MAC is included in a signed answer. Or that only a validated request MAC is included in a signed answer. Or
with other words when the request MAC was not validated the answer with other words when the request MAC was not validated the answer
must be unsigned with a BADKEY or BADSIG TSIG error. must be unsigned with a BADKEY or BADSIG TSIG error.
11.2. Why not DNSSEC? 11.2. Why not DNSSEC?
This section from the original document [RFC2845] analyzes DNSSEC in This section from the original document [RFC2845] analyzes DNSSEC in
skipping to change at page 23, line 33 skipping to change at page 23, line 18
8. Added Section 6.6.4 about truncation error handling by 8. Added Section 6.6.4 about truncation error handling by
clients. clients.
9. Removed the limit to HMAC output in replies as a request 9. Removed the limit to HMAC output in replies as a request
which specified a MAC length longer than the HMAC output is which specified a MAC length longer than the HMAC output is
invalid according the the first processing rule in invalid according the the first processing rule in
Section 6.5.2. Section 6.5.2.
10. Promoted the requirement that a secret length should be at 10. Promoted the requirement that a secret length should be at
least as long as the keyed message digest to a SHOULD least as long as the HMAC output to a SHOULD [RFC2119] key
[RFC2119] key word. word.
11. Added a short text to explain the security issue. 11. Added a short text to explain the security issue.
draft-dupont-dnsop-rfc2845bis-01
Improved wording (post-publication comments).
Specialized and renamed the "TSIG on TCP connection" (Section 6.4)
to "TSIG on zone tranfer over a TCP connection". Added a SHOULD
for a TSIG in each message (was envelope) for new implementations.
Authors' Addresses Authors' Addresses
Francis Dupont (editor) Francis Dupont (editor)
Internet Software Consortium Internet Software Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
United States United States
Email: Francis.Dupont@fdupont.fr Email: Francis.Dupont@fdupont.fr
Stephen Morris Stephen Morris
Internet Software Consortium Internet Software Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
United States United States
Email: stephen@isc.org Email: stephen@isc.org
URI: http://www.isc.org URI: http://www.isc.org
 End of changes. 58 change blocks. 
158 lines changed or deleted 158 lines changed or added

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