Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/dist/bind/doc/draft/draft-ietf-dnsext-trustupda...

1501 lines
42 KiB
Plaintext
Raw Blame History

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.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]
Reference in New Issue View Git Blame Copy Permalink