draft-ietf-dnsext-tkey-renewal-mode-04.txt   draft-ietf-dnsext-tkey-renewal-mode-05.txt 
DNSEXT Working Group Yuji Kamite DNS Extensions Yuji Kamite
INTERNET-DRAFT NTT Communications Internet-Draft NTT Communications
<draft-ietf-dnsext-tkey-renewal-mode-04.txt> Masaya Nakayama Expires: April 15, 2005 Masaya Nakayama
Expires: Aug. 2004 The University of Tokyo The University of Tokyo
Feb. 2004 October 14, 2004
TKEY Secret Key Renewal Mode TKEY Secret Key Renewal Mode
draft-ietf-dnsext-tkey-renewal-mode-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is subject to all provisions
provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
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."
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.
This Internet-Draft will expire on April 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract Abstract
This document defines a new mode in TKEY and proposes an atomic This document defines a new mode in TKEY and proposes an atomic
method for changing secret keys used for TSIG periodically. method for changing secret keys used for TSIG periodically.
Originally, TKEY provides methods of setting up shared secrets other Originally, TKEY provides methods of setting up shared secrets other
than manual exchange, but it cannot control timing of key renewal than manual exchange, but it cannot control timing of key renewal
very well though it can add or delete shared keys separately. This very well though it can add or delete shared keys separately. This
proposal is a systematical key renewal procedure intended for proposal is a systematical key renewal procedure intended for
preventing signing DNS messages with old and non-safe keys preventing signing DNS messages with old and non-safe keys
permanently. permanently.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3
1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4
1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4
2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5
2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5
2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6
2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 7 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7
2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . . . 7 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7
2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . . 7 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7
2.3.3 Attributes of Generated Key . . . . . . . . . . . . . . . 8 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8
2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . . . 8 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8
2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 10 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10
2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10
2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11
2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12
2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13
2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14
3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Compulsory Key Revocation . . . . . . . . . . . . . . . . . . . . 15 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15
4.1 Compulsory Key Revocation by Server . . . . . . . . . . . . . 15 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15
4.2 Authentication Methods Considerations . . . . . . . . . . . . 15 4.2 Authentication Methods Considerations . . . . . . . . . . 15
5 Special Considerations for Two Servers' Case . . . . . . . . . . 16 5. Special Considerations for Two Servers' Case . . . . . . . . 16
5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16
6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17
7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17
8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21
11.2 Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
1. Introduction 1. Introduction
TSIG [RFC2845] provides DNS message integrity and the TSIG [RFC2845] provides DNS message integrity and the
request/transaction authentication by means of message authentication request/transaction authentication by means of message authentication
codes (MAC). TSIG is a practical solution in view of calculation codes (MAC). TSIG is a practical solution in view of calculation
speed and availability. However, TSIG does not have exchanging speed and availability. However, TSIG does not have exchanging
mechanism of shared secret keys between server and resolver, and mechanism of shared secret keys between server and resolver, and
administrators might have to exchange secret keys manually. TKEY administrators might have to exchange secret keys manually. TKEY
[RFC2930] is introduced to solve such problem and it can exchange [RFC2930] is introduced to solve such problem and it can exchange
skipping to change at page 21, line 5 skipping to change at page 21, line 5
initial secret establishment such as Diffie-Hellman Exchanged Keying. initial secret establishment such as Diffie-Hellman Exchanged Keying.
9. IANA Considerations 9. IANA Considerations
IANA needs to allocate a value for "DH exchange for key renewal", IANA needs to allocate a value for "DH exchange for key renewal",
"server assignment for key renewal", "resolver assignment for key "server assignment for key renewal", "resolver assignment for key
renewal" and "key adoption" in the mode filed of TKEY. It also needs renewal" and "key adoption" in the mode filed of TKEY. It also needs
to allocate a value for "PartialRevoke" from the extended RCODE to allocate a value for "PartialRevoke" from the extended RCODE
space. space.
10. Acknowledgement 10. Acknowledgements
The authors would like to thank Olafur Gudmundsson, whose helpful The authors would like to thank Olafur Gudmundsson, whose helpful
input and comments contributed greatly to this document. input and comments contributed greatly to this document.
11. References 11. References
[RFC2104] 11.1. Normative References
H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
Authentication", RFC2104, February 1997.
[RFC2119] [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[RFC2539] [RFC2539]
D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
System (DNS)", RFC 2539, March 1999. System (DNS)", RFC 2539, March 1999.
[RFC2845] [RFC2845]
skipping to change at page 22, line 5 skipping to change at page 21, line 35
May 2000. May 2000.
[RFC2930] [RFC2930]
D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
RFC 2930, September 2000. RFC 2930, September 2000.
[RFC2931] [RFC2931]
D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
)", RFC 2931, September 2000. )", RFC 2931, September 2000.
11.2. Informative References
[RFC2104]
H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
Authentication", RFC2104, February 1997.
Authors' Addresses Authors' Addresses
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
Tokyo Opera City Tower Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
163-1421, Japan 163-1421, Japan
EMail: y.kamite@ntt.com EMail: y.kamite@ntt.com
Masaya Nakayama Masaya Nakayama
Information Technology Center, The University of Tokyo Information Technology Center, The University of Tokyo
2-11-16 Yayoi, Bunkyo-ku, Tokyo 2-11-16 Yayoi, Bunkyo-ku, Tokyo
113-8658, Japan 113-8658, Japan
EMail: nakayama@nc.u-tokyo.ac.jp EMail: nakayama@nc.u-tokyo.ac.jp
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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