731 lines
27 KiB
Plaintext
731 lines
27 KiB
Plaintext
|
||
|
||
|
||
|
||
Network Working Group M. StJohns
|
||
Internet-Draft Nominum, Inc.
|
||
Expires: February 16, 2006 August 15, 2005
|
||
|
||
|
||
Automated Updates of DNSSEC Trust Anchors
|
||
draft-ietf-dnsext-trustupdate-timers-01
|
||
|
||
Status of this Memo
|
||
|
||
By submitting this Internet-Draft, each author represents that any
|
||
applicable patent or other IPR claims of which he or she is aware
|
||
have been or will be disclosed, and any of which he or she becomes
|
||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||
|
||
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 February 16, 2006.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2005).
|
||
|
||
Abstract
|
||
|
||
This document describes a means for automated, authenticated and
|
||
authorized updating of DNSSEC "trust anchors". The method provides
|
||
protection against single key compromise of a key in the trust point
|
||
key set. Based on the trust established by the presence of a current
|
||
anchor, other anchors may be added at the same place in the
|
||
hierarchy, and, ultimately, supplant the existing anchor.
|
||
|
||
This mechanism, if adopted, will require changes to resolver
|
||
management behavior (but not resolver resolution behavior), and the
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 1]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
addition of a single flag bit to the DNSKEY record.
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
|
||
1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
|
||
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
|
||
2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4
|
||
2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
|
||
2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
|
||
2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
|
||
2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
|
||
2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
|
||
2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6
|
||
3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
|
||
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||
5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8
|
||
5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
|
||
5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
|
||
5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9
|
||
5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9
|
||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
|
||
6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
|
||
6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
|
||
6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10
|
||
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
|
||
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
|
||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
|
||
Intellectual Property and Copyright Statements . . . . . . . . 12
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 2]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
1. Introduction
|
||
|
||
As part of the reality of fielding DNSSEC (Domain Name System
|
||
Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
|
||
community has come to the realization that there will not be one
|
||
signed name space, but rather islands of signed name space each
|
||
originating from specific points (i.e. 'trust points') in the DNS
|
||
tree. Each of those islands will be identified by the trust point
|
||
name, and validated by at least one associated public key. For the
|
||
purpose of this document we'll call the association of that name and
|
||
a particular key a 'trust anchor'. A particular trust point can have
|
||
more than one key designated as a trust anchor.
|
||
|
||
For a DNSSEC-aware resolver to validate information in a DNSSEC
|
||
protected branch of the hierarchy, it must have knowledge of a trust
|
||
anchor applicable to that branch. It may also have more than one
|
||
trust anchor for any given trust point. Under current rules, a chain
|
||
of trust for DNSSEC-protected data that chains its way back to ANY
|
||
known trust anchor is considered 'secure'.
|
||
|
||
Because of the probable balkanization of the DNSSEC tree due to
|
||
signing voids at key locations, a resolver may need to know literally
|
||
thousands of trust anchors to perform its duties. (e.g. Consider an
|
||
unsigned ".COM".) Requiring the owner of the resolver to manually
|
||
manage this many relationships is problematic. It's even more
|
||
problematic when considering the eventual requirement for key
|
||
replacement/update for a given trust anchor. The mechanism described
|
||
herein won't help with the initial configuration of the trust anchors
|
||
in the resolvers, but should make trust point key replacement/
|
||
rollover more viable.
|
||
|
||
As mentioned above, this document describes a mechanism whereby a
|
||
resolver can update the trust anchors for a given trust point, mainly
|
||
without human intervention at the resolver. There are some corner
|
||
cases discussed (e.g. multiple key compromise) that may require
|
||
manual intervention, but they should be few and far between. This
|
||
document DOES NOT discuss the general problem of the initial
|
||
configuration of trust anchors for the resolver.
|
||
|
||
1.1 Compliance Nomenclature
|
||
|
||
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 BCP 14, [RFC2119].
|
||
|
||
1.2 Changes since -00
|
||
|
||
Added the concept of timer triggered resolver queries to refresh the
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 3]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
resolvers view of the trust anchor key RRSet.
|
||
|
||
Re-submitted expired draft as -01. Updated DNSSEC RFC References.
|
||
|
||
2. Theory of Operation
|
||
|
||
The general concept of this mechanism is that existing trust anchors
|
||
can be used to authenticate new trust anchors at the same point in
|
||
the DNS hierarchy. When a new SEP key is added to a trust point
|
||
DNSKEY RRSet, and when that RRSet is validated by an existing trust
|
||
anchor, then the new key can be added to the set of trust anchors.
|
||
|
||
There are some issues with this approach which need to be mitigated.
|
||
For example, a compromise of one of the existing keys could allow an
|
||
attacker to add their own 'valid' data. This implies a need for a
|
||
method to revoke an existing key regardless of whether or not that
|
||
key is compromised. As another example assuming a single key
|
||
compromise, an attacker could add a new key and revoke all the other
|
||
old keys.
|
||
|
||
2.1 Revocation
|
||
|
||
Assume two trust anchor keys A and B. Assume that B has been
|
||
compromised. Without a specific revocation bit, B could invalidate A
|
||
simply by sending out a signed trust point key set which didn't
|
||
contain A. To fix this, we add a mechanism which requires knowledge
|
||
of the private key of a DNSKEY to revoke that DNSKEY.
|
||
|
||
A key is considered revoked when the resolver sees the key in a self-
|
||
signed RRSet and the key has the REVOKE bit set to '1'. Once the
|
||
resolver sees the REVOKE bit, it MUST NOT use this key as a trust
|
||
anchor or for any other purposes except validating the RRSIG over the
|
||
DNSKEY RRSet specifically for the purpose of validating the
|
||
revocation. Unlike the 'Add' operation below, revocation is
|
||
immediate and permanent upon receipt of a valid revocation at the
|
||
resolver.
|
||
|
||
N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
|
||
than one without the bit set. This affects the matching of a DNSKEY
|
||
to DS records in the parent, or the fingerprint stored at a resolver
|
||
used to configure a trust point. [msj3]
|
||
|
||
In the given example, the attacker could revoke B because it has
|
||
knowledge of B's private key, but could not revoke A.
|
||
|
||
2.2 Add Hold-Down
|
||
|
||
Assume two trust point keys A and B. Assume that B has been
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 4]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
compromised. An attacker could generate and add a new trust anchor
|
||
key - C (by adding C to the DNSKEY RRSet and signing it with B), and
|
||
then invalidate the compromised key. This would result in the both
|
||
the attacker and owner being able to sign data in the zone and have
|
||
it accepted as valid by resolvers.
|
||
|
||
To mitigate, but not completely solve, this problem, we add a hold-
|
||
down time to the addition of the trust anchor. When the resolver
|
||
sees a new SEP key in a validated trust point DNSKEY RRSet, the
|
||
resolver starts an acceptance timer, and remembers all the keys that
|
||
validated the RRSet. If the resolver ever sees the DNSKEY RRSet
|
||
without the new key but validly signed, it stops the acceptance
|
||
process and resets the acceptance timer. If all of the keys which
|
||
were originally used to validate this key are revoked prior to the
|
||
timer expiring, the resolver stops the acceptance process and resets
|
||
the timer.
|
||
|
||
Once the timer expires, the new key will be added as a trust anchor
|
||
the next time the validated RRSet with the new key is seen at the
|
||
resolver. The resolver MUST NOT treat the new key as a trust anchor
|
||
until the hold down time expires AND it has retrieved and validated a
|
||
DNSKEY RRSet after the hold down time which contains the new key.
|
||
|
||
N.B.: Once the resolver has accepted a key as a trust anchor, the key
|
||
MUST be considered a valid trust anchor by that resolver until
|
||
explictly revoked as described above.
|
||
|
||
In the given example, the zone owner can recover from a compromise by
|
||
revoking B and adding a new key D and signing the DNSKEY RRSet with
|
||
both A and B.
|
||
|
||
The reason this does not completely solve the problem has to do with
|
||
the distributed nature of DNS. The resolver only knows what it sees.
|
||
A determined attacker who holds one compromised key could keep a
|
||
single resolver from realizing that key had been compromised by
|
||
intercepting 'real' data from the originating zone and substituting
|
||
their own (e.g. using the example, signed only by B). This is no
|
||
worse than the current situation assuming a compromised key.
|
||
|
||
2.3 Remove Hold-down
|
||
|
||
A new key which has been seen by the resolver, but hasn't reached
|
||
it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
|
||
zone owner. If the resolver sees a validated DNSKEY RRSet without
|
||
this key, it waits for the remove hold-down time and then, if the key
|
||
hasn't reappeared, SHOULD discard any information about the key.
|
||
|
||
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 5]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
2.4 Active Refresh
|
||
|
||
A resolver which has been configured for automatic update of keys
|
||
from a particular trust point MUST query that trust point (e.g. do a
|
||
lookup for the DNSKEY RRSet and related RRSIG records) no less often
|
||
than the lesser of 15 days or half the original TTL for the DNSKEY
|
||
RRSet or half the RRSIG expiration interval. The expiration interval
|
||
is the amount of time from when the RRSIG was last retrieved until
|
||
the expiration time in the RRSIG.
|
||
|
||
If the query fails, the resolver MUST repeat the query until
|
||
satisfied no more often than once an hour and no less often than the
|
||
lesser of 1 day or 10% of the original TTL or 10% of the original
|
||
expiration interval.
|
||
|
||
2.5 Resolver Parameters
|
||
|
||
2.5.1 Add Hold-Down Time
|
||
|
||
The add hold-down time is 30 days or the expiration time of the TTL
|
||
of the first trust point DNSKEY RRSet which contained the key,
|
||
whichever is greater. This ensures that at least two validated
|
||
DNSKEY RRSets which contain the new key MUST be seen by the resolver
|
||
prior to the key's acceptance.
|
||
|
||
2.5.2 Remove Hold-Down Time
|
||
|
||
The remove hold-down time is 30 days.
|
||
|
||
2.5.3 Minimum Trust Anchors per Trust Point
|
||
|
||
A compliant resolver MUST be able to manage at least five SEP keys
|
||
per trust point.
|
||
|
||
3. Changes to DNSKEY RDATA Wire Format
|
||
|
||
Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
|
||
flag. If this bit is set to '1', AND the resolver sees an
|
||
RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
|
||
consider this key permanently invalid for all purposes except for
|
||
validing the revocation.
|
||
|
||
4. State Table
|
||
|
||
The most important thing to understand is the resolver's view of any
|
||
key at a trust point. The following state table describes that view
|
||
at various points in the key's lifetime. The table is a normative
|
||
part of this specification. The initial state of the key is 'Start'.
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 6]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
The resolver's view of the state of the key changes as various events
|
||
occur.
|
||
|
||
[msj1] This is the state of a trust point key as seen from the
|
||
resolver. The column on the left indicates the current state. The
|
||
header at the top shows the next state. The intersection of the two
|
||
shows the event that will cause the state to transition from the
|
||
current state to the next.
|
||
|
||
NEXT STATE
|
||
--------------------------------------------------
|
||
FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
|
||
----------------------------------------------------------
|
||
Start | |NewKey | | | | |
|
||
----------------------------------------------------------
|
||
AddPend |KeyRem | |AddTime| | |
|
||
----------------------------------------------------------
|
||
Valid | | | |KeyRem |Revbit | |
|
||
----------------------------------------------------------
|
||
Missing | | |KeyPres| |Revbit | |
|
||
----------------------------------------------------------
|
||
Revoked | | | | | |RemTime|
|
||
----------------------------------------------------------
|
||
Removed | | | | | | |
|
||
----------------------------------------------------------
|
||
|
||
|
||
4.1 Events
|
||
NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
|
||
That key will become a new trust anchor for the named trust point
|
||
after its been present in the RRSet for at least 'add time'.
|
||
KeyPres The key has returned to the valid DNSKEY RRSet.
|
||
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
|
||
this key.
|
||
AddTime The key has been in every valid DNSKEY RRSet seen for at
|
||
least the 'add time'.
|
||
RemTime A revoked key has been missing from the trust point DNSKEY
|
||
RRSet for sufficient time to be removed from the trust set.
|
||
RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
|
||
"REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
|
||
signed by this key.
|
||
|
||
4.2 States
|
||
Start The key doesn't yet exist as a trust anchor at the resolver.
|
||
It may or may not exist at the zone server, but hasn't yet been
|
||
seen at the resolver.
|
||
|
||
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 7]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
AddPend The key has been seen at the resolver, has its 'SEP' bit set,
|
||
and has been included in a validated DNSKEY RRSet. There is a
|
||
hold-down time for the key before it can be used as a trust
|
||
anchor.
|
||
Valid The key has been seen at the resolver and has been included in
|
||
all validated DNSKEY RRSets from the time it was first seen up
|
||
through the hold-down time. It is now valid for verifying RRSets
|
||
that arrive after the hold down time. Clarification: The DNSKEY
|
||
RRSet does not need to be continuously present at the resolver
|
||
(e.g. its TTL might expire). If the RRSet is seen, and is
|
||
validated (i.e. verifies against an existing trust anchor), this
|
||
key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
|
||
Missing This is an abnormal state. The key remains as a valid trust
|
||
point key, but was not seen at the resolver in the last validated
|
||
DNSKEY RRSet. This is an abnormal state because the zone operator
|
||
should be using the REVOKE bit prior to removal. [Discussion
|
||
item: Should a missing key be considered revoked after some
|
||
period of time?]
|
||
Revoked This is the state a key moves to once the resolver sees an
|
||
RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
|
||
this key with its REVOKE bit set to '1'. Once in this state, this
|
||
key MUST permanently be considered invalid as a trust anchor.
|
||
Removed After a fairly long hold-down time, information about this
|
||
key may be purged from the resolver. A key in the removed state
|
||
MUST NOT be considered a valid trust anchor.
|
||
|
||
5. Scenarios
|
||
|
||
The suggested model for operation is to have one active key and one
|
||
stand-by key at each trust point. The active key will be used to
|
||
sign the DNSKEY RRSet. The stand-by key will not normally sign this
|
||
RRSet, but the resolver will accept it as a trust anchor if/when it
|
||
sees the signature on the trust point DNSKEY RRSet.
|
||
|
||
Since the stand-by key is not in active signing use, the associated
|
||
private key may (and SHOULD) be provided with additional protections
|
||
not normally available to a key that must be used frequently. E.g.
|
||
locked in a safe, split among many parties, etc. Notionally, the
|
||
stand-by key should be less subject to compromise than an active key,
|
||
but that will be dependent on operational concerns not addressed
|
||
here.
|
||
|
||
5.1 Adding A Trust Anchor
|
||
|
||
Assume an existing trust anchor key 'A'.
|
||
1. Generate a new key pair.
|
||
|
||
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 8]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
2. Create a DNSKEY record from the key pair and set the SEP and Zone
|
||
Key bits.
|
||
3. Add the DNSKEY to the RRSet.
|
||
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
|
||
'A'.
|
||
5. Wait a while.
|
||
|
||
5.2 Deleting a Trust Anchor
|
||
|
||
Assume existing trust anchors 'A' and 'B' and that you want to revoke
|
||
and delete 'A'.
|
||
1. Set the revolcation bit on key 'A'.
|
||
2. Sign the DNSKEY RRSet with both 'A' and 'B'.
|
||
'A' is now revoked. The operator SHOULD include the revoked 'A' in
|
||
the RRSet for at least the remove hold-down time, but then may remove
|
||
it from the DNSKEY RRSet.
|
||
|
||
5.3 Key Roll-Over
|
||
|
||
Assume existing keys A and B. 'A' is actively in use (i.e. has been
|
||
signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
|
||
in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
|
||
used to sign the RRSet.)
|
||
1. Generate a new key pair 'C'.
|
||
2. Add 'C' to the DNSKEY RRSet.
|
||
3. Set the revocation bit on key 'A'.
|
||
4. Sign the RRSet with 'A' and 'B'.
|
||
'A' is now revoked, 'B' is now the active key, and 'C' will be the
|
||
stand-by key once the hold-down expires. The operator SHOULD include
|
||
the revoked 'A' in the RRSet for at least the remove hold-down time,
|
||
but may then remove it from the DNSKEY RRSet.
|
||
|
||
5.4 Active Key Compromised
|
||
|
||
This is the same as the mechanism for Key Roll-Over (Section 5.3)
|
||
above assuming 'A' is the active key.
|
||
|
||
5.5 Stand-by Key Compromised
|
||
|
||
Using the same assumptions and naming conventions as Key Roll-Over
|
||
(Section 5.3) above:
|
||
1. Generate a new key pair 'C'.
|
||
2. Add 'C' to the DNSKEY RRSet.
|
||
3. Set the revocation bit on key 'B'.
|
||
4. Sign the RRSet with 'A' and 'B'.
|
||
'B' is now revoked, 'A' remains the active key, and 'C' will be the
|
||
stand-by key once the hold-down expires. 'B' SHOULD continue to be
|
||
included in the RRSet for the remove hold-down time.
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 9]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
6. Security Considerations
|
||
|
||
6.1 Key Ownership vs Acceptance Policy
|
||
|
||
The reader should note that, while the zone owner is responsible
|
||
creating and distributing keys, it's wholly the decision of the
|
||
resolver owner as to whether to accept such keys for the
|
||
authentication of the zone information. This implies the decision
|
||
update trust anchor keys based on trust for a current trust anchor
|
||
key is also the resolver owner's decision.
|
||
|
||
The resolver owner (and resolver implementers) MAY choose to permit
|
||
or prevent key status updates based on this mechanism for specific
|
||
trust points. If they choose to prevent the automated updates, they
|
||
will need to establish a mechanism for manual or other out-of-band
|
||
updates outside the scope of this document.
|
||
|
||
6.2 Multiple Key Compromise
|
||
|
||
This scheme permits recovery as long as at least one valid trust
|
||
anchor key remains uncompromised. E.g. if there are three keys, you
|
||
can recover if two of them are compromised. The zone owner should
|
||
determine their own level of comfort with respect to the number of
|
||
active valid trust anchors in a zone and should be prepared to
|
||
implement recovery procedures once they detect a compromise. A
|
||
manual or other out-of-band update of all resolvers will be required
|
||
if all trust anchor keys at a trust point are compromised.
|
||
|
||
6.3 Dynamic Updates
|
||
|
||
Allowing a resolver to update its trust anchor set based in-band key
|
||
information is potentially less secure than a manual process.
|
||
However, given the nature of the DNS, the number of resolvers that
|
||
would require update if a trust anchor key were compromised, and the
|
||
lack of a standard management framework for DNS, this approach is no
|
||
worse than the existing situation.
|
||
|
||
7. Normative References
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
|
||
RFC 2535, March 1999.
|
||
|
||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "DNS Security Introduction and Requirements",
|
||
RFC 4033, March 2005.
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 10]
|
||
|
||
Internet-Draft trustanchor-update August 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.
|
||
|
||
Editorial Comments
|
||
|
||
[msj1] msj: N.B. This table is preliminary and will be revised to
|
||
match implementation experience. For example, should there
|
||
be a state for "Add hold-down expired, but haven't seen the
|
||
new RRSet"?
|
||
|
||
[msj2] msj: To be assigned.
|
||
|
||
[msj3] msj: For discussion: What's the implementation guidance for
|
||
resolvers currently with respect to the non-assigned flag
|
||
bits? If they consider the flag bit when doing key matching
|
||
at the trust anchor, they won't be able to match.
|
||
|
||
|
||
Author's Address
|
||
|
||
Michael StJohns
|
||
Nominum, Inc.
|
||
2385 Bay Road
|
||
Redwood City, CA 94063
|
||
USA
|
||
|
||
Phone: +1-301-528-4729
|
||
Email: Mike.StJohns@nominum.com
|
||
URI: www.nominum.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 11]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
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.
|
||
|
||
The IETF has been notified of intellectual property rights claimed in
|
||
regard to some or all of the specification contained in this
|
||
document. For more information consult the online list of claimed
|
||
rights.
|
||
|
||
|
||
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 (2005). 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.
|
||
|
||
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 12]
|
||
|
||
Internet-Draft trustanchor-update August 2005
|
||
|
||
|
||
Acknowledgment
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
StJohns Expires February 16, 2006 [Page 13]
|
||
|
||
|