draft-ietf-dnsop-rollover-00.txt   draft-ietf-dnsop-rollover-01.txt 
INTERNET-DRAFT DNSSEC Key Rollover INTERNET-DRAFT DNSSEC Key Rollover
UPDATES RFC 1996 July 2000 UPDATES RFC 1996 December 2000
Expires January 2001 Expires June 2001
Domain Name System (DNS) Security Key Rollover Domain Name System (DNS) Security Key Rollover
------ ---- ------ ----- -------- --- -------- ------ ---- ------ ----- -------- --- --------
<draft-ietf-dnsop-rollover-00.txt> <draft-ietf-dnsop-rollover-01.txt>
Mark Andrews, Donald E. Eastlake 3rd Mark Andrews, Donald E. Eastlake 3rd
Status of This Document Status of This Document
This draft, file name draft-ietf-dnsop-rollover-00.txt, is intended This draft is intended to be become a Proposed Standard RFC.
to be become a Proposed Standard RFC. Distribution of this document Distribution of this document is unlimited. Comments should be sent
is unlimited. Comments should be sent to the Domain Name Server to the Domain Name Server Operations working group mailing list
Operations working group mailing list <dnsop@cafax.se> or to the <dnsop@cafax.se> or to the authors.
authors.
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 RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. 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
skipping to change at page 1, line 44 skipping to change at page 1, line 43
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
Deployment of Domain Name System (DNS) security with good cryptologic Deployment of Domain Name System (DNS) security with good cryptologic
practice will involve large volumes of key rollover traffic. A practice will involve large volumes of key rollover traffic. A
standard format and protocol for such traffic will be necessary for standard format and protocol for such traffic will be necessary for
this to be practical and is specified herein. this to be practical and is specified herein.
[Note: The previous version of this draft was draft-ietf-dnsind- [Note: The previous versions of this draft included draft-ietf-
rollover-00.txt and before that draft-ietf-dnssec-rollover-00.txt.] dnsind-rollover-*.txt and draft-ietf-dnssec-rollover-*.txt.]
INTERNET-DRAFT July 2000 DNSSEC Key Rollover INTERNET-DRAFT December 2000 DNSSEC Key Rollover
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1 Abstract...................................................1
Table of Contents..........................................2 Table of Contents..........................................2
1. Introduction............................................3 1. Introduction............................................3
2. Key Rollover Scenario...................................3 2. Key Rollover Scenario...................................3
skipping to change at page 3, line 5 skipping to change at page 3, line 5
3.2 Rollover to Children...................................7 3.2 Rollover to Children...................................7
4. Secure Zone Cuts and Joinders...........................8 4. Secure Zone Cuts and Joinders...........................8
5. Security Considerations.................................9 5. Security Considerations.................................9
6. IANA Considerations.....................................9 6. IANA Considerations.....................................9
References................................................10 References................................................10
Authors Address...........................................11 Authors Address...........................................11
Expiration and File Name..................................11 Expiration and File Name..................................11
INTERNET-DRAFT July 2000 DNSSEC Key Rollover INTERNET-DRAFT December 2000 DNSSEC Key Rollover
1. Introduction 1. Introduction
The Domain Name System (DNS) [RFC 1034, 1035] is the global The Domain Name System (DNS) [RFC 1034, 1035] is the global
hierarchical replicated distributed database system for Internet hierarchical replicated distributed database system for Internet
addressing, mail proxy, and other information. The DNS has been addressing, mail proxy, and other information. The DNS has been
extended to include digital signatures and cryptographic keys as extended to include digital signatures and cryptographic keys as
described in [RFC 2535]. described in [RFC 2535].
The principle security service provided for DNS data is data origin The principle security service provided for DNS data is data origin
skipping to change at page 4, line 5 skipping to change at page 4, line 5
Although DNSSEC provides for the storage of other keys in the DNS for Although DNSSEC provides for the storage of other keys in the DNS for
other purposes, DNSSEC zone keys are included solely for the purpose other purposes, DNSSEC zone keys are included solely for the purpose
of being retrieved to authenticate DNSSEC signatures. Thus, when a of being retrieved to authenticate DNSSEC signatures. Thus, when a
zone key is being rolled over, the old public key should be left in zone key is being rolled over, the old public key should be left in
the zone, along with the addition of the new public key, for as long the zone, along with the addition of the new public key, for as long
as it will reasonably be needed to authenticate old signatures that as it will reasonably be needed to authenticate old signatures that
have been cached or are held by applications. Similarly, old parent have been cached or are held by applications. Similarly, old parent
SIGs should be retained for a short time after a parent KEY(s) roll SIGs should be retained for a short time after a parent KEY(s) roll
over and new parent SIGs have been installed. over and new parent SIGs have been installed.
INTERNET-DRAFT July 2000 DNSSEC Key Rollover INTERNET-DRAFT December 2000 DNSSEC Key Rollover
If DNSSEC were universally deployed and all DNS server's clocks were If DNSSEC were universally deployed and all DNS server's clocks were
synchronized and zone transfers were instantaneous etc., it might be synchronized and zone transfers were instantaneous etc., it might be
possible to avoid ever having duplicate old/new KEY/SIG RRsets due to possible to avoid ever having duplicate old/new KEY/SIG RRsets due to
simultaneous expiration of SIGs everywhere in the DNS. But these simultaneous expiration of SIGs everywhere in the DNS. But these
assumptions do not hold. Security aware DNS servers decrease the TTL assumptions do not hold. Security aware DNS servers decrease the TTL
of secure RRs served as the expiration of their authenticating SIG(s) of secure RRs served as the expiration of their authenticating SIG(s)
approaches but some dithered fudge must generally be left due to approaches but some dithered fudge must generally be left due to
clock skew, rounding, RR retention by applications, and the like. clock skew, rounding, RR retention by applications, and the like.
Retaining old KEYs for a while after rolling over to new KEYs will be Retaining old KEYs for a while after rolling over to new KEYs will be
necessary in practical cases. necessary in practical cases.
Assume a secure middle zone with a s parent and a secure child wishes Assume a secure middle zone with a secure parent and a secure child
to role over its KEY RRset. This RRset would probably be one KEY RR wishes to role over its KEY RRset. This RRset would probably be one
per crypto algorithm used to sign the zone, but for this scenario, we KEY RR per crypto algorithm used to sign the zone, but for this
will simply assume it is one KEY RR. The old KEY RR and two SIG RRs, scenario, we will simply assume it is one KEY RR. The old KEY RR and
one signed by the parent and one signed by the zone itself, will two SIG RRs, one signed by the parent and one signed by the zone
exist at the apex of the middle zone. (These RRs may also exist at itself, will exist at the apex of the middle zone. (These RRs may
the leaf node for this zone in its parent if the parent chooses to also exist at the leaf node for this zone in its parent if the parent
store them there.) The contents of this middle zone and the zone KEY chooses to store them there.) The contents of this middle zone and
RRs of its secure child will have SIGs under the old key. the zone KEY RRs of its secure child will have SIGs under the old
key.
The middle zone owner needs to communicate with its parent to obtain The middle zone owner needs to communicate with its parent to obtain
a new parental signature covering both the old and new KEY RRs and a a new parental signature covering both the old and new KEY RRs and a
parental signature covering just the new KEY RR. The signature on parental signature covering just the new KEY RR. The signature on
both is needed so the old KEY can be retain for the period it might both is needed so the old KEY can be retain for the period it might
be needed to authenticate old SIGs. The middle zone would probably be needed to authenticate old SIGs. The middle zone would probably
want to obtain these in advance so that it can install them at the want to obtain these in advance so that it can install them at the
right time along with its new SIG RRs covering the content of its right time along with its new SIG RRs covering the content of its
zone. Finally, it needs to give new SIG RRs to its child that cover zone. Finally, it needs to give new SIG RRs to its child that cover
both its KEY RRs and the child's KEY RRs so it must signal its the child's KEY RRs so it must signal its children to ask for such
children to ask for such SIG RRs. SIG RRs.
The table below illustrates what happens during this rollover The table below illustrates what happens during this rollover
scenario: scenario:
INTERNET-DRAFT July 2000 DNSSEC Key Rollover INTERNET-DRAFT December 2000 DNSSEC Key Rollover
BEFORE ROLLOVER SHORTLY AFTER AFTER ROLLOVER BEFORE ROLLOVER SHORTLY AFTER AFTER ROLLOVER
p.x KEY P1 p.x KEY P1 p.x KEY P1 p.x KEY P1 p.x KEY P1 p.x KEY P1
p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1
p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP
m.p.x KEY M1 m.p.x KEY M2 m.p.x KEY M2 m.p.x KEY M1 m.p.x KEY M2 m.p.x KEY M2
m.p.x SIG(KEY) P1 m.p.x KEY M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) P1 m.p.x KEY M1 m.p.x SIG(KEY) P1
m.p.x SIG(KEY) M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) M2 m.p.x SIG(KEY) M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) M2
skipping to change at page 6, line 5 skipping to change at page 6, line 5
new KEY RRset, as discussed above. new KEY RRset, as discussed above.
The server selection algorithm in [RFC 2136] section 4 should be used The server selection algorithm in [RFC 2136] section 4 should be used
for the retrieval of SRV RRs [RFC 2782] using the service name (tbd) for the retrieval of SRV RRs [RFC 2782] using the service name (tbd)
to determine which host(s) to which the ROLLOVER request is sent. A to determine which host(s) to which the ROLLOVER request is sent. A
child needs to be configured with or determine the name of its child needs to be configured with or determine the name of its
parent. parent.
The ROLLOVER request Zone should be specified in the Zone section. The ROLLOVER request Zone should be specified in the Zone section.
INTERNET-DRAFT July 2000 DNSSEC Key Rollover INTERNET-DRAFT December 2000 DNSSEC Key Rollover
The request Update section has the new KEY RRset on which the parent The request Update section has the new KEY RRset on which the parent
signature is requested along with the requesting zone's SIG(s) under signature is requested along with the requesting zone's SIG(s) under
its old KEY(s) as RRs to be "added" to the parent zone. The its old KEY(s) as RRs to be "added" to the parent zone. The
inception and expiration times in this child SIG or SIGs are the inception and expiration times in this child SIG or SIGs are the
requested inception and expiration times for the new parent SIG(s). requested inception and expiration times for the new parent SIG(s).
The "prerequisites" section has the old child KEY RRset with the The "prerequisites" section has the old child KEY RRset with the
parent SIG (see next paragraph). parent SIG (see next paragraph).
An upward ROLLOVER request MUST be signed and if not signed a BADAUTH An upward ROLLOVER request MUST be signed and if not signed a BADAUTH
response generated. The signature MUST be a SIG(0) using the response generated. The signature MUST be a SIG(0) using the
previous zone KEY, so the parent can validate it, or be under a valid previous zone KEY, so the parent can validate it, or be under a valid
TSIG key [RFC 2845] arranged with the parent. Including the TSIG key [RFC 2845] arranged with the parent. Including the
"prerequisite" section as specified above enables a parent that keeps "prerequisite" section as specified above enables a parent that keeps
no record of its children's KEYs to still authenticate a child's no record of its children's KEYs to still authenticate a child's
ROLLOVER request based on the old child KEY because the parent is ROLLOVER request based on the old child KEY because the parent is
presented with its own SIG on the old KEY. presented with its own SIG on the old KEY.
If the ROLLOVER command is erroneous or violates parental policy, an If the ROLLOVER command is erroneous or violates parental policy, an
Error response is returned. If a parent retains copies of its Error response is returned. If a parent retains copies of its
children's KEYs, it may use that knowledge to validate ROLLOVER children's KEYs, it MAY use that knowledge to validate ROLLOVER
request SIGs and ignore the "prerequisites" section. request SIGs and ignore the "prerequisites" section.
If the ROLLOVER command is OK and the parent can sign online, its If the ROLLOVER command is OK and the parent can sign online, its
response MAY include the new parent SIG(s) in the response Update response MAY include the new parent SIG(s) in the response Update
section. This response MUST be sent to the originator of the section. This response MUST be sent to the originator of the
request. request.
If the parent can not sign online in a reasonable length of time, it If the parent can not sign online in a reasonable length of time, it
should return a response with an empty Update section and queue the should return a response with an empty Update section and queue the
SIG(s) calculation request. This response MUST be sent to the SIG(s) calculation request. This response MUST be sent to the
skipping to change at page 7, line 5 skipping to change at page 7, line 5
name (tbd). This ROLLOVER reqeust contains the KEY RR set that name (tbd). This ROLLOVER reqeust contains the KEY RR set that
triggered it and the new SIG(s). There are several reasons for triggered it and the new SIG(s). There are several reasons for
sending the ROLLOVER response regardless of whether the new SIG RR(s) sending the ROLLOVER response regardless of whether the new SIG RR(s)
were sent in the original response. One is to provide an indication were sent in the original response. One is to provide an indication
to the operators of the zone in the event someone is trying to hijack to the operators of the zone in the event someone is trying to hijack
the zone. Another is that this maximizes the probability of the the zone. Another is that this maximizes the probability of the
response getting through. response getting through.
Although the parent zone need not hold or serve the child's key, if Although the parent zone need not hold or serve the child's key, if
INTERNET-DRAFT July 2000 DNSSEC Key Rollover INTERNET-DRAFT December 2000 DNSSEC Key Rollover
it does, the ROLLOVER command request MAY automatically update the it does, the ROLLOVER command request MAY automatically update the
parent zone. parent zone.
This document does not cover the question of parental policy on key This document does not cover the question of parental policy on key
rollovers. Parents may have restrictions on how far into the future rollovers. Parents may have restrictions on how far into the future
they will sign KEY RRsets, what algorithms or key lengths they will they will sign KEY RRsets, what algorithms or key lengths they will
support, may require payment for the service, etc. The signing of a support, may require payment for the service, etc. The signing of a
future KEY by a parent is, to some extent, a granting of future future KEY by a parent is, to some extent, a granting of future
authoritative existence to the controller of the child private key authoritative existence to the controller of the child private key
skipping to change at page 8, line 5 skipping to change at page 8, line 5
Unless the rollover server for the zone master is configured to Unless the rollover server for the zone master is configured to
initiate an automatic ROLLOVER it MUST seek to inform its operators initiate an automatic ROLLOVER it MUST seek to inform its operators
that a rollover NOTIFY request has been received. This could be done that a rollover NOTIFY request has been received. This could be done
by a number of methods including generating a log message, generating by a number of methods including generating a log message, generating
an email request to the child zone's SOA RNAME or any other method an email request to the child zone's SOA RNAME or any other method
defined in the server's configuration for the zone. The default defined in the server's configuration for the zone. The default
SHOULD be to send mail to the zone's SOA RNAME. As with all rollover SHOULD be to send mail to the zone's SOA RNAME. As with all rollover
operations, care should be taken to rate limit these messages so operations, care should be taken to rate limit these messages so
INTERNET-DRAFT July 2000 DNSSEC Key Rollover INTERNET-DRAFT December 2000 DNSSEC Key Rollover
prevent them being used to facilitate a denial of service attack. prevent them being used to facilitate a denial of service attack.
Once the message has been sent (or suppressed if so configured) to Once the message has been sent (or suppressed if so configured) to
the child zone's administrator the master server for the child zone the child zone's administrator the master server for the child zone
is free to respond to the rollover NOTIFY request. is free to respond to the rollover NOTIFY request.
4. Secure Zone Cuts and Joinders 4. Secure Zone Cuts and Joinders
There are two other events that have some similarity to key rollover. There are two other events that have some similarity to key rollover.
skipping to change at page 9, line 5 skipping to change at page 9, line 5
rollover to the new cut or joined state to work, these SOAs must be rollover to the new cut or joined state to work, these SOAs must be
signed with old KEY(s) of the former parent so the signatures can be signed with old KEY(s) of the former parent so the signatures can be
validated by the zone whose parent name is changing. In the case of validated by the zone whose parent name is changing. In the case of
a joinder, if the private key of the pinched out middle zone is not a joinder, if the private key of the pinched out middle zone is not
available, then manual update of the former grandchild, now child, available, then manual update of the former grandchild, now child,
will be necessary. In the case of introducing a cut, operational will be necessary. In the case of introducing a cut, operational
coordination with the former parent, now grandparent, signing the coordination with the former parent, now grandparent, signing the
initial updates to the former child, now grandchild, will be needed initial updates to the former child, now grandchild, will be needed
to automate the reconfiguration of the zones. to automate the reconfiguration of the zones.
INTERNET-DRAFT July 2000 DNSSEC Key Rollover INTERNET-DRAFT December 2000 DNSSEC Key Rollover
5. Security Considerations 5. Security Considerations
The security of ROLLOVER or UPDATE requests is essential, otherwise The security of ROLLOVER or UPDATE requests is essential, otherwise
false children could steal parental authorization or a false parent false children could steal parental authorization or a false parent
could cause a child to install an invalid signature on its zone key, could cause a child to install an invalid signature on its zone key,
etc. etc.
A ROLLOVER request can be authenticated by request SIG(s)under the A ROLLOVER request can be authenticated by request SIG(s)under the
old zone KEY(s) of the requestor [RFC 2535]. The response SHOULD old zone KEY(s) of the requestor [RFC 2535]. The response SHOULD
skipping to change at page 10, line 5 skipping to change at page 10, line 5
compromised. compromised.
6. IANA Considerations 6. IANA Considerations
The DNS operation code (TBD) is assigned to ROLLOVER. The DNS operation code (TBD) is assigned to ROLLOVER.
The Service Name (TBD) is assigned to the DNS key rollover service. The Service Name (TBD) is assigned to the DNS key rollover service.
There are no other IANA considerations in this document. There are no other IANA considerations in this document.
INTERNET-DRAFT July 2000 DNSSEC Key Rollover INTERNET-DRAFT December 2000 DNSSEC Key Rollover
References References
[RFC 1034] - "Domain names - concepts and facilities", P. [RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, 11/01/1987. Mockapetris, 11/01/1987.
[RFC 1035] - "Domain names - implementation and specification", P. [RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, 11/01/1987. Mockapetris, 11/01/1987.
[RFC 1996] - "A Mechanism for Prompt Notification of Zone Changes [RFC 1996] - "A Mechanism for Prompt Notification of Zone Changes
skipping to change at page 11, line 5 skipping to change at page 11, line 5
[RFC 2541] - "DNS Security Operational Considerations", D. Eastlake. [RFC 2541] - "DNS Security Operational Considerations", D. Eastlake.
March 1999. March 1999.
[RFC 2782] - "A DNS RR for specifying the location of services (DNS [RFC 2782] - "A DNS RR for specifying the location of services (DNS
SRV)", A. Gulbrandsen, P. Vixie, L. Esibov. February 2000. SRV)", A. Gulbrandsen, P. Vixie, L. Esibov. February 2000.
[RFC 2845] - "Secret Key Transaction Authentication for DNS (TSIG)", [RFC 2845] - "Secret Key Transaction Authentication for DNS (TSIG)",
P. Vixie, O. Gundmundsson, D. Eastlake, B. Wellington. May 2000. P. Vixie, O. Gundmundsson, D. Eastlake, B. Wellington. May 2000.
INTERNET-DRAFT July 2000 DNSSEC Key Rollover INTERNET-DRAFT December 2000 DNSSEC Key Rollover
Authors Address Authors Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Motorola
140 Forest Avenue 155 Beaver Street
Hudson, MA 01749 USA Milford, MA 01757 USA
Telephone: +1 978-562-2827 (h) Telephone: +1 508-261-5434 (w)
+1 508-261-5434 (w) +1 508-634-2066 (h)
FAX: +1 508-261-4447 (w) FAX: +1 508-261-4447 (w)
EMail: Donald.Eastlake@motorola.com EMail: Donald.Eastlake@motorola.com
Mark Andrews Mark Andrews
Internet Software Consortium Nominum, Inc.
1 Seymour Street 1 Seymour Street
Dundas Valley, NSW 2117 Dundas Valley, NSW 2117
AUSTRALIA AUSTRALIA
Telephone: +61-2-9871-4742 Telephone: +61-2-9871-4742
Email: Mark_Andrews@iengines.com Email: Mark.Andrews@nominum.com
Expiration and File Name Expiration and File Name
This draft expires in December 2000. This draft expires in June 2001
Its file name is draft-ietf-dnsop-rollover-00.txt. Its file name is draft-ietf-dnsop-rollover-01.txt.
 End of changes. 

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