Internet DRAFT - draft-mekking-dnsop-kasp
draft-mekking-dnsop-kasp
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:
<Denial>
<NSEC/>
</Denial>
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]
