DNSOP J. Lundstroem Internet-Draft .SE Intended status: Experimental W. Mekking Expires: January 5, 2015 NLnet Labs July 4, 2014 DNSSEC Key and Signing Policies draft-mekking-dnsop-kasp-00 Abstract This document describes how key policies should look like. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 5, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Lundstroem & Mekking Expires January 5, 2015 [Page 1] Internet-Draft KASP July 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Data Modeling . . . . . . . . . . . . . . . . . . . . . . 3 1.3.1. Data Modeling Types . . . . . . . . . . . . . . . . . 3 1.3.2. Data Modeling Arguments . . . . . . . . . . . . . . . 3 2. KASP Contents . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Preamble . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Policies . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1.1. Signatures . . . . . . . . . . . . . . . . . . . 4 2.1.1.2. Authenticated Denial of Existence . . . . . . . . 6 2.1.1.3. Keys . . . . . . . . . . . . . . . . . . . . . . 8 2.1.1.4. Zone . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1.5. Parent . . . . . . . . . . . . . . . . . . . . . 13 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Informative References . . . . . . . . . . . . . . . . . 14 3.2. Normative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction A key and signing policy (KASP) defines a DNSSEC [RFC4033] [RFC4034] [RFC4035] policy for one or more zones. 1.1. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology The reader is assumed to be familiar with DNSSEC described in [RFC4033] [RFC4034] [RFC4035], [RFC5155] and [RFC6781]. The following terminology is used throughout this document: KASP: Key And Signing Policy, describes a DNSSEC policy that can be applied to one or more zones. A key and signing policy can be expressed in any format. This document uses XML as example. Lundstroem & Mekking Expires January 5, 2015 [Page 2] Internet-Draft KASP July 2014 1.3. Data Modeling 1.3.1. Data Modeling Types This document reuses the modeling types described in [RFC6020]. The following modeling types are used: container: A container node does not have a value, but it has a list of child nodes in the data tree. The child nodes are defined in the container's substatements. leaf: A leaf node has a value, but no child nodes in the data tree. A leaf node exists in zero or one instances in the data tree. list: The "list" statement is used to define an interior data node in the schema tree. A list node may exist in multiple instances in the data tree. Each such instance is known as a list entry. choice: The "choice" statement defines a set of alternatives, only one of which may exist at any one time. A choice node does not exist in the data tree. A choice consists of a number of branches, defined with the "case" substatement. Each branch contains a number of child nodes. The nodes from at most one of the choice's branches exist at the same time. 1.3.2. Data Modeling Arguments The following arguments are used: string: A string. duration: A duration, as specified in ISO 8601 [REF]. empty: An empty type. integer: An integer. 2. KASP Contents 2.1. Preamble All policies MUST be enclosed in a KASP container. Lundstroem & Mekking Expires January 5, 2015 [Page 3] Internet-Draft KASP July 2014 container KASP { list Policy { ... } } A KASP container MUST contain a sequence of policy entries and MUST NOT contain any other modeling types. 2.1.1. Policies Each policy MUST have a "name" leaf which contains the name of the policy. The name is used to link a policy and the zones signed using it; each policy MUST have a unique name. A policy named "default" MAY be used to associate with all zones that do not have a policy explicitly configured. A policy SHOULD have a description associated with it. Furthermore, a policy MUST have the containers Signatures, Denial, Keys, Zone and Parent. These containers are described in the forthcoming sections. list Policy { key "name"; leaf name { mandatory true; type string; } leaf description { type string; } container Signatures { ... } container Denial { ... } container Keys { ... } container Zone { ... } container Parent { ... } } 2.1.1.1. Signatures A Signatures container defines the policy parameters for creating RRSIG records and MUST be included. It MUST contain the following leaf nodes: Resign, Refresh, InceptionOffset. It MAY have a leaf node Jitter. It MUST contain a Validity container that includes leaf nodes for the validity periods of certain type of resource record sets (RRsets). The Default leaf node sets the validity period for all RRsets that do not have a specific leaf node in this Validity container. The Denial leaf node sets the validity period for all NSEC and NSEC3 RRsets. Lundstroem & Mekking Expires January 5, 2015 [Page 4] Internet-Draft KASP July 2014 The Validity container MUST include leaf nodes Default and Denial and MAY include other leaf nodes to differentiate between even more types of RRsets. container Signatures { leaf Resign { mandatory true; type duration; } leaf Refresh { mandatory true; type duration; } leaf Jitter { type duration; } leaf InceptionOffset { mandatory true; type duration; } container Validity { leaf Default { mandatory true; type duration; } leaf Denial { mandatory true; type duration; } } } Here: 1. Resign - the re-sign interval, which is the interval when the signer MUST re-sign the zone. 2. Refresh - the refresh interval, detailing when a signature MUST be refreshed. As signatures are typically valid for much longer than the interval between runs of the signer, there is no need to re-generate the signatures each time the signer runs. The signature MUST be refreshed when the time until the signature expiration is closer than the refresh interval or when the data has been changed. A value of zero (PT0S) MUST be interpreted as to refresh the signatures each re-sign interval. 3. Jitter - If present, the value added to the expiration time of signatures to ensure that not all signatures expire at the same Lundstroem & Mekking Expires January 5, 2015 [Page 5] Internet-Draft KASP July 2014 time. The actual value of Jitter to be added MUST be -j + (r % 2j), where j is the jitter value from the policy and r a random duration, uniformly ranging between -j and j, is added to signature validity period to get the signature expiration time. 4. InceptionOffset - a duration that MUST be subtracted from the time at which a record is signed to give the start time of the record. This is required to allow for clock skew between the signing system and the system on which the signature is checked. Without it, the possibility exists that the checking system could retrieve a signature whose start time is later than the current time. 5. Validity - groups two or more elements of information related to how long the signatures are valid for - Denial is the validity period for all NSEC and NSEC3 RRsets, Default is the validity period for all other RRset. [MM: Add MaxZoneTTL] The relationship between these elements is shown [RFC6781], Figure 11. 2.1.1.2. Authenticated Denial of Existence Authenticated denial of existence information is included within a Denial container. It MUST contain either an empty leaf node NSEC or a container NSEC3. A NSEC3 container MUST include a leaf node for TTL and Resalt and MUST include a container Hash. Additionally, it MAY include an OptOut leaf node. The Hash container MUST include three leaf nodes: Algorithm, Iterations and SaltLength. Lundstroem & Mekking Expires January 5, 2015 [Page 6] Internet-Draft KASP July 2014 container Denial { choice RRtype { case plain { leaf NSEC { mandatory true; type empty; } } case hashed { container NSEC3 { leaf TTL { mandatory true; type duration; } leaf OptOut { type empty; } leaf Resalt { mandatory true; type duration; } container Hash { leaf Algorithm { mandatory true; type integer; } leaf Iterations { mandatory true; type integer; } leaf SaltLength { mandatory true; type integer; } } } } } If NSEC is used, zones with this policy MUST include NSEC records when signing the zone. If NSEC3 is used, zones with this policy MUST include NSEC3 and NSEC3PARAM records with the appropriate policy values: 1. TTL - if present, the TTL for the NSEC3PARAM resource record MUST be set to this value. If not present, PT0S (0) SHOULD be used as TTL. Lundstroem & Mekking Expires January 5, 2015 [Page 7] Internet-Draft KASP July 2014 2. OptOut - if present, all included NSEC3 records SHOULD set the Opt-Out bit. The signer SHOULD NOT include NSEC3 records for insecure delegations. 3. Resalt - A new salt value MUST be generated each Resalt interval value. 4. Algorithm, Iterations, SaltLength MUST be used as the parameters to the hash algorithm. The choice and case modeling types are not included in the actual data tree. In the case that NSEC is used, the XML example would be: 2.1.1.3. Keys Parameters relating to keys can be found in Keys container. This container MUST include leaf node for TTL, and MAY include leaf nodes for PublishSafety, RetireSafety, ShareKeys and Purge. Furthermore, it MAY include a KSK list, a ZSK list and/or a CSK list. The latter indicates that a Single-Type Signing Scheme is used. If no such lists are included in the policy, the zone remains unsigned. container Keys { leaf TTL { mandatory true; type duration; } leaf PublishSafety { type duration; } leaf RetireSafety { type duration; } leaf ShareKeys { type empty; } leaf Purge { type duration; } list KSK { ... } list ZSK { ... } list CSK { ... } } Lundstroem & Mekking Expires January 5, 2015 [Page 8] Internet-Draft KASP July 2014 The leaf nodes specify the following behavior: 1. TTL - This value MUST be used as the TTL of the DNSKEY resource records. 2. PublishSafety - If present, the publish safety margin is used to give some extra time to cover unforeseen events and MUST be added to the publish interval in key timing equations. 3. RetireSafety - If present and similar to PublishSafety, the retire safety margin MUST be added to the retire interval in key timing equations. 4. ShareKeys - if multiple zones are associated with the same policy, the presence of a ShareKeys node indicates that a physical key can be shared between zones. 5. Purge - if present, keys in the dead state (as defined in key- timing-bis) will be automatically purged from the database after this interval. A CSK, KSK or ZSK list MUST include leaf nodes for Algorithm, Length, Lifetime and Repository. Additionally, they MAY include a RollType leaf, Standby leaf and ManualRollover leaf. A CSK or KSK list MAY also include a RFC5011 leaf. list CSK { leaf Algorithm { mandatory true; type integer; } leaf Length { mandatory true; type integer; } leaf Lifetime { mandatory true; type duration; } leaf Repository { mandatory true; type string; } leaf RollType { type string; } leaf Standby { type empty; Lundstroem & Mekking Expires January 5, 2015 [Page 9] Internet-Draft KASP July 2014 } leaf ManualRollover { type empty; } leaf RFC5011 { type empty; } } list KSK { leaf Algorithm { mandatory true; type integer; } leaf Length { mandatory true; type integer; } leaf Lifetime { mandatory true; type duration; } leaf Repository { mandatory true; type string; } leaf RollType { type string; } leaf Standby { type empty; } leaf ManualRollover { type empty; } leaf RFC5011 { type empty; } } list ZSK { leaf Algorithm { mandatory true; type integer; } leaf Length { mandatory true; type integer; Lundstroem & Mekking Expires January 5, 2015 [Page 10] Internet-Draft KASP July 2014 } leaf Lifetime { mandatory true; type duration; } leaf Repository { mandatory true; type string; } leaf RollType { type string; } leaf Standby { type empty; } leaf ManualRollover { type empty; } } where: 1. Algorithm - this algorithm MUST be used. 2. Length - this key length MUST be used. 3. Lifetime - determines how long the key SHOULD be used for before it is rolled. 4. Repository - determines the location of the physical keys. The corresponding type of keys MUST be stored in this repository. 5. Standby - if present, determines the number of standby keys MUST be held in the zone. 6. ManualRollover - if present, this indicates that the key rollover MUST NOT occur automatically, it may only be initiated by the operator. 7. RFC5011 - if present, this indicates that the key rollover MUST include additional time for key publication and retirement and MUST revoke the predecessor key accordingly. 2.1.1.4. Zone The Zone container encloses general information concerning the zone. It MAY include a PropagationDelay leaf and MUST have a SOA container. Lundstroem & Mekking Expires January 5, 2015 [Page 11] Internet-Draft KASP July 2014 The SOA container MUST include a TTL leaf, Minimum leaf and Serial leaf. container Zone { leaf PropagationDelay { type duration; } container SOA { leaf TTL { mandatory true; type duration; } leaf Minimum { mandatory true; type duration; } leaf Serial { mandatory true; type string; } } } The PropagationDelay leaf holds the amount of time needed for information changes at the master server for the zone to work its way through to all the secondary servers. The value MAY be used in equations related to key timings during a rollover. If PropagationDelay is not used, a signer MUST use different heuristics to make sure key timings during a rollover are correct, for example by querying the name servers for the required records to exist. The SOA container gives values of parameters for the SOA record in the signed zone. These values will override values set for the SOA record in the unsigned zone file: 1. TTL - The TTL of the SOA record MUST be set to the value of the TTL leaf. 2. Minimum - The MINIMUM RDATA field of the SOA record MUST be set to the value of the Minimum leaf. 3. Serial - The format of the serial number in the signed zone. This is one of: "counter", datecounter, unixtime, keep. When Serial is set to "counter", the SOA serial MUST be incremented by one every re-sign. Lundstroem & Mekking Expires January 5, 2015 [Page 12] Internet-Draft KASP July 2014 When Serial is set to "datecounter", the SOA serial MUST be set to YYYYMMDDCC, where YYYYMMDD represents the current date and CC the number of new re-signs that day. If there are more than 100 re-signs a day, the date MUST rollover to the day after and count is reset to 00. When Serial is "unixtime", the SOA serial MUST be set to the seconds since the epoch (1970-01-01 UTC). When Serial is "keep" the SOA serial MUST be set to the SERIAL RDATA field of the SOA record in the unsigned zone. If this does not increment the last used serial, a signer MUST NOT produce a signed zone. 2.1.1.5. Parent If a DNSSEC zone is in a chain of trust, digest information about the KSKs used in the zone will be published in DS records in the parent zone. To properly roll keys, timing information about the parent zone must be configured in the Parent container. A Parent container MAY include a PropagationDelay leaf, a DS container and a SOA container. The DS container MAY include a TTL leaf and the SOA container MAY include TTL and Minimum leafs. container Parent { leaf PropagationDelay { type duration; } container DS { leaf TTL { type duration; } } container SOA { leaf TTL { type duration; } leaf Minimum { type duration; } } } Here, the PropagationDelay leaf configures how long it takes to get a DS record published in the parent zone after submitting the DNSKEY or DS record to the parent zone manager. The value SHOULD be used in equations related to key timings during a rollover. If PropagationDelay is not used, a signer MUST use different heuristics Lundstroem & Mekking Expires January 5, 2015 [Page 13] Internet-Draft KASP July 2014 to make sure key timings during a rollover are correct, for example by querying the name servers for the required records to exist. The DS and SOA containers give values of parameters for the DS record and SOA record in the parent zone. These values SHOULD be used in equations related to key timings during a rollover. If these values are not used, a signer MUST query the parent name servers in order to retrieve the correct values. A before: 1. TTL - The TTL of the DS and SOA records MUST be set to the value of the corresponding TTL leaf. 2. Minimum - The MINIMUM RDATA field of the SOA record MUST be set to the value of the Minimum leaf. 3. References 3.1. Informative References [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. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, December 2012. 3.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Lundstroem & Mekking Expires January 5, 2015 [Page 14] Internet-Draft KASP July 2014 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. Lundstroem & Mekking Expires January 5, 2015 [Page 15] Internet-Draft KASP July 2014 Appendix A. Changelog o Initial version Authors' Addresses Jerry Lundstroem .SE Ringvaegen 100 Box 7399 Stockholm 103 91 SE EMail: jerry.lundstrom@iis.se URI: http://www.iis.se/ W. (Matthijs) Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH NL EMail: matthijs@nlnetlabs.nl URI: http://www.nlnetlabs.nl/ Lundstroem & Mekking Expires January 5, 2015 [Page 16]