One document matched: draft-ietf-dnsind-tsig-00.txt
DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Olafur Gudmundsson (TIS)
<draft-ietf-dnsind-tsig-00.txt> September 1996
Amends: RFC 1035
Simple Transaction Signature for DNS
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This protocol allows for transaction level authentication using
shared secrets and one way hashing. It can be used to authenticate
dynamic updates as coming from an approved client, or to authenticate
responses as coming from an approved caching/forwarding name server.
No provision has been made here for distributing the shared secrets;
it is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism such as
sneaker-net.
Expires March 1997 [Page 1]
INTERNET-DRAFT DNS TSIG September 1996
1 - Motivation
1.1. [DNSSEC] creates a framework for authenticating DNS data by DNS
Resolvers and servers. To do this securely a chain of trusted Keys must
be constructed to a Key that is unconditionally trusted (preconfigured).
For expediency nameservers will store large caches of KEYs. If a name
server does not have a KEY that it needs to authenticate RRs in an
incoming message, it must query for that KEY before it can pass the
original data on as secure.
1.2, Common DNS implementations use ``stub'' resolvers, which do not
have caches. Thus it is impractical in most cases for resolvers to
perform [DNSSEC] authentication. To overcome this problem, [DNSSEC]
includes Transaction Signatures. Unfortunately, Transaction Signatures
with the RSA algorithm are expensive to generate, and [DNSSEC]'s RR
format is difficult to encode and decode. A cheaper and necessarily
less secure way of performing transaction authentication is required.
This document specifies a standard inexpensive transaction signature for
use in certain cases.
1.3. There are two main requirements for this. In [UPDATE], messages
may originate from hosts that do not support encryption. It is a
terrible idea to allow clients to update DNS servers without any
authentication. The second requirement is to allow resolvers to
authenticate the response they got from a local query came from a
trusted server.
1.4. The mechanism proposed here uses shared secret keys to establish
trust relationship between two entities. This key must be protected or
anyone can mascarade one of the parties. [DNSSEC] transaction
signatures are much stronger and as [DNSSEC] uses Public/Private KEY
algorithms the Public KEY can be advertised. There is a urgent need to
provide some authentication between clients and local servers. This
proposal is unsuitable for server to server authentication, due to the
fact that resolvers on user machines only talk to few local servers.
Servers on the other hand talk to many other servers. A server acting
as a caching resolver -- a ``slave forwarder'' in common usage -- might
use transaction signatures when communicating with its small number of
preconfigured ``upstream'' servers.
Expires March 1997 [Page 2]
INTERNET-DRAFT DNS TSIG September 1996
2 - TSIG RR Format
2.1. To provide the authentication between server and client, we use a
new RR type whose mnuemonic is TSIG, and whose type code is UNASSIGNED.
TSIG RRs can be used for authenticating a previously established context
between the clients and servers who are supplied with and configured to
use a shared secret key.
2.2. As the TSIG RRs are related to one DNS query/response there is no
value in storing or retransmitting them, thus the TSIG RR should be
discarded once it has been used to authenticate DNS packet. The only
Message Digest algorithm specified in this document is "MD5" (see
[MD5]). Other algorithms can be specified at later date. Names and
definitions of new algorithms must be registered with IANA.
2.3. The TSIG RR has the same syntax as the TXT RR (see [RFC1034
3.3.14]), with each <character-string> treated as a field, with
boundaries between <character-string>s being significant, and with at
least one field always present.
NAME The owner name of the TSIG RR is the name of the shared
secret, which allows a resolver to use a different secret for
each of its recursive name servers, and allows a server to
know different secrets for each of its client resolvers. This
owner name is not registered in the Domain Name System.
TYPE TSIG (Transaction SIGnature).
CLASS expiration (offset from "now"), in seconds; set to estimate of
RTT + fudge.
TTL "now" (time since 1 Jan 1970, 00:00 UTC, 32 bit unsigned), in
seconds.
RDATA As for TXT RR, with each <character-string> treated as a
field. The first field is the algorythm name, e.g., "MD5".
The second and following fields are the Message Digest in
Base64 encoding (see [RFC1521 5.2]).
2.4. Note that the Message Digest is represented by all TXT subparts
after the first. It is possible that the Message Digest will be empty,
or will be representable with one (1) <character-string>, or will be
represented by many <character-string>s. In either case, <character-
string> ordering and boundaries can be significant and must be stable
during storage and forwarding, even across internal program APIs.
Expires March 1997 [Page 3]
INTERNET-DRAFT DNS TSIG September 1996
3 - HMAC-MD5 Details
3.1. There are some concerns about the strength of MD5. To make MD5
more secure, the HMAC mechanism has been proposed. This draft specifies
the use of the HMAC mechanism (see [HMAC]). The HMAC operation is:
MD5( K xor OPAD, MD5( K xor IPAD, DNSDATA))
K The KEY used or a message digest of the key if the key is
longer than 64 bytes. The key is padded to 64 bytes by
appending the NUL bytes (0x00) as needed.
IPAD A 64 byte string with the value 0x36 in each byte.
OPAD A 64 byte string with the value 0x5C in each byte.
DNSDATA The data the whole outgoing DNS packet in wire format,
before the TSIG RR has been added to the additional data
section and before the DNS Message Header's ARCOUNT field
has been incremented to contain the TSIG RR.
4 - Message Digest Operation
4.1. Once the outgoing packet has been constructed, the message digest
operation can be performed. The resulting message digest will then be
stored in a TSIG which is appended to the additional data section.
Appending a Transaction signature to an DNS transaction is not allowed
to result in a truncated response, TCP connection must be used to
prevent the truncation.
4.2. Upon receipt of a packet with a TSIG RR, 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 this point the message digest
operation is performed. If the algorythm name or key name is unknown to
the recipient, or if the message digests do not match, the whole DNS
Message must be discarded and a response with RCODE 5 (REFUSED) should
be sent back to the sender. A message to the system operations log
ought to be generated in this case, to warn the operations staff of a
possible security incident in progress.
Expires March 1997 [Page 4]
INTERNET-DRAFT DNS TSIG September 1996
5 - Protocol Details
5.1. Client performs the message digest operation and appends TSIG to
additional data section and transmits query to server. The client must
store the message digest from the query while waiting for an answer.
Note that some older name servers will not accept queries with a
nonempty additional data section, but clients will only attempt signed
transactions against servers who are known to support TSIG and to share
some secret key.
5.2. Upon receipt of a QUERY, server will check if there is a TSIG RR,
if one exists, it requires the server to return a TSIG RR in the
response. If the query TSIG does not validate, the server responds with
RCODE 5 (REFUSED) if OPCODE is 0 (QUERY) or RCODE 9 (NOTAUTH) if the
opcode is 5 (UPDATE).
5.3. When server has generated a response, it calculates the a digest.
The DNSSDATA in this case is:
message digest from query | dnsANSWER
TSIG is appended and the response is sent. The inclusion of the message
digest from the query binds the response to the initiating request.
5.4. When a client receives a response from a server it expects a TSIG
from, it first checks if the TSIG RR is present in the reply, if not the
reply is treated as having a format error. Client performs the TSIG
adjustment and calculates the message digest over:
message digest from query | dnsANSWER
5.5. This protocol allows client and server to share multiple secrets,
if server rejects a particular secret by sending back either REFUSED or
NOTAUTH the client can either try the next secret, or give up on this
server.
Expires March 1997 [Page 5]
INTERNET-DRAFT DNS TSIG September 1996
6 - Storage of Shared Secrets
6.1. Resolvers usually run unprivileged, which means all users of a host
will usually be able to see whatever configuration data is used by the
resolver. This presents a problem in that the shared secrets probably
ought not to be visible to anyone except the network or system manager.
In the absence of a Public Key Algorythm, there is no way to make the
resolver's share secrets secure.
6.2. A name server usually runs privileged, which means its
configuration data need not be visible to all users of the host. For
this reason, a host that implements transaction signatures should
probably be configured with a ``stub resolver'' and a local
``caching/forwarding name server.'' This presents a special problem for
[UPDATE] which otherwise depends on clients to communicate only with a
zone's authoritative name servers.
7 - Security Considerations
The approach specified here is weaker than an RSA/MD5 transaction
signature, but this approach is computationally much less expensive,
easier to implement and easier to configure. MD5 implementations are
common and are not restricted anywhere in the world, unlike RSA. The
main goal here is to provide protection of DNSDATA on the last hop from
the local name server to the user resolver. The authentication provided
here is better than nothing and allows protection against some attacks,
as long as the shared secret key is not compromised.
Secret keys should be changed periodically. If client host has been
broken into, server should suspend the use of all secrets known to that
client. If possible, secrets should be stored in encrypted form.
Secrets should never be transmitted in the clear over any wire. This
draft does not address the issue on how to distribute and store secrets.
One vulnerability is that someone may find a way to calculate the shared
secret key given enough data.
Expires March 1997 [Page 6]
INTERNET-DRAFT DNS TSIG September 1996
8 - References
[RFC1321] Rivest, R., ``The MD5 Message-Digest Algorithm,'' RFC 1321,
MIT LCS & RSA Data Security, Inc., April 1992.
[RFC1521] N. Borenstein, N. Freed, ``MIME (Multipurpose Internet Mail
Extensions) Part One,'' RFC 1521, Bellcore & Innosoft,
September 1993.
[HMAC] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5
for Message Authentication,'' draft-ietf-ipsec-hmac-
md5-00.txt, March, 1996.
9 - Author's Addresses
Paul Vixie Olafur Gudmundsson
Internet Software Consortium Trusted Information Systems
Star Route Box 159A 3060 Washington Road, Route 97
Woodside, CA 94062 Glenwood, MD 21738
+1 415 747 0204 +1 301 854 6889
<paul@vix.com> <ogud@tis.com>
Expires March 1997 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 11:28:37 |