draft-ietf-dnsext-tkey-02.txt   draft-ietf-dnsext-tkey-03.txt 
DNSEXT Working Group Donald E. Eastlake, 3rd DNSEXT Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT Motorola INTERNET-DRAFT Motorola
Expires: October 2000 April 2000 Expires: December 2000 June 2000
Secret Key Establishment for DNS (TKEY RR) Secret Key Establishment for DNS (TKEY RR)
------ --- ------------- --- --- ----- --- ------ --- ------------- --- --- ----- ---
<draft-ietf-dnsext-tkey-02.txt> <draft-ietf-dnsext-tkey-03.txt>
Status of This Document Status of This Document
This draft is intended to be become a Proposed Standard RFC. This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the DNS working group mailing list <namedroppers@ops.ietf.org> or to the DNS working group mailing list <namedroppers@ops.ietf.org> or
to the author. to the author.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months. Internet-Drafts may be updated, replaced, or obsoleted by and may be updated, replaced, or obsoleted by other documents at any
other documents at any time. It is not appropriate to use Internet- time. It is inappropriate to use Internet- Drafts as reference
Drafts as reference material or to cite them other than as a material or to cite them other than as "work in progress."
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
[draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating [draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating
skipping to change at page 2, line 26 skipping to change at page 2, line 26
The comments and ideas of the following persons (listed in alphabetic The comments and ideas of the following persons (listed in alphabetic
order) have been incorporated herein and are gratefully acknowledged: order) have been incorporated herein and are gratefully acknowledged:
Olafur Gudmundsson (TIS) Olafur Gudmundsson (TIS)
Stuart Kwan (Microsoft) Stuart Kwan (Microsoft)
Ed Lewis (TIS) Ed Lewis (TIS)
Brian Wellington (TIS) Erik Nordmark (SUN)
Brian Wellington (Nominum)
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................2 Abstract...................................................2
Acknowledgments............................................2 Acknowledgments............................................2
Table of Contents..........................................3 Table of Contents..........................................3
skipping to change at page 12, line 43 skipping to change at page 12, line 43
The resolver KEY RR MUST be authenticated, through the authentication The resolver KEY RR MUST be authenticated, through the authentication
of this query with a TSIG or SIG(0) or the signing of the resolver of this query with a TSIG or SIG(0) or the signing of the resolver
KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY
for which they know the private key, and thereby the attacker could for which they know the private key, and thereby the attacker could
obtain a valid shared secret key from the server. obtain a valid shared secret key from the server.
4.5 Query for Resolver Assigned Keying 4.5 Query for Resolver Assigned Keying
Optionally, a server can accept resolver assigned keys. The keying Optionally, a server can accept resolver assigned keys. The keying
material must be encrypted under a server key for protection in material MUST be encrypted under a server key for protection in
transmission as described in Section 6. transmission as described in Section 6.
The resolver sends a TKEY query with a TKEY RR that specifies the The resolver sends a TKEY query with a TKEY RR that specifies the
encrypted keying material and a KEY RR specifying the server public encrypted keying material and a KEY RR specifying the server public
key used to encrypt the data, both in the additional information key used to encrypt the data, both in the additional information
section. The name of the key and the keying data are completely section. The name of the key and the keying data are completely
controlled by the sending resolver so a globally unique key name controlled by the sending resolver so a globally unique key name
SHOULD be used. The KEY RR used MUST be one for which the server has SHOULD be used. The KEY RR used MUST be one for which the server has
the corresponding private key, or it will not be able to decrypt the the corresponding private key, or it will not be able to decrypt the
keying material and will return a FORMERR, and for which no untrusted keying material and will return a FORMERR. It is also important that
party (preferably no other party than the server) has the private no untrusted party (preferably no other party than the server) has
key, or the untrusted private key holder can capture the messages to the private key corresponding to the KEY RR because, if they do, they
the server, learn the shared secret, and spoof valid TSIGs. can capture the messages to the server, learn the shared secret, and
spoof valid TSIGs.
The query TKEY RR inception and expiry give the time period the The query TKEY RR inception and expiry give the time period the
querier intends to consider the keying material valid. The server querier intends to consider the keying material valid. The server
can return a lesser time interval to advise that it will not maintain can return a lesser time interval to advise that it will not maintain
state for that long and can pre-expire keys in any case. state for that long and can pre-expire keys in any case.
This mode of query MUST be authenticated with a TSIG or SIG(0). This mode of query MUST be authenticated with a TSIG or SIG(0).
Otherwise, an attacker can forge a resolver assigned TKEY query, and Otherwise, an attacker can forge a resolver assigned TKEY query, and
thereby the attacker could specify a shared secret key that would be thereby the attacker could specify a shared secret key that would be
accepted, used, and honored by the server. accepted, used, and honored by the server.
skipping to change at page 13, line 43 skipping to change at page 13, line 44
A server can optionally tell a client that it has deleted a secret A server can optionally tell a client that it has deleted a secret
key by spontaneously including a TKEY RR in the additional key by spontaneously including a TKEY RR in the additional
information section of a response with the key's name and specifying information section of a response with the key's name and specifying
the key deletion mode. Such a response SHOULD be authenticated. If the key deletion mode. Such a response SHOULD be authenticated. If
authenticated, it "deletes" the key with the given name. The authenticated, it "deletes" the key with the given name. The
inception and expiry times of the delete TKEY RR are ignored. Failure inception and expiry times of the delete TKEY RR are ignored. Failure
by a client to receive or properly process such additional by a client to receive or properly process such additional
information in a response would mean that the client might use a key information in a response would mean that the client might use a key
that the server had discarded and would then get an error indication. that the server had discarded and would then get an error indication.
For server assigned and Diffie-Hellman keys, the client must truly For server assigned and Diffie-Hellman keys, the client MUST
"discard" all active state associated with the key. For querier "discard" active state associated with the key. For querier assigned
assigned keys, the querier MAY simply mark the key as no longer keys, the querier MAY simply mark the key as no longer retained by
retained by the server and may re-send it in a future query the server and may re-send it in a future query specifying querier
specifying querier assigned keying material. assigned keying material.
6. Methods of Encryption 6. Methods of Encryption
For the server assigned and resolver assigned key agreement modes, For the server assigned and resolver assigned key agreement modes,
the keying material is sent within the key data field of a TKEY RR the keying material is sent within the key data field of a TKEY RR
encrypted under the public key in an accompanying KEY RR [RFC 2535]. encrypted under the public key in an accompanying KEY RR [RFC 2535].
This KEY RR MUST be for a public key algorithm where the public and This KEY RR MUST be for a public key algorithm where the public and
private keys can be used for encryption and the corresponding private keys can be used for encryption and the corresponding
decryption which recovers the originally encrypted data. The KEY RR decryption which recovers the originally encrypted data. The KEY RR
SHOULD correspond to a name for the decrypting resolver/server such SHOULD correspond to a name for the decrypting resolver/server such
skipping to change at page 14, line 49 skipping to change at page 14, line 49
consideration should be given before the allocation of meaning for consideration should be given before the allocation of meaning for
Mode field values 0x0000 and 0xFFFF. Mode field values 0x0000 and 0xFFFF.
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
are allocated by IESG approval or IETF consensus. are allocated by IESG approval or IETF consensus.
Mode field values 0x1000 through 0xEFFF are allocated based on Mode field values 0x1000 through 0xEFFF are allocated based on
Specification Required as defined in [RFC 2434]. Specification Required as defined in [RFC 2434].
Mode values should not be changed when the status of their use Mode values should not be changed when the status of their use
changes. For example, a mode value assigned for an Experimental changes. For example, a mode value assigned based just on providing
Standard should not be changed later just because that standard's a specification should not be changed later just because that use's
status is changed to Proposed. status is changed to standards track.
The following assignments are documented herein: The following assignments are documented herein:
RR Type 249 for TKEY. RR Type 249 for TKEY.
TKEY Modes 1 through 5 as listed in section 2.5. TKEY Modes 1 through 5 as listed in section 2.5.
Extended RCODE Error values of 19, 20, and 21 as listed in Extended RCODE Error values of 19, 20, and 21 as listed in
section 2.6. section 2.6.
skipping to change at page 17, line 9 skipping to change at page 17, line 9
RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", March 1999. Name System (DNS)", March 1999.
draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D. draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Motorola
65 Shindegan Hill Road, RR #1 140 Forest Avenue
Carmel, NY 10512 USA Hudson, MA 01749 USA
Telephone: +1 914-276-2668 (h) Telephone: +1 978-562-2827 (h)
+1 508-261-5434 (w) +1 508-261-5434 (w)
FAX: +1 508-261-4447 (w) FAX: +1 978-567-7941 (h)
+1 508-261-4447 (w)
email: Donald.Eastlake@motorola.com email: Donald.Eastlake@motorola.com
Expiration and File Name Expiration and File Name
This draft expires October 2000. This draft expires December 2000.
Its file name is draft-ietf-dnsext-tkey-02.txt. Its file name is draft-ietf-dnsext-tkey-03.txt.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/