summaryrefslogtreecommitdiffstats
path: root/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt')
-rw-r--r--doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt1501
1 files changed, 1501 insertions, 0 deletions
diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
new file mode 100644
index 0000000..eaf6865
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
@@ -0,0 +1,1501 @@
+Network Working Group J. Ihren
+Internet-Draft Autonomica AB
+Expires: April 18, 2005 O. Kolkman
+ RIPE NCC
+ B. Manning
+ EP.net
+ October 18, 2004
+
+
+
+ An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for
+ DNSSEC Trust Anchors.
+ draft-ietf-dnsext-trustupdate-threshold-00
+
+
+Status of this Memo
+
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+
+ 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."
+
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+ This Internet-Draft will expire on April 18, 2005.
+
+
+Copyright Notice
+
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+
+Abstract
+
+
+ The DNS Security Extensions (DNSSEC) works by validating so called
+ chains of authority. The start of these chains of authority are
+ usually public keys that are anchored in the DNS clients. These keys
+ are known as the so called trust anchors.
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 1]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ This memo describes a method how these client trust anchors can be
+ replaced using the DNS validation and querying mechanisms (in-band)
+ when the key pairs used for signing by zone owner are rolled.
+
+
+ This memo also describes a method to establish the validity of trust
+ anchors for initial configuration, or priming, using out of band
+ mechanisms.
+
+
+Table of Contents
+
+
+ 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry
+ Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Introduction and Background . . . . . . . . . . . . . . . . . 5
+ 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5
+ 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7
+ 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8
+ 3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9
+ 3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10
+ 3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11
+ 3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12
+ 3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12
+ 3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12
+ 3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12
+ 3.6 Removal of trust anchors for a trust point . . . . . . . . 12
+ 3.7 No need for resolver-side overlap of old and new keys . . 13
+ 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14
+ 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.1.1 Bootstrapping trust anchors using a priming key . . . 14
+ 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15
+ 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
+ 6.1 Threshold-based Trust Update Security Considerations . . . 17
+ 6.2 Priming Key Security Considerations . . . . . . . . . . . 17
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20
+ 8.2 Informative References . . . . . . . . . . . . . . . . . . . 20
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
+ A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
+ B. Document History . . . . . . . . . . . . . . . . . . . . . . . 23
+ B.1 prior to version 00 . . . . . . . . . . . . . . . . . . . 23
+ B.2 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23
+ Intellectual Property and Copyright Statements . . . . . . . . 24
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 2]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+1. Terminology
+
+
+ The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+ and "MAY" in this document are to be interpreted as described in
+ RFC2119 [1].
+
+
+ The term "zone" refers to the unit of administrative control in the
+ Domain Name System. In this document "name server" denotes a DNS
+ name server that is authoritative (i.e. knows all there is to know)
+ for a DNS zone. A "zone owner" is the entity responsible for signing
+ and publishing a zone on a name server. The terms "authentication
+ chain", "bogus", "trust anchors" and "Island of Security" are defined
+ in [4]. Throughout this document we use the term "resolver" to mean
+ "Validating Stub Resolvers" as defined in [4].
+
+
+ We use the term "security apex" as the zone for which a trust anchor
+ has been configured (by validating clients) and which is therefore,
+ by definition, at the root of an island of security. The
+ configuration of trust anchors is a client side issue. Therefore a
+ zone owner may not always know if their zone has become a security
+ apex.
+
+
+ A "stale anchor" is a trust anchor (a public key) that relates to a
+ key that is not used for signing. Since trust anchors indicate that
+ a zone is supposed to be secure a validator will mark the all data in
+ an island of security as bogus when all trust anchors become stale.
+
+
+ It is assumed that the reader is familiar with public key
+ cryptography concepts [REF: Schneier Applied Cryptography] and is
+ able to distinguish between the private and public parts of a key
+ based on the context in which we use the term "key". If there is a
+ possible ambiguity we will explicitly mention if a private or a
+ public part of a key is used.
+
+
+ The term "administrator" is used loosely throughout the text. In
+ some cases an administrator is meant to be a person, in other cases
+ the administrator may be a process that has been delegated certain
+ responsibilities.
+
+
+1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points
+
+
+ Although the DNSSEC protocol does not make a distinction between
+ different keys the operational practice is that a distinction is made
+ between zone signing keys and key signing keys. A key signing key is
+ used to exclusively sign the DNSKEY Resource Record (RR) set at the
+ apex of a zone and the zone signing keys sign all the data in the
+ zone (including the DNSKEY RRset at the apex).
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 3]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ Keys that are intended to be used as the start of the authentication
+ chain for a particular zone, either because they are pointed to by a
+ parental DS RR or because they are configured as a trust anchor, are
+ called Secure Entry Point (SEP) keys. In practice these SEP keys
+ will be key signing keys.
+
+
+ In order for the mechanism described herein to work the keys that are
+ intended to be used as secure entry points MUST have the SEP [2] flag
+ set. In the examples it is assumed that keys with the SEP flag set
+ are used as key signing keys and thus exclusively sign the DNSKEY
+ RRset published at the apex of the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 4]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+2. Introduction and Background
+
+
+ When DNSSEC signatures are validated the resolver constructs a chain
+ of authority from a pre-configured trust anchor to the DNSKEY
+ Resource Record (RR), which contains the public key that validates
+ the signature stored in an RRSIG RR. DNSSEC is designed so that the
+ administrator of a resolver can validate data in multiple islands of
+ security by configuring multiple trust anchors.
+
+
+ It is expected that resolvers will have more than one trust anchor
+ configured. Although there is no deployment experience it is not
+ unreasonable to expect resolvers to be configured with a number of
+ trust anchors that varies between order 1 and order 1000. Because
+ zone owners are expected to roll their keys, trust anchors will have
+ to be maintained (in the resolver end) in order not to become stale.
+
+
+ Since there is no global key maintenance policy for zone owners and
+ there are no mechanisms in the DNS to signal the key maintenance
+ policy it may be very hard for resolvers administrators to keep their
+ set of trust anchors up to date. For instance, if there is only one
+ trust anchor configured and the key maintenance policy is clearly
+ published, through some out of band trusted channel, then a resolver
+ administrator can probably keep track of key rollovers and update the
+ trust anchor manually. However, with an increasing number of trust
+ anchors all rolled according to individual policies that are all
+ published through different channels this soon becomes an
+ unmanageable problem.
+
+
+2.1 Dangers of Stale Trust Anchors
+
+
+ Whenever a SEP key at a security apex is rolled there exists a danger
+ that "stale anchors" are created. A stale anchor is a trust anchor
+ (i.e. a public key configured in a validating resolver) that relates
+ to a private key that is no longer used for signing.
+
+
+ The problem with a stale anchors is that they will (from the
+ validating resolvers point of view) prove data to be false even
+ though it is actually correct. This is because the data is either
+ signed by a new key or is no longer signed and the resolver expects
+ data to be signed by the old (now stale) key.
+
+
+ This situation is arguably worse than not having a trusted key
+ configured for the secure entry point, since with a stale key no
+ lookup is typically possible (presuming that the default
+ configuration of a validating recursive nameserver is to not give out
+ data that is signed but failed to verify.
+
+
+ The danger of making configured trust anchors become stale anchors
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 5]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ may be a reason for zone owners not to roll their keys. If a
+ resolver is configured with many trust anchors that need manual
+ maintenance it may be easy to not notice a key rollover at a security
+ apex, resulting in a stale anchor.
+
+
+ In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
+ track key rollovers and modify the configured trust anchors
+ accordingly. The mechanism is stateless and does not need protocol
+ extensions. The proposed design is that this mechanism is
+ implemented as a "trust updating machine" that is run entirely
+ separate from the validating resolver except that the trust updater
+ will have influence over the trust anchors used by the latter.
+
+
+ In Section 4 we describe a method [Editors note: for now only the
+ frame work and a set of requirements] to install trust anchors. This
+ method can be used at first configuration or when the trust anchors
+ became stale (typically due to a failure to track several rollover
+ events).
+
+
+ The choice for which domains trust anchors are to be configured is a
+ local policy issue. So is the choice which trust anchors has
+ prevalence if there are multiple chains of trust to a given piece of
+ DNS data (e.g. when a parent zone and its child both have trust
+ anchors configured). Both issues are out of the scope of this
+ document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 6]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+3. Threshold-based Trust Anchor Rollover
+
+
+3.1 The Rollover
+
+
+ When a key pair is replaced all signatures (in DNSSEC these are the
+ RRSIG records) created with the old key will be replaced by new
+ signatures created by the new key. Access to the new public key is
+ needed to verify these signatures.
+
+
+ Since zone signing keys are in "the middle" of a chain of authority
+ they can be verified using the signature made by a key signing key.
+ Rollover of zone signing keys is therefore transparent to validators
+ and requires no action in the validator end.
+
+
+ But if a key signing key is rolled a resolver can determine its
+ authenticity by either following the authorization chain from the
+ parents DS record, an out-of-DNS authentication mechanism or by
+ relying on other trust anchors known for the zone in which the key is
+ rolled.
+
+
+ The threshold trust anchor rollover mechanism (or trust update),
+ described below, is based on using existing trust anchors to verify a
+ subset of the available signatures. This is then used as the basis
+ for a decision to accept the new keys as valid trust anchors.
+
+
+ Our example pseudo zone below contains a number of key signing keys
+ numbered 1 through Y and two zone signing keys A and B. During a key
+ rollover key 2 is replaced by key Y+1. The zone content changes
+ from:
+
+
+ example.com. DNSKEY key1
+ example.com. DNSKEY key2
+ example.com. DNSKEY key3
+ ...
+ example.com. DNSKEY keyY
+
+
+ example.com. DNSKEY keyA
+ example.com. DNSKEY keyB
+
+
+ example.com. RRSIG DNSKEY ... (key1)
+ example.com. RRSIG DNSKEY ... (key2)
+ example.com. RRSIG DNSKEY ... (key3)
+ ...
+ example.com. RRSIG DNSKEY ... (keyY)
+ example.com. RRSIG DNSKEY ... (keyA)
+ example.com. RRSIG DNSKEY ... (keyB)
+
+
+ to:
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 7]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ example.com. DNSKEY key1
+ example.com. DNSKEY key3
+ ...
+ example.com. DNSKEY keyY
+ example.com. DNSKEY keyY+1
+
+
+ example.com. RRSIG DNSKEY ... (key1)
+ example.com. RRSIG DNSKEY ... (key3)
+ ...
+ example.com. RRSIG DNSKEY ... (keyY)
+ example.com. RRSIG DNSKEY ... (keyY+1)
+ example.com. RRSIG DNSKEY ... (keyA)
+ example.com. RRSIG DNSKEY ... (keyB)
+
+
+ When the rollover becomes visible to the verifying stub resolver it
+ will be able to verify the RRSIGs associated with key1, key3 ...
+ keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will
+ not be used for validation, since that key is previously unknown and
+ therefore not trusted.
+
+
+ Note that this example is simplified. Because of operational
+ considerations described in [5] having a period during which the two
+ key signing keys are both available is necessary.
+
+
+3.2 Threshold-based Trust Update
+
+
+ The threshold-based trust update algorithm applies as follows. If
+ for a particular secure entry point
+ o if the DNSKEY RRset in the zone has been replaced by a more recent
+ one (as determined by comparing the RRSIG inception dates)
+ and
+ o if at least M configured trust anchors directly verify the related
+ RRSIGs over the new DNSKEY RRset
+ and
+ o the number of configured trust anchors that verify the related
+ RRSIGs over the new DNSKEY RRset exceed a locally defined minimum
+ number that should be greater than one
+ then all the trust anchors for the particular secure entry point are
+ replaced by the set of keys from the zones DNSKEY RRset that have the
+ SEP flag set.
+
+
+ The choices for the rollover acceptance policy parameter M is left to
+ the administrator of the resolver. To be certain that a rollover is
+ accepted up by resolvers using this mechanism zone owners should roll
+ as few SEP keys at a time as possible (preferably just one). That
+ way they comply to the most strict rollover acceptance policy of
+ M=N-1.
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 8]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ The value of M has an upper bound, limited by the number of of SEP
+ keys a zone owner publishes (i.e. N). But there is also a lower
+ bound, since it will not be safe to base the trust in too few
+ signatures. The corner case is M=1 when any validating RRSIG will be
+ sufficient for a complete replacement of the trust anchors for that
+ secure entry point. This is not a recommended configuration, since
+ that will allow an attacker to initiate rollover of the trust anchors
+ himself given access to just one compromised key. Hence M should in
+ be strictly larger than 1 as shown by the third requirement above.
+
+
+ If the rollover acceptance policy is M=1 then the result for the
+ rollover in our example above should be that the local database of
+ trust anchors is updated by removing key "key2" from and adding key
+ "keyY+1" to the key store.
+
+
+3.3 Possible Trust Update States
+
+
+ We define five states for trust anchor configuration at the client
+ side.
+ PRIMING: There are no trust anchors configured. There may be priming
+ keys available for initial priming of trust anchors.
+ IN-SYNC: The set of trust anchors configured exactly matches the set
+ of SEP keys used by the zone owner to sign the zone.
+ OUT-OF-SYNC: The set of trust anchors is not exactly the same as the
+ set of SEP keys used by the zone owner to sign the zone but there
+ are enough SEP key in use by the zone owner that is also in the
+ trust anchor configuration.
+ UNSYNCABLE: There is not enough overlap between the configured trust
+ anchors and the set of SEP keys used to sign the zone for the new
+ set to be accepted by the validator (i.e. the number of
+ signatures that verify is not sufficient).
+ STALE: There is no overlap between the configured trust anchors and
+ the set of SEP keys used to sign the zone. Here validation of
+ data is no longer possible and hence we are in a situation where
+ the trust anchors are stale.
+
+
+ Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of
+ the automatic trust update mechanism. The PRIMING state is where a
+ validator is located before acquiring an up-to-date set of trust
+ anchors. The transition from PRIMING to IN-SYNC is manual (see
+ Section 4 below).
+
+
+ Example: assume a secure entry point with four SEP keys and a
+ validator with the policy that it will accept any update to the set
+ of trust anchors as long as no more than two signatures fail to
+ validate (i.e. M >= N-2) and at least two signature does validate
+ (i.e. M >= 2). In this case the rollover of a single key will move
+ the validator from IN-SYNC to OUT-OF-SYNC. When the trust update
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 9]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ state machine updates the trust anchors it returns to state IN-SYNC.
+
+
+ If if for some reason it fails to update the trust anchors then the
+ next rollover (of a different key) will move the validator from
+ OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys
+ that are configured as trust anchors and that is sufficient to accpt
+ an automatic update of the trust anchors.
+
+
+ The UNSYNCABLE state is where a validator is located if it for some
+ reason fails to incorporate enough updates to the trust anchors to be
+ able to accept new updates according to its local policy. In this
+ example (i.e. with the policy specified above) this will either be
+ because M < N-2 or M < 2, which does not suffice to authenticate a
+ successful update of trust anchors.
+
+
+ Continuing with the previous example where two of the four SEP keys
+ have already rolled, but the validator has failed to update the set
+ of trust anchors. When the third key rolls over there will only be
+ one trust anchor left that can do successful validation. This is not
+ sufficient to enable automatic update of the trust anchors, hence the
+ new state is UNSYNCABLE. Note, however, that the remaining
+ up-to-date trust anchor is still enough to do successful validation
+ so the validator is still "working" from a DNSSEC point of view.
+
+
+ The STALE state, finally, is where a validator ends up when it has
+ zero remaining current trust anchors. This is a dangerous state,
+ since the stale trust anchors will cause all validation to fail. The
+ escape is to remove the stale trust anchors and thereby revert to the
+ PRIMING state.
+
+
+3.4 Implementation notes
+
+
+ The DNSSEC protocol specification ordains that a DNSKEY to which a DS
+ record points should be self-signed. Since the keys that serve as
+ trust anchors and the keys that are pointed to by DS records serve
+ the same purpose, they are both secure entry points, we RECOMMEND
+ that zone owners who want to facilitate the automated rollover scheme
+ documented herein self-sign DNSKEYs with the SEP bit set and that
+ implementation check that DNSKEYs with the SEP bit set are
+ self-signed.
+
+
+ In order to maintain a uniform way of determining that a keyset in
+ the zone has been replaced by a more recent set the automatic trust
+ update machine SHOULD only accept new DNSKEY RRsets if the
+ accompanying RRSIGs show a more recent inception date than the
+ present set of trust anchors. This is also needed as a safe guard
+ against possible replay attacks where old updates are replayed
+ "backwards" (i.e. one change at a time, but going in the wrong
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 10]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ direction, thereby luring the validator into the UNSYNCABLE and
+ finally STALE states).
+
+
+ In order to be resilient against failures the implementation should
+ collect the DNSKEY RRsets from (other) authoritative servers if
+ verification of the self signatures fails.
+
+
+ The threshold-based trust update mechanism SHOULD only be applied to
+ algorithms, as represented in the algorithm field in the DNSKEY/RRSIG
+ [3], that the resolver is aware of. In other words the SEP keys of
+ unknown algorithms should not be used when counting the number of
+ available signatures (the N constant) and the SEP keys of unknown
+ algorithm should not be entered as trust anchors.
+
+
+ When in state UNSYNCABLE or STALE manual intervention will be needed
+ to return to the IN-SYNC state. These states should be flagged. The
+ most appropriate action is human audit possibly followed by
+ re-priming (Section 4) the keyset (i.e. manual transfer to the
+ PRIMING state through removal of the configured trust anchors).
+
+
+ An implementation should regularly probe the the authoritative
+ nameservers for new keys. Since there is no mechanism to publish
+ rollover frequencies this document RECOMMENDS zone owners not to roll
+ their key signing keys more often than once per month and resolver
+ administrators to probe for key rollsovers (and apply the threshold
+ criterion for acceptance of trust update) not less often than once
+ per month. If the rollover frequency is higher than the probing
+ frequency then trust anchors may become stale. The exact relation
+ between the frequencies depends on the number of SEP keys rolled by
+ the zone owner and the value M configured by the resolver
+ administrator.
+
+
+ In all the cases below a transaction where the threshold criterion is
+ not satisfied should be considered bad (i.e. possibly spoofed or
+ otherwise corrupted data). The most appropriate action is human
+ audit.
+
+
+ There is one case where a "bad" state may be escaped from in an
+ automated fashion. This is when entering the STALE state where all
+ DNSSEC validation starts to fail. If this happens it is concievable
+ that it is better to completely discard the stale trust anchors
+ (thereby reverting to the PRIMING state where validation is not
+ possible). A local policy that automates removal of stale trust
+ anchors is therefore suggested.
+
+
+3.5 Possible transactions
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 11]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+3.5.1 Single DNSKEY replaced
+
+
+ This is probably the most typical transaction on the zone owners
+ part. The result should be that if the threshold criterion is
+ satisfied then the key store is updated by removal of the old trust
+ anchor and addition of the new key as a new trust anchor. Note that
+ if the DNSKEY RRset contains exactly M keys replacement of keys is
+ not possible, i.e. for automatic rollover to work M must be stricly
+ less than N.
+
+
+3.5.2 Addition of a new DNSKEY (no removal)
+
+
+ If the threshold criterion is satisfied then the new key is added as
+ a configured trust anchor. Not more than N-M keys can be added at
+ once, since otherwise the algorithm will fail.
+
+
+3.5.3 Removal of old DNSKEY (no addition)
+
+
+ If the threshold criterion is satisfied then the old key is removed
+ from being a configured trust anchor. Note that it is not possible
+ to reduce the size of the DNSKEY RRset to a size smaller than the
+ minimum required value for M.
+
+
+3.5.4 Multiple DNSKEYs replaced
+
+
+ Arguably it is not a good idea for the zone administrator to replace
+ several keys at the same time, but from the resolver point of view
+ this is exactly what will happen if the validating resolver for some
+ reason failed to notice a previous rollover event.
+
+
+ Not more than N-M keys can be replaced at one time or the threshold
+ criterion will not be satisfied. Or, expressed another way: as long
+ as the number of changed keys is less than or equal to N-M the
+ validator is in state OUT-OF-SYNC. When the number of changed keys
+ becomes greater than N-M the state changes to UNSYNCABLE and manual
+ action is needed.
+
+
+3.6 Removal of trust anchors for a trust point
+
+
+ If the parent of a secure entry point gets signed and it's trusted
+ keys get configured in the key store of the validating resolver then
+ the configured trust anchors for the child should be removed entirely
+ unless explicitly configured (in the utility configuration) to be an
+ exception.
+
+
+ The reason for such a configuration would be that the resolver has a
+ local policy that requires maintenance of trusted keys further down
+ the tree hierarchy than strictly needed from the point of view.
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 12]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ The default action when the parent zone changes from unsigned to
+ signed should be to remove the configured trust anchors for the
+ child. This form of "garbage collect" will ensure that the automatic
+ rollover machinery scales as DNSSEC deployment progresses.
+
+
+3.7 No need for resolver-side overlap of old and new keys
+
+
+ It is worth pointing out that there is no need for the resolver to
+ keep state about old keys versus new keys, beyond the requirement of
+ tracking signature inception time for the covering RRSIGs as
+ described in Section 3.4.
+
+
+ From the resolver point of view there are only trusted and not
+ trusted keys. The reason is that the zone owner needs to do proper
+ maintenance of RRSIGs regardless of the resolver rollover mechanism
+ and hence must ensure that no key rolled out out the DNSKEY set until
+ there cannot be any RRSIGs created by this key still legally cached.
+
+
+ Hence the rollover mechanism is entirely stateless with regard to the
+ keys involved: as soon as the resolver (or in this case the rollover
+ tracking utility) detects a change in the DNSKEY RRset (i.e. it is
+ now in the state OUT-OF-SYNC) with a sufficient number of matching
+ RRSIGs the configured trust anchors are immediately updated (and
+ thereby the machine return to state IN-SYNC). I.e. the rollover
+ machine changes states (mostly oscillating between IN-SYNC and
+ OUT-OF-SYNC), but the status of the DNSSEC keys is stateless.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 13]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+4. Bootstrapping automatic rollovers
+
+
+ It is expected that with the ability to automatically roll trust
+ anchors at trust points will follow a diminished unwillingness to
+ roll these keys, since the risks associated with stale keys are
+ minimized.
+
+
+ The problem of "priming" the trust anchors, or bringing them into
+ sync (which could happen if a resolver is off line for a long period
+ in which a set of SEP keys in a zone 'evolve' away from its trust
+ anchor configuration) remains.
+
+
+ For (re)priming we can rely on out of band technology and we propose
+ the following framework.
+
+
+4.1 Priming Keys
+
+
+ If all the trust anchors roll somewhat frequently (on the order of
+ months or at most about a year) then it will not be possible to
+ design a device, or a software distribution that includes trust
+ anchors, that after being manufactured is put on a shelf for several
+ key rollover periods before being brought into use (since no trust
+ anchors that were known at the time of manufacture remain active).
+
+
+ To alleviate this we propose the concept of "priming keys". Priming
+ keys are ordinary DNSSEC Key Signing Keys with the characteristic
+ that
+ o The private part of a priming key signs the DNSKEY RRset at the
+ security apex, i.e. at least one RRSIG DNSKEY is created by a
+ priming key rather than by an "ordinary" trust anchor
+ o the public parts of priming keys are not included in the DNSKEY
+ RRset. Instead the public parts of priming keys are only
+ available out-of-band.
+ o The public parts of the priming keys have a validity period.
+ Within this period they can be used to obtain trust anchors.
+ o The priming key pairs are long lived (relative to the key rollover
+ period.)
+
+
+4.1.1 Bootstrapping trust anchors using a priming key
+
+
+ To install the trust anchors for a particular security apex an
+ administrator of a validating resolver will need to:
+ o query for the DNSKEY RRset of the zone at the security apex;
+ o verify the self signatures of all DNSKEYs in the RRset;
+ o verify the signature of the RRSIG made with a priming key --
+ verification using one of the public priming keys that is valid at
+ that moment is sufficient;
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 14]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ o create the trust anchors by extracting the DNSKEY RRs with the SEP
+ flag set.
+ The SEP keys with algorithms unknown to the validating resolver
+ SHOULD be ignored during the creation of the trust anchors.
+
+
+4.1.2 Distribution of priming keys
+
+
+ The public parts of the priming keys SHOULD be distributed
+ exclusively through out-of-DNS mechanisms. The requirements for a
+ distribution mechanism are:
+ o it can carry the "validity" period for the priming keys;
+ o it can carry the self-signature of the priming keys;
+ o and it allows for verification using trust relations outside the
+ DNS.
+ A distribution mechanism would benefit from:
+ o the availability of revocation lists;
+ o the ability of carrying zone owners policy information such as
+ recommended values for "M" and "N" and a rollover frequency;
+ o and the technology on which is based is readily available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 15]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+5. The Threshold Rollover Mechanism vs Priming
+
+
+ There is overlap between the threshold-based trust updater and the
+ Priming method. One could exclusively use the Priming method for
+ maintaining the trust anchors. However the priming method probably
+ relies on "non-DNS' technology and may therefore not be available for
+ all devices that have a resolver.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 16]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+6. Security Considerations
+
+
+6.1 Threshold-based Trust Update Security Considerations
+
+
+ A clear issue for resolvers will be how to ensure that they track all
+ rollover events for the zones they have configure trust anchors for.
+ Because of temporary outages validating resolvers may have missed a
+ rollover of a KSK. The parameters that determine the robustness
+ against failures are: the length of the period between rollovers
+ during which the KSK set is stable and validating resolvers can
+ actually notice the change; the number of available KSKs (i.e. N)
+ and the number of signatures that may fail to validate (i.e. N-M).
+
+
+ With a large N (i.e. many KSKs) and a small value of M this
+ operation becomes more robust since losing one key, for whatever
+ reason, will not be crucial. Unfortunately the choice for the number
+ of KSKs is a local policy issue for the zone owner while the choice
+ for the parameter M is a local policy issue for the resolver
+ administrator.
+
+
+ Higher values of M increase the resilience against attacks somewhat;
+ more signatures need to verify for a rollover to be approved. On the
+ other hand the number of rollover events that may pass unnoticed
+ before the resolver reaches the UNSYNCABLE state goes down.
+
+
+ The threshold-based trust update intentionally does not provide a
+ revocation mechanism. In the case that a sufficient number of
+ private keys of a zone owner are simultaneously compromised the the
+ attacker may use these private keys to roll the trust anchors of (a
+ subset of) the resolvers. This is obviously a bad situation but it
+ is not different from most other public keys systems.
+
+
+ However, it is important to point out that since any reasonable trust
+ anchor rollover policy (in validating resolvers) will require more
+ than one RRSIG to validate this proposal does provide security
+ concious zone administrators with the option of not storing the
+ individual private keys in the same location and thereby decreasing
+ the likelihood of simultaneous compromise.
+
+
+6.2 Priming Key Security Considerations
+
+
+ Since priming keys are not included in the DNSKEY RR set they are
+ less sensitive to packet size constraints and can be chosen
+ relatively large. The private parts are only needed to sign the
+ DNSKEY RR set during the validity period of the particular priming
+ key pair. Note that the private part of the priming key is used each
+ time when a DNSKEY RRset has to be resigned. In practice there is
+ therefore little difference between the usage pattern of the private
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 17]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ part of key signing keys and priming keys.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 18]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+7. IANA Considerations
+
+
+ NONE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 19]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+8. References
+
+
+8.1 Normative References
+
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+ [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
+ (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+ RFC 3757, May 2004.
+
+
+ [3] Arends, R., "Resource Records for the DNS Security Extensions",
+ draft-ietf-dnsext-dnssec-records-10 (work in progress),
+ September 2004.
+
+
+8.2 Informative References
+
+
+ [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
+ "DNS Security Introduction and Requirements",
+ draft-ietf-dnsext-dnssec-intro-12 (work in progress), September
+ 2004.
+
+
+ [5] Kolkman, O., "DNSSEC Operational Practices",
+ draft-ietf-dnsop-dnssec-operational-practices-01 (work in
+ progress), May 2004.
+
+
+ [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
+ Public Key Infrastructure Certificate and CRL Profile", RFC
+ 2459, January 1999.
+
+
+
+Authors' Addresses
+
+
+ Johan Ihren
+ Autonomica AB
+ Bellmansgatan 30
+ Stockholm SE-118 47
+ Sweden
+
+
+ EMail: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 20]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ Olaf M. Kolkman
+ RIPE NCC
+ Singel 256
+ Amsterdam 1016 AB
+ NL
+
+
+ Phone: +31 20 535 4444
+ EMail: olaf@ripe.net
+ URI: http://www.ripe.net/
+
+
+
+ Bill Manning
+ EP.net
+ Marina del Rey, CA 90295
+ USA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 21]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+Appendix A. Acknowledgments
+
+
+ The present design for in-band automatic rollovers of DNSSEC trust
+ anchors is the result of many conversations and it is no longer
+ possible to remember exactly who contributed what.
+
+
+ In addition we've also had appreciated help from (in no particular
+ order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
+ Larson and Mark Kosters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 22]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+Appendix B. Document History
+
+
+ This appendix will be removed if and when the document is submitted
+ to the RFC editor.
+
+
+ The version you are reading is tagged as $Revision: 1.1 $.
+
+
+ Text between square brackets, other than references, are editorial
+ comments and will be removed.
+
+
+B.1 prior to version 00
+
+
+ This draft was initially published as a personal submission under the
+ name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt.
+
+
+ Kolkman documented the ideas provided by Ihren and Manning. In the
+ process of documenting (and prototyping) Kolkman changed some of the
+ details of the M-N algorithms working. Ihren did not have a chance
+ to review the draft before Kolkman posted;
+
+
+ Kolkman takes responsibilities for omissions, fuzzy definitions and
+ mistakes.
+
+
+B.2 version 00
+ o The name of the draft was changed as a result of the draft being
+ adopted as a working group document.
+ o A small section on the concept of stale trust anchors was added.
+ o The different possible states are more clearly defined, including
+ examples of transitions between states.
+ o The terminology is changed throughout the document. The old term
+ "M-N" is replaced by "threshold" (more or less). Also the
+ interpretation of the constants M and N is significantly
+ simplified to bring the usage more in line with "standard"
+ threshold terminlogy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 23]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+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.
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 24] \ No newline at end of file
generated by cgit (git 2.34.1) at 2024-04-26 02:27:49 +0000