rfc8945v2.txt   rfc8945.txt 
skipping to change at line 251 skipping to change at line 251
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. For example, if hosts A.site.example and B.example.net time. For example, if hosts A.site.example and B.example.net
share a key, possibilities for the key name include share a key, possibilities for the key name include
<id>.A.site.example, <id>.B.example.net, and <id>.A.site.example, <id>.B.example.net, and
<id>.A.site.example.B.example.net. It should be possible for more <id>.A.site.example.B.example.net. It should be possible for more
than one key to be in simultaneous use among a set of interacting than one key to be in simultaneous use among a set of interacting
hosts. This allows for periodic key rotation as per best hosts. This allows for periodic key rotation as per best
operational practices, as well as algorithm agility as indicated operational practices, as well as algorithm agility as indicated
by [BCP201]. by [RFC7696].
The name may be used as a local index to the key involved, but it The name may be used as a local index to the key involved, but it
is recommended that it be globally unique. Where a key is just is recommended that it be globally unique. Where a key is just
shared between two hosts, its name actually need only be shared between two hosts, its name actually need only be
meaningful to them, but it is recommended that the key name be meaningful to them, but it is recommended that the key name be
mnemonic and incorporate the names of participating agents or mnemonic and incorporate the names of participating agents or
resources as suggested above. resources as suggested above.
TYPE: This MUST be TSIG (250: Transaction SIGnature). TYPE: This MUST be TSIG (250: Transaction SIGnature).
skipping to change at line 310 skipping to change at line 310
an unsigned 48-bit integer containing the time the message was an unsigned 48-bit integer containing the time the message was
signed as seconds since 00:00 on 1970-01-01 UTC, ignoring leap signed as seconds since 00:00 on 1970-01-01 UTC, ignoring leap
seconds. seconds.
Fudge: Fudge:
an unsigned 16-bit integer specifying the allowed time difference an unsigned 16-bit integer specifying the allowed time difference
in seconds permitted in the Time Signed field. in seconds permitted in the Time Signed field.
MAC Size: MAC Size:
an unsigned 16-bit integer giving the length of the MAC field in an unsigned 16-bit integer giving the length of the MAC field in
octets. Truncation is indicated by a MAC size less than the size octets. Truncation is indicated by a MAC Size less than the size
of the keyed hash produced by the algorithm specified by the of the keyed hash produced by the algorithm specified by the
Algorithm Name. Algorithm Name.
MAC: MAC:
a sequence of octets whose contents are defined by the TSIG a sequence of octets whose contents are defined by the TSIG
algorithm used, possibly truncated as specified by the MAC Size. algorithm used, possibly truncated as specified by the MAC Size.
The length of this field is given by the Mac size. Calculation of The length of this field is given by the MAC Size. Calculation of
the MAC is detailed in Section 4.3. the MAC is detailed in Section 4.3.
Original ID: Original ID:
an unsigned 16-bit integer holding the message ID of the original an unsigned 16-bit integer holding the message ID of the original
request message. For a TSIG RR on a request, it is set equal to 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 in the DNS message ID. In a TSIG attached to a response -- or in
cases such as the forwarding of a dynamic update request -- the cases such as the forwarding of a dynamic update request -- the
field contains the ID of the original DNS request. field contains the ID of the original DNS request.
Error: Error:
skipping to change at line 347 skipping to change at line 347
will be empty (i.e., Other Len will be zero) unless the content of will be empty (i.e., Other Len will be zero) unless the content of
the Error field is BADTIME, in which case it will be a 48-bit the Error field is BADTIME, in which case it will be a 48-bit
unsigned integer containing the server's current time as the unsigned integer containing the server's current time as the
number of seconds since 00:00 on 1970-01-01 UTC, ignoring leap number of seconds since 00:00 on 1970-01-01 UTC, ignoring leap
seconds (see Section 5.2.3). This document assigns no meaning to seconds (see Section 5.2.3). This document assigns no meaning to
its contents in requests. its contents in requests.
4.3. MAC Computation 4.3. MAC Computation
When generating or verifying the contents of a TSIG record, the data When generating or verifying the contents of a TSIG record, the data
listed in the rest of this section is passed, in the order listed listed in the rest of this section are passed, in the order listed
below, as input to MAC computation. The data are passed in network below, as input to MAC computation. The data are passed in network
byte order or wire format, as appropriate and are fed into the byte order or wire format, as appropriate and are fed into the
hashing function as a continuous octet sequence with no interfield hashing function as a continuous octet sequence with no interfield
separator or padding. separator or padding.
4.3.1. Request MAC 4.3.1. Request MAC
Only included in the computation of a MAC for a response message (or Only included in the computation of a MAC for a response message (or
the first message in a multi-message response), the validated request the first message in a multi-message response), the validated request
MAC MUST be included in the MAC computation. If the request MAC MAC MUST be included in the MAC computation. If the request MAC
skipping to change at line 385 skipping to change at line 385
and subsequent messages in a response that consists of multiple DNS and subsequent messages in a response that consists of multiple DNS
messages (e.g., a zone transfer). These are described in messages (e.g., a zone transfer). These are described in
Section 5.3.1. Section 5.3.1.
4.3.2. DNS Message 4.3.2. DNS Message
In the MAC computation, the whole/complete DNS message in wire format In the MAC computation, the whole/complete DNS message in wire format
is used. is used.
When creating an outgoing message, the TSIG is based on the message When creating an outgoing message, the TSIG is based on the message
before the TSIG RR has been added to the additional section and content before the TSIG RR has been added to the additional section
before the DNS Message Header's ARCOUNT has been incremented to and before the DNS Message Header's ARCOUNT has been incremented to
include the TSIG RR. include the TSIG RR.
When verifying an incoming message, the TSIG is checked against the When verifying an incoming message, the TSIG is checked against the
message after the TSIG RR has been removed, the ARCOUNT decremented, message after the TSIG RR has been removed, the ARCOUNT decremented,
and the message ID replaced by the original message ID from the TSIG and the message ID replaced by the original message ID from the TSIG
if those IDs differ. (This could happen, for example, when if those IDs differ. (This could happen, for example, when
forwarding a dynamic update request.) forwarding a dynamic update request.)
4.3.3. TSIG Variables 4.3.3. TSIG Variables
skipping to change at line 525 skipping to change at line 525
use the truncated value for authentication. HMAC SHA-1 truncated to use the truncated value for authentication. HMAC SHA-1 truncated to
96 bits is an option available in several IETF protocols, including 96 bits is an option available in several IETF protocols, including
IPsec and TLS. However, while this option is kept for backwards IPsec and TLS. However, while this option is kept for backwards
compatibility, it may not provide a security level appropriate for compatibility, it may not provide a security level appropriate for
all cases in the modern environment. In these cases, it is all cases in the modern environment. In these cases, it is
preferable to use a hashing algorithm such as SHA-256-128, SHA- preferable to use a hashing algorithm such as SHA-256-128, SHA-
384-192, or SHA-512-256 [RFC4868]. 384-192, or SHA-512-256 [RFC4868].
Processing of a truncated MAC follows these rules: Processing of a truncated MAC follows these rules:
If the MAC Size field is greater than keyed hash output length: This If the MAC Size field is greater than the keyed hash output
case MUST NOT be generated and, if received, MUST cause the DNS length: This case MUST NOT be generated and, if received, MUST cause
message to be dropped and RCODE 1 (FORMERR) to be returned. the DNS message to be dropped and RCODE 1 (FORMERR) to be
returned.
If the MAC Size field equals the keyed hash output length: The If the MAC Size field equals the keyed hash output length: The
entire keyed hash output is present and used. entire keyed hash output is present and used.
If the MAC Size field is less than the larger of 10 (octets) and If the MAC Size field is less than the larger of 10 (octets) and
half the length of the hash function in use: With the exception of half the length of the hash function in use: With the exception of
certain TSIG error messages described in Section 5.3.2, where it certain TSIG error messages described in Section 5.3.2, where it
is permitted that the MAC Size be zero, this case MUST NOT be is permitted that the MAC Size be zero, this case MUST NOT be
generated and, if received, MUST cause the DNS message to be generated and, if received, MUST cause the DNS message to be
dropped and RCODE 1 (FORMERR) to be returned. dropped and RCODE 1 (FORMERR) to be returned.
skipping to change at line 657 skipping to change at line 658
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
exact behavior is not specified). exact behavior is not specified).
5.3.2. Generation of TSIG on Error Returns 5.3.2. Generation of TSIG on Error Returns
When a server detects an error relating to the key or MAC in the When a server detects an error relating to the key or MAC in the
incoming request, the server SHOULD send back an unsigned error incoming request, the server SHOULD send back an unsigned error
message (MAC size == 0 and empty MAC). It MUST NOT send back a message (MAC Size == 0 and empty MAC). It MUST NOT send back a
signed error message. signed error message.
If an error is detected relating to the TSIG validity period or the 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 back a MAC is too short for the local policy, the server SHOULD send back a
signed error message. The digest components are: 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)
skipping to change at line 837 skipping to change at line 838
truncation than the minimum strength required by the policy. truncation than the minimum strength required by the policy.
8. Shared Secrets 8. Shared Secrets
Secret keys are very sensitive information and all available steps Secret keys are very sensitive information and all available steps
should be taken to protect them on every host on which they are should be taken to protect them on every host on which they are
stored. Generally, such hosts need to be physically protected. If stored. Generally, such hosts need to be physically protected. If
they are multi-user machines, great care should be taken so that 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 able often run unprivileged, which means all users of a host would be able
to see whatever configuration data is used by the resolver. to see whatever configuration data are used by the resolver.
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 [RFC2136], which otherwise depends on clients to communicate only
with a zone's authoritative name servers. with 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
skipping to change at line 986 skipping to change at line 987
expensive public key cryptography and complex authentication logic. expensive public key cryptography and complex authentication logic.
Secure Domain Name System Dynamic Update ([RFC3007]) describes how Secure Domain Name System Dynamic Update ([RFC3007]) describes how
different keys are used in dynamically updated zones. different keys are used in dynamically updated zones.
11. References 11. References
11.1. Normative References 11.1. Normative References
[FIPS180-4] [FIPS180-4]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, DOI DOI Hash Standard (SHS)", FIPS PUB 180-4,
10.6028/NIST.FIPS.180-4, August 2015, <https://doi.org/DOI DOI 10.6028/NIST.FIPS.180-4, August 2015,
10.6028/NIST.FIPS.180-4>. <https://doi.org/10.6028/NIST.FIPS.180-4>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at line 1023 skipping to change at line 1024
Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
RFC 4635, DOI 10.17487/RFC4635, August 2006, RFC 4635, DOI 10.17487/RFC4635, August 2006,
<https://www.rfc-editor.org/info/rfc4635>. <https://www.rfc-editor.org/info/rfc4635>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[BCP201] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>.
[CVE-2017-11104] [CVE-2017-11104]
Common Vulnerabilities and Exposures, "CVE-2017-11104: Common Vulnerabilities and Exposures, "CVE-2017-11104:
Improper TSIG validity period check can allow TSIG Improper TSIG validity period check can allow TSIG
forgery", June 2017, <https://cve.mitre.org/cgi-bin/ forgery", June 2017, <https://cve.mitre.org/cgi-bin/
cvename.cgi?name=CVE-2017-11104>. cvename.cgi?name=CVE-2017-11104>.
[CVE-2017-3142] [CVE-2017-3142]
Common Vulnerabilities and Exposures, "CVE-2017-3142: An Common Vulnerabilities and Exposures, "CVE-2017-3142: An
error in TSIG authentication can permit unauthorized zone error in TSIG authentication can permit unauthorized zone
transfers", June 2017, <https://cve.mitre.org/cgi-bin/ transfers", June 2017, <https://cve.mitre.org/cgi-bin/
skipping to change at line 1129 skipping to change at line 1125
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>. April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[SHA1SHAMBLES] [SHA1SHAMBLES]
Leurent, G. and T. Peyrin, "SHA-1 is a Shambles", January Leurent, G. and T. Peyrin, "SHA-1 is a Shambles", January
2020, <https://eprint.iacr.org/2020/014.pdf>. 2020, <https://eprint.iacr.org/2020/014.pdf>.
Acknowledgements Acknowledgements
 End of changes. 11 change blocks. 
19 lines changed or deleted 20 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/