Root DNSSEC Design Team J. Schlyter Kirei R. Lamb ICANN R. Balasubramanian VeriSign May 11, 2010 DNSSEC Key Management Implementation for the Root Zone (DRAFT) Abstract This document describes key management implementation for the KSK and ZSK operator in the deployment of DNSSEC in the root zone of the DNS. Copyright Notice Copyright (c) 2010 Internet Corporation For Assigned Names and Numbers. Schlyter, et al. [Page 1] Root Zone DNSSEC Key Management May 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. DNSSEC Parameters . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Key Signing Key (KSK) Lifetime . . . . . . . . . . . . . . 3 2.3. Zone Signing Key (ZSK) Lifetime . . . . . . . . . . . . . 3 2.4. KSK and ZSK Signature Validity . . . . . . . . . . . . . . 3 2.5. Automated Updates of Trust Anchors . . . . . . . . . . . . 3 3. Key and Signature Time Cycle . . . . . . . . . . . . . . . . . 4 3.1. Cycle with ZSK rollover . . . . . . . . . . . . . . . . . 5 3.2. Cycle with ZSK and KSK rollover . . . . . . . . . . . . . 5 4. Key Signing Request/Response . . . . . . . . . . . . . . . . . 5 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Structure . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Transmission . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Integrity Protection . . . . . . . . . . . . . . . . . . . 7 4.5. Processing . . . . . . . . . . . . . . . . . . . . . . . . 7 4.5.1. Constructing the Key Signing Request . . . . . . . . . 7 4.5.2. Validating the Key Signing Request . . . . . . . . . . 7 4.5.3. Processing the Key Signing Request . . . . . . . . . . 8 4.5.4. Validating the Signed Key Response . . . . . . . . . . 9 4.5.5. Authorizing the Signed Key Response . . . . . . . . . 10 4.5.6. Activation of the Signed Key Response . . . . . . . . 11 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Root Zone TTL Values . . . . . . . . . . . . . . . . 12 Appendix B. KSR XML Schema . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Schlyter, et al. [Page 2] Root Zone DNSSEC Key Management May 2010 1. Introduction The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. Security extensions to the DNS (DNSSEC) are described in [RFC4033], [RFC4034] and [RFC4035]. This document describes operational procedures for the KSK operator in the deployment of DNSSEC in the root zone of the DNS. 2. DNSSEC Parameters DNSSEC parameters are enumerated here for convenience only. Where differences exist between this document and the DNSSEC Practice Statements (DPS) which are current at the time of reading, the most current DPS documents should be taken as authoritative. 2.1. Algorithms The digital signature algorithm used to sign the root zone is RSA with SHA-256 ([RFC5702]). NSEC is used for authenticated denial of existence. 2.2. Key Signing Key (KSK) Lifetime The expected lifetime of the KSK is 5 years. 2.3. Zone Signing Key (ZSK) Lifetime The expected lifetime of the ZSK is approximately 90 days. 2.4. KSK and ZSK Signature Validity o KSK signatures of the root zone DNSKEY RRset has a validity period of 15 days. o ZSK signatures of other root zone authoritative data has a validity period of 7 days. 2.5. Automated Updates of Trust Anchors The following timing parameters apply to the root zone, as specified in [RFC5011]: DNSKEY RRSigExpirationInterval = 15 days Schlyter, et al. [Page 3] Root Zone DNSSEC Key Management May 2010 DNSKEY OrigTTL = 48 hours Active refresh query interval = 1 day Active refresh retry = 4.8 hours Add hold-down time = 30 days Given these timings, the minimum publication window needed to perform an automated update is 34 days based on the following formula: add hold-down time + OrigTTL + refresh query interval + refresh retry * (5 retries) As the 34 day period does not include any time to allow for clients to be offline, we increase this window to 50 days. This allows clients to be offline for more than 2 weeks during a rollover and still be able to update the trust anchor automatically. Old trust anchors are published with the revoke bit set in the root zone for 10 days. 3. Key and Signature Time Cycle DNSKEY RRsets are signed with the Root Zone KSK quarterly for cycles of approximately 90 days. Time cycles begin at the following dates each year: Q1 - January 1st Q2 - April 1st Q3 - July 1st Q4 - October 1st In order to facilitate automatic updates of resolvers' trust anchors (as described in [RFC5011]) while also minimizing the number of concurrent keys, the time cycle is divided into 9 slots of 10 days each. If the time cycle is more than 90 days, the last slot in the cycle is expanded to fill the period. Approximately 90 days before the start of the cycle, the ZSK operator sends the KSK operator a Key Signing Request (KSR (Section 4)) containing the zone signing keys it wants to publish in each slot. The KSK operator adds the key signing keys it wants to publish in Schlyter, et al. [Page 4] Root Zone DNSSEC Key Management May 2010 each slot and signs the resulting DNSKEY RRsets with the key signing key that will be active for the slot producing a Signed Key Response (SKR). The SKR is sent back for ZSK operator and the contents of each slot is published in the root zone during the cycle. To minimize the number of concurrent keys in the root DNSKEY resource record set (RRset), each slot is reserved for either ZSK or KSK rollovers. ZSK rollovers may happen at the beginning and the end of the cycle, whereas KSK rollovers may happen in the middle of the cycle: slot 1 Reserved for ZSK rollover slots 2-8 Reserved for KSK rollover slot 9 Reserved for ZSK rollover 3.1. Cycle with ZSK rollover slot 1 publish ZSK (n) + ZSK (n-1) + KSK (n), sign DNSKEY RRset with KSK(n) slots 2-8 publish ZSK (n) + KSK (n), sign DNSKEY RRset with KSK(n) slot 9 publish ZSK (n) + ZSK (n+1) + KSK (n), sign DNSKEY RRset with KSK(n) 3.2. Cycle with ZSK and KSK rollover slot 1 publish ZSK (n) + ZSK (n-1) + KSK (n), sign DNSKEY RRset with KSK(n) slots 2-6 publish ZSK (n) + KSK (n) + KSK (n+1), sign DNSKEY RRset with KSK(n) slots 7-8 publish ZSK (n) + KSK (n) + KSK (n+1), sign DNSKEY RRset with KSK (n) + KSK(n+1) slot 9 publish ZSK (n) + ZSK (n+1) + KSK (n+1), sign DNSKEY RRset with KSK(n+1) 4. Key Signing Request/Response Schlyter, et al. [Page 5] Root Zone DNSSEC Key Management May 2010 4.1. Introduction The Key Signing Request (KSR) and Signed Key Response (SKR) are formatted within an XML document designed to assist communication between the KSK and ZSK operators where KSK and ZSK responsibility is split between two parties, as is the case in the root zone. The KSR/ SKR exchange is designed to operate as follows: 1. The ZSK operator submits a KSR containing a policy and a list of ZSK keysets to the KSK operator for signing. 2. The KSK operator validates the keysets against its own policy, as well as the submitted policy. 3. For each keyset, the KSK operator adds and applies the appropriate KSK and signs the resulting keyset. 4. The KSK operator adds its policy and submits the SKR back to the ZSK operator. 5. The ZSK operator validates the returned SKR and stores it securely for use in the zone at the appropriate time. 4.2. Structure The KSR is defined by the KSR XML schema as described in Appendix B. The Key Signing Request contains: o a request policy declaring a number of key management timings that the requestor claims to follow, and o a list of signed sets of (ZSK) keys The Signed Key Response contains: o a response policy declaring a number of key management timings that the responder claims to follow, and o a list of signed sets of (KSK+ZSK) keys 4.3. Transmission The KSR/SKR is transported via HTTPS [RFC2818] using the HTTP [RFC2616] POST mechanism. ZSK/KSK operators exchange the CA certificates, list of Common Names(CNs), Organization (O) used to post KSR/SKR, respectively. Schlyter, et al. [Page 6] Root Zone DNSSEC Key Management May 2010 The KSR must be validated as described in section Section 4.5.2 before being accepted by the recipient. If any one of these checks fail, the KSR is rejected. The SKR must be validated as described in section Section 4.5.4 before being accepted by the recipient. If any one of these checks fail, the SKR is rejected. 4.4. Integrity Protection The KSR is integrity protected by calculating a SHA-256 hash over the XML file as transmitted (i.e. not in XML canonical format). This hash is verified out-of-band (e.g. by phone, via local presence, etc.) before a KSR is accepted for processing. 4.5. Processing 4.5.1. Constructing the Key Signing Request The ZSK operator constructs a Key Signing Request containing a number of key bundles corresponding to Key and Signature Time Cycle slots as described in Section 3. Each key bundle contains the following elements: o any post-published ZSK, called ZSK(n-1) o the current ZSK (for the current cycle), called ZSK(n) o any pre-published ZSK (for the next cycle), called ZSK(n+1) o one RRSIG by each ZSK in the bundle, covering all keys in the bundle. The complete Key Signing Request is sent to the KSK operator for signing. The ZSK operator also calculates a SHA-256 hash (hash#1) over the resulting KSR XML file as generated by the KSR creator. 4.5.2. Validating the Key Signing Request The following checks are performed by the KSK operator to validate the Key Signing Request before processing. The validation may be done before accepting a KSR from the the ZSK operator (i.e. as part of the transmission process) and must be done before producing a corresponding SKR. Schlyter, et al. [Page 7] Root Zone DNSSEC Key Management May 2010 The input to the KSR validation process is the KSR to be validated, KSR(n), as well as the last processed SKR, SKR(n-1). 4.5.2.1. Verify KSR/SKR chaining o For each key bundle in KSR(n), verify the signature by each ZSK to confirm proof of possession of each ZSK. The inception and expiration times of the RRSIGs in the KSR are ignored when checking proof of possession. o Check the integrity of SKR(n-1) by verifying the KSK signature over each key bundle. This verifies the integrity of all the ZSKs in SKR(n-1). When this check is performed as part of the KSR signing process, the KSK should be verified using the private KSK used for signing the KSR. o Compare the pre-published ZSK from the last key bundle of SKR(n-1) with the ZSK published in the first key bundle of KSR(n). These keys must be identical. o Compare the post-published ZSK from the first key bundle of KSR(n) with ZSK published in the last key bundle of SKR(n-1). These keys must be identical. 4.5.2.2. Verify KSR policy parameters If the KSR passes the checks below it follows that each key bundle meets the ZSK operator's policy, and that the submitter didn't make a mistake by straying from the stated policy. o Validate the policy parameters present in the KSR against the KSK operator's own policy. It is expected that the KSK operator's policy will have acceptance ranges for the policy parameters. o Validate the rest of the KSR against the the stated policy. 4.5.3. Processing the Key Signing Request Before signing the request, the KSK operator calculates a SHA-256 hash (hash#2) over the KSR XML file as received from the ZSK operator and verifies this hash out-of-band with the hash (hash#1) previously calculated by the ZSK operator. If the hashes do not match, the KSR should not be processed by the KSK operator and no corresponding SKR should be produced. The KSK operator constructs a Signed Key Response (SKR) by building a ResponsePolicy consisting of a KSK policy and a ZSK policy (copied from the KSR), together with a set of ResponseBundles. Each Schlyter, et al. [Page 8] Root Zone DNSSEC Key Management May 2010 ResponseBundle is constructed by the appropriate KSKs and ZSKs (copied from the KSR), together with a set of RRSIGs created with the Inception/Expiration specified in the KSR. The SKR is sent back to the ZSK operator for further processing. A description of the operational procedures associated with this procedure can be found in [icann-dnssec-ceremonies]. 4.5.4. Validating the Signed Key Response The KSK operator transmits the Signed Key Response with a client certificate, as described in Section 4.3. The client certificate is verified by the receiving web server. The following checks are performed by the ZSK operator to validate the Signed Key Response. The validation may be done before accepting a SKR from the the KSK operator (i.e. as part of the transmission process) and must be done before SKR is authorized and activated. o Verify that the client certificate used to push the SKR is signed by a Certificate Authority that matches the CA certificate obtained from KSK operator, o verify that the Common Name in the client certificate matches one of the Common Names of the KSK operator, o verify that the Organization in the client certificate matches the Organization of the KSK operator, o verify that the SKR received corresponds to the most recent KSR sent by the ZSK operator, o verify that the ID, serialNumber, and Domain parameters in the SKR and its corresponding KSR match, o verify that number of request bundles in the SKR matches that of the corresponding KSR, and o verify that for each request bundle the following parameters in the response match those in the request: * bundle id * inception date * expiration date Schlyter, et al. [Page 9] Root Zone DNSSEC Key Management May 2010 o verify that for each paired request and response bundle: * all the ZSKs in the request bundle are present in the response bundle, * the only ZSKs present in the response bundle are the ones in the request bundle, * KSKs are present in the SKR, * the signature inception in the response bundle is not later than inception of request bundle, * the signature expiration in the response bundle is not earlier than expiration of request bundle, and * each KSK signature is verified cryptographically. 4.5.5. Authorizing the Signed Key Response Signed Key Responses must be authorized prior to activation. A web- based interface is provided for authorization, designed for manual use by human operators. The role of authorizing SKRs is referred to here as SKR Authorizer. Prior to first use of this interface, the SKR Authorizer supplies the CA certificate, Certificate Common Name and Organization to be used during authorization process to the ZSK operator using some suitable, authenticated out-of-band mechanism (e.g. in-person peering). The ZSK operator provides authentication credentials (username and password) to the SKR Authorizer to allow them to gain access to the authorization interface. Access to the SKR authorization interface is permitted only after the following authentication steps have been performed: o verify that the client certificate used to access the SKR authorization URL is signed by a Certificate Authority that matches the CA certificate obtained from SKR authorizer, o verify that the Common Name in the client certificate matches one of the Common Names of the SKR authorizer, o verify that the Organization in the client certificate matches the Organization of the SKR authorizer, and o verify that the SKR authorizer provided correct credentials (username and password). Schlyter, et al. [Page 10] Root Zone DNSSEC Key Management May 2010 4.5.6. Activation of the Signed Key Response A DNSKEY RRset is selected from the SKR for use in the signed zone based on the following criteria: o ZSKs published in the zone that day match the ZSKs in the DNSKEY RRset, o inception date of signature in the DNSKEY RRset is no later than current UTC date, and o the expiration date of signature in the DNSKEY RRset is no earlier than current date. If more than one DNSKEY RRset matches the criteria listed above, one with later expiration date shall be picked for use. 5. References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY Schlyter, et al. [Page 11] Root Zone DNSSEC Key Management May 2010 and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009. [icann-dnssec-ceremonies] Schlyter, J., Ljunggren, F., and R. Lamb, "Root Zone DNSSEC KSK Ceremonies Guide", May 2010. Appendix A. Root Zone TTL Values +---------------+----------+ | RRSet | TTL | +---------------+----------+ | apex NS | 6 days | | apex DNSKEY | 48 hours | | delegation NS | 48 hours | | delegation DS | 24 hours | | glue {A,AAAA} | 48 hours | +---------------+----------+ Appendix B. KSR XML Schema # KSR: Key Signing Request/Response - Relax NG Compact Schema # # Authors: Jakob Schlyter # David Blacka # Joe Abley # datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" start = element KSR { attribute id { xsd:string }, attribute serial { xsd:nonNegativeInteger }, attribute domain { xsd:string }, (request | response) } request = element Request { attribute timestamp { xsd:dateTime }?, # ZSK policy in request element RequestPolicy { element ZSK { anykeyPolicy } }, Schlyter, et al. [Page 12] Root Zone DNSSEC Key Management May 2010 element RequestBundle { attribute id { xsd:string }, element Inception { xsd:dateTime }, element Expiration { xsd:dateTime }, # optional request that the request is signed by specific KSKs signer*, # ZSKs requested to be signed key+, # signatures by ZSKs to proof possession of the private key # each signature must cover the RequestBundle DNSKEY RRset signature+ }+ } response = element Response { attribute timestamp { xsd:dateTime }?, # KSK policy in response # ZSK policy from request echoed back in response element ResponsePolicy { element KSK { anykeyPolicy }, element ZSK { anykeyPolicy } }, element ResponseBundle { attribute id { xsd:string }, element Inception { xsd:dateTime }, element Expiration { xsd:dateTime }, # KSKs & ZSK:s from RequestBundle key+, # Signatures by KSKs signature+ }+ } algorithmPolicy = element SignatureAlgorithm { attribute algorithm { algorithm }, ( RSA | DSA ) } RSA = element RSA { attribute size { xsd:nonNegativeInteger }, attribute exponent { xsd:nonNegativeInteger }, Schlyter, et al. [Page 13] Root Zone DNSSEC Key Management May 2010 empty } DSA = element DSA { attribute size { xsd:nonNegativeInteger }, empty } anykeyPolicy = element PublishSafety { xsd:duration }, element RetireSafety { xsd:duration }, element MaxSignatureValidity { xsd:duration }, element MinSignatureValidity { xsd:duration }, element MaxValidityOverlap { xsd:duration }, element MinValidityOverlap { xsd:duration }, algorithmPolicy+ signer = element Signer { attribute keyIdentifier { keyid }, empty } signature = element Signature { attribute keyIdentifier { keyid }?, element TTL { ttl }, element TypeCovered { xsd:string }, element Algorithm { algorithm }, element Labels { labels }, element OriginalTTL { ttl }, element SignatureExpiration { xsd:dateTime }, element SignatureInception { xsd:dateTime }, element KeyTag { keytag }, element SignersName { xsd:string }, element SignatureData { xsd:base64Binary } } key = element Key { attribute keyIdentifier { keyid }?, attribute keyTag { keytag }, element TTL { ttl }, element Flags { flags }, element Protocol { protocol }, element Algorithm { algorithm }, element PublicKey { xsd:base64Binary } } keytag = xsd:nonNegativeInteger { maxInclusive = "65535" } Schlyter, et al. [Page 14] Root Zone DNSSEC Key Management May 2010 keyid = xsd:string algorithm = xsd:nonNegativeInteger { maxInclusive = "255" } ttl = xsd:nonNegativeInteger protocol = xsd:nonNegativeInteger { minInclusive = "3" maxInclusive = "3" } flags = xsd:nonNegativeInteger { maxInclusive = "65535" } labels = xsd:nonNegativeInteger { maxInclusive = "255" } Authors' Addresses Jakob Schlyter Kirei AB P.O. Box 53204 Goteborg SE-400 16 Sweden Email: jakob@kirei.se Richard Lamb Internet Corporation For Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Ray, CA 90292 USA Email: richard.lamb@icann.org Ramesh Balasubramanian VeriSign, Inc. 21345 Ridgetop Circle - Lakeside II Dulles, VA 20166 USA Email: rbalasubramanian@verisign.com Schlyter, et al. [Page 15]