Network Working Group S. Rose
Internet-Draft NIST
Expires: February 4, 2004 August 6, 2003
DNS Request and Transaction Signatures ( SIG(0)s )
draft-srose-rfc2931bis-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 4, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Extensions to the Domain Name System (DNS) can provide data origin
and transaction integrity and authentication to security aware
resolvers and applications through the use of cryptographic digital
signatures. However, these security extensions do not provide
authentication at the transaction or message level. This document
describes a message authentication scheme (called SIG(0)) that
provides message level authentication and integrity checking by means
of a meta-RR in the additional section of a DNS message.
Rose Expires February 4, 2004 [Page 1]
Internet-Draft rfc2931bis August 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SIG(0) Design Rationale . . . . . . . . . . . . . . . . . . . 4
2.1 Message Authentication . . . . . . . . . . . . . . . . . . . . 4
2.2 Request Authentication . . . . . . . . . . . . . . . . . . . . 4
2.3 Keying . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Differences Between TSIG and SIG(0) . . . . . . . . . . . . . 6
4. The SIG(0) Resource Record . . . . . . . . . . . . . . . . . . 7
4.1 SIG(0) Lifetime and Expiration . . . . . . . . . . . . . . . . 8
4.2 Calculating Request and Transaction SIG(0)s . . . . . . . . . 8
4.3 Inclusion of SIG(0) RR in a DNS Message . . . . . . . . . . . 9
4.4 Processing Responses and SIG(0) RRs . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
Nornative References . . . . . . . . . . . . . . . . . . . . . 13
Informative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
Rose Expires February 4, 2004 [Page 2]
Internet-Draft rfc2931bis August 2003
1. Introduction
intro
It is assumed that the reader has some knowledge of the DNSSEC
extensions ([6], [7], and [8]) The key words "MUST", "MUST NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119 [2].
Rose Expires February 4, 2004 [Page 3]
Internet-Draft rfc2931bis August 2003
2. SIG(0) Design Rationale
SIG(0) provides protection for DNS transactions and requests that is
not provided by the regular RRSIG, DNSKEY, and NSEC RRs specified in
[7]. These services do not cover glue records, DNS message headers,
the query section of DNS requests, and do not provide protection of
the overall integrity of a DNS message. The RRSIG RR is used to
authenticate data resource records (RRs) or authenticatably deny
their nonexistence. The SIG(0) RR is a variant of the RRSIG RR that
covers the entire DNS message. This would give the same protection
levels to the DNS message headers and query section as the RRSIG RR
gives to a data RR set.
2.1 Message Authentication
Message authentication means that a requester can be sure it is at
least getting the messages from the server it queried and that the
received messages have not be tampered with in transit. This is
accomplished by optionally adding either a TSIG RR [3] or, a SIG(0)
RR at the end of the message which digitally signs the concatenation
of the server's response and the corresponding resolver query.
2.2 Request Authentication
Queries and update messages can be authenticated by including a TSIG
or a SIG(0) RR at the end of the request. There is little need to
authenticate a traditional DNS query, although it may be desired for
dynamic updates to a zone, or to provide proof of the identity. In
the latter, message authentication may be used as a form of
indentification. The presence of a SIG(0) may allow certain access
based on the capability of providing a SIG(0) signature. Due to the
cost associated with generating a SIG(0) RR, this ability should not
be used for general purpose DNS lookups.
Requests with a non- empty additional information section produce
error returns or may even be ignored by a few such older DNS servers.
However, this syntax for signing requests is defined to be used for
authenticating dynamic update requests [5], TKEY requests [4], or
possible future requests requiring authentication.
2.3 Keying
The private keys used in transaction authentication belong to the
entitiy composing the DNS message, not to the zone involved. Request
authentication may also involve the private key of the host or other
entity depending on the request authority seeking to be established.
The corresponding public key(s) are normally stored in and retrieved
from the DNS for verification as KEY RRs with a protocol byte of 3
Rose Expires February 4, 2004 [Page 4]
Internet-Draft rfc2931bis August 2003
(DNSSEC).
Rose Expires February 4, 2004 [Page 5]
Internet-Draft rfc2931bis August 2003
3. Differences Between TSIG and SIG(0)
There are significant differences between TSIG and SIG(0).
Because TSIG involves secret keys installed at both the requester and
server the presence of such a key implies that the other party
understands TSIG and very likely has the same key installed.
Furthermore, TSIG uses keyed hash authentication codes which are
relatively inexpensive to compute. Thus it is common to authenticate
requests with TSIG and responses are authenticated with TSIG if the
corresponding request is authenticated.
SIG(0) on the other hand, uses public key authentication, where the
public keys are stored in DNS as KEY RRs and a private key is stored
at the signer. Existence of such a KEY RR does not necessarily imply
implementation of SIG(0). In addition, SIG(0) involves relatively
expensive public key cryptographic operations that should be
minimized and the verification of a SIG(0) involves obtaining and
verifying the corresponding KEY which can be an expensive and lengthy
operation. Indeed, a policy of using SIG(0) on all requests and
verifying it before responding would, for some configurations, lead
to a deadly embrace with the attempt to obtain and verify the KEY
needed to authenticate the request SIG(0) resulting in additional
requests accompanied by a SIG(0) leading to further requests
accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not
required on requests halves the number of public key operations
required by the transaction.
For these reasons, SIG(0)s SHOULD only be used on requests when
necessary to authenticate that the requester has some required
privilege or identity. SIG(0)s on replies are defined in such a way
as to not require a SIG(0) on the corresponding request and still
provide transaction protection. For other replies, whether they are
authenticated by the server or required to be authenticated by the
requester SHOULD be a local configuration option.
Rose Expires February 4, 2004 [Page 6]
Internet-Draft rfc2931bis August 2003
4. The SIG(0) Resource Record
Note: requests and responses can either have a single TSIG or one
SIG(0) but not both a TSIG and a SIG(0).
The structure of the SIG(0) resource records (RRs) is similar to the
RRSIG RR [7] with the following differences outlined below. Any
conflict between the DNSSEC specification and this document
concerning SIG(0) RRs should be resolved in favor of this document.
The owner's name of a SIG(0) MUST be the root. That is, a single
zero (0) octet. Likewise, the class code MUST be ANY and TTL value
MUST be zero (0).
The type code for the SIG(0) is 24.
The RDATA of the SIG(0) is given as:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fixed sized resevered sections MUST be zero (0).
The Algorithm field is described in Section 6.
The Labels and Key Tag field are constructed the same way as the
same filds in the RRSIG RR. See [7]. Since the owner name of the
SIG(0) is zero, the labels field MUST also be zero (0).
For all SIG(0)s, the signer name field MUST be a name of the
originating host and there MUST be a KEY RR at that name with the
Rose Expires February 4, 2004 [Page 7]
Internet-Draft rfc2931bis August 2003
public key corresponding to the private key used to calculate the
signature. (The host domain name used may be the inverse IP
address mapping name for an IP address of the host if the relevant
KEY is stored there.)
4.1 SIG(0) Lifetime and Expiration
The inception and expiration times in SIG(0)s are for the purpose of
resisting replay attacks. They should be set to form a time bracket
such that messages outside that bracket can be ignored. In IP
networks, this time bracket should not normally extend further than 5
minutes into the past and 5 minutes into the future.
4.2 Calculating Request and Transaction SIG(0)s
A DNS query message signed with a SIG(0) places the RR at the end of
the additional section. The signature is calculated by using a
plaintext (see [7]) of (1) the SIG(0)'s RDATA entirely omitting the
signature section itself (19 bytes), (2) the entire DNS message minus
the UDP/IP header. The additional section RR count in the DNS
message header should NOT include the SIG(0) itself.
That is:
plaintext = RDATA | DNSquery - SIG(0)
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated omitting the signature field itself.
Similarly, a SIG(0) used to secure a response are calculated by using
a plaintext of (1) the SIG(0) RDATA omitting the signature itself
(again, 19 bytes), (2) the entire DNS query message that produced
this response, but not its UDP/IP header, and (3) the entire DNS
response message, but not the UDP/IP header. Again, like the query
message, the additional section RR counts do not reflect the the
SIG(0) RR itself.
That is
plaintext = RDATA | full query | response - SIG(0)
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated.
Verification of a response SIG(0) (which is signed by the server host
key, not the zone key) by the requesting resolver shows that the
query and response were not tampered with in transit, that the
Rose Expires February 4, 2004 [Page 8]
Internet-Draft rfc2931bis August 2003
response corresponds to the intended query, and that the original
response comes from the queried server.
In the case of a DNS message via TCP, a SIG(0) on the first data
packet is calculated with "data" as above and for each subsequent
packet, it is calculated as follows:
data = RDATA | DNS payload - SIG(0) | previous packet
where "|" is concatenations, RDATA is as above, and previous packet
is the previous DNS payload including DNS header and the SIG(0) but
not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an
alternative, TSIG may be used after, if necessary, setting up a key
with TKEY [4].
Except where needed to authenticate an update, TKEY, or similar
privileged request, servers are not required to check for a request
SIG(0).
4.3 Inclusion of SIG(0) RR in a DNS Message
When SIG(0) authentication on a response is desired, that SIG RR MUST
be considered the highest priority of any additional information for
inclusion in the response. If the SIG(0) RR cannot be added without
causing the message to be truncated, the server MUST alter the
response so that a SIG(0) can be included. This response consists of
only the question and a SIG(0) record, and has the TC bit set and
RCODE 0 (NOERROR). The client should retry the request using TCP.
4.4 Processing Responses and SIG(0) RRs
A SIG(0) SHOULD be placed as the last RR in the additional section of
a DNS message. If it is located in any other section, it MUST NOT be
considered valid. For TKEY responses, it MUST be checked and the
message rejected if the checks fail unless otherwise specified for
the TKEY mode in use. For all other responses, it MAY be checked and
the message rejected if the checks fail.
If a response's SIG(0) check succeed, such a transaction
authentication signature does NOT directly authenticate the validity
any data-RRs in the message. However, it authenticates that they
were sent by the queried server and have not been altered. (Only a
proper SIG(0) RR signed by the zone or a key tracing its authority to
the zone or to static resolver configuration can directly
authenticate data-RRs, depending on resolver policy.) If a resolver
or server does not plan to implement transaction and/or request
SIG(0), it MUST ignore them without error where they are optional and
treat them as failing where they are required.
Rose Expires February 4, 2004 [Page 9]
Internet-Draft rfc2931bis August 2003
5. Security Considerations
A more detailed description of the threats against the DNS are given
in [9].
Because requests and replies are highly variable, message
authentication SIGs can not be pre-calculated. Thus it will be
necessary to keep the private key on-line. This will cause the DNS
entity to rely on the system security for keeping the key secure.
The inclusion of the SIG(0) inception and expiration time under the
signature improves resistance to replay attacks. The benefit of
using private and public key pairs allows for the distribution of the
public verification key while keeping the private signing key secure.
This is an advantage of SIG(0) message authentication schemes over
the TSIG RR schemes, which use a shared secret that must be
distributed securely.
SIG(0) signature scheme cannot be used to authenticate source data,
only to authenticate a resolver request and/or a server response.
The DNS security mechanisms described in [7] should be used to
provide coverage of the original source data.
Rose Expires February 4, 2004 [Page 10]
Internet-Draft rfc2931bis August 2003
6. IANA Considerations
In order to allow DNS Security and SIG(0) to use different sets of
algorithms, the existing "DNS Security Algorithm Numbers" registry is
renamed as the "SIG(0) Algorithm Numbers" registry and a new "DNS
Security Algorithm Numbers" registry is established. The initial
algorithm values are:
VALUE Algorithm [mnemonic] RFC
0 Reserved -
1 Reserved (Obsolete) RFC 2537
2 Diffie-Hellman [DH] RFC 2539
3 DSA [DSA] RFC 2536
4 available for assignment
5 RSA/SHA1 [RSA/SHA1] RFC 3110
6-252 available for assignment -
253 private [PRIVATE_DNS] -
254 private [PRIVATE_OID] -
255 reserved -
As support for SIG(0) is not mandatory to the DNS protocol, there are
no mandatory to implement algorithms for SIG(0). It is suggested,
but not required, that new algorithms usable by both DNS Security and
SIG(0) be assigned the same number in both registries.
Rose Expires February 4, 2004 [Page 11]
Internet-Draft rfc2931bis August 2003
7. Acknowledgements
The author would like to acknowledge the author of the original
SIG(0) draft, Donald Eastlake, as well as the express graditude for
those that helped prod the author into producing this draft.
Rose Expires February 4, 2004 [Page 12]
Internet-Draft rfc2931bis August 2003
Nornative References
[1] Elz, R. and R. Bush, "Serial Number Arithmatic", RFC 1982,
August 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[4] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000.
[5] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
Rose Expires February 4, 2004 [Page 13]
Internet-Draft rfc2931bis August 2003
Informative References
[6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"DNS Security Introduction and Requirements", draft-ietf-dnsext-
dnssec-intro-05 (work in progress), February 2003.
[7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Resource Records for DNS Security Extensions", draft-ietf-
dnsext-dnssec-records-04 (work in progress), February 2003.
[8] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Protocol Modifications for the DNS Security Extensions", draft-
ietf-dnsext-dnssec-protocol-00 (work in progress), Februari
2003.
[9] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
System", draft-ietf-dnsext-dns-threats-02 (work in progress),
November 2002.
Author's Address
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov
Rose Expires February 4, 2004 [Page 14]
Internet-Draft rfc2931bis August 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rose Expires February 4, 2004 [Page 15]