mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 06:25:31 +00:00
Code Issues Releases Wiki Activity

cleanup

Browse Source
This commit is contained in:
Mark Andrews
2009-11-19 05:34:56 +00:00
parent 6b5b1d74a4
commit fad04ffe23
17 changed files with 4311 additions and 12968 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1501
doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
View File

File diff suppressed because it is too large Load Diff

729
doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt
View File

@@ -1,729 +0,0 @@
Network Working Group M. StJohns
Internet-Draft Nominum, Inc.
Intended status: Informational November 29, 2006
Expires: June 2, 2007
Automated Updates of DNSSEC Trust Anchors
draft-ietf-dnsext-trustupdate-timers-05
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 June 2, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a means for automated, authenticated and
authorized updating of DNSSEC "trust anchors". The method provides
protection against N-1 key compromises of N keys 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(s).
This mechanism will require changes to resolver management behavior
StJohns Expires June 2, 2007 [Page 1]
Internet-Draft trustanchor-update November 2006
(but not resolver resolution behavior), and the addition of a single
flag bit to the DNSKEY record.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
2.4.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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8
6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9
6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9
6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10
6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11
8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
StJohns Expires June 2, 2007 [Page 2]
Internet-Draft trustanchor-update November 2006
1. Introduction
As part of the reality of fielding DNSSEC (Domain Name System
Security Extensions) [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].
StJohns Expires June 2, 2007 [Page 3]
Internet-Draft trustanchor-update November 2006
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 zone operator adds a new SEP key (i.e. a
DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section
2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
validated by an existing trust anchor, then the resolver can add the
new key to its valid set of trust anchors for that trust point.
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, we need to prevent an attacker from adding a new key and
revoking 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 (see Section 7 below) 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 it signed 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.
A self-signed RRSet is a DNSKEY RRSet which contains the specific
DNSKEY and for which there is a corresponding validated RRSIG record.
It's not a special DNSKEY RRSet, just a way of describing the
validation requirements for that RRSet.
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.
In the given example, the attacker could revoke B because it has
knowledge of B's private key, but could not revoke A.
StJohns Expires June 2, 2007 [Page 4]
Internet-Draft trustanchor-update November 2006
2.2. Add Hold-Down
Assume two trust point keys A and B. Assume that B has been
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 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 for that
key 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. 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
StJohns Expires June 2, 2007 [Page 5]
Internet-Draft trustanchor-update November 2006
RRSet or half the RRSIG expiration interval and no more often than
once per hour. 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. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 *
origTTL, .1 * expireInterval)).
2.4. Resolver Parameters
2.4.1. Add Hold-Down Time
The add hold-down time is 30 days or the expiration time of the
original TTL of the first trust point DNSKEY RRSet which contained
the new 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.4.2. Remove Hold-Down Time
The remove hold-down time is 30 days. This parameter is solely a key
management database bookeeping parameter. Failure to remove
information about the state of defunct keys from the database will
not adversely impact the security of this protocol, but may end up
with a database cluttered with obsolete key information.
2.4.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
validating 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
StJohns Expires June 2, 2007 [Page 6]
Internet-Draft trustanchor-update November 2006
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'.
The resolver's view of the state of the key changes as various events
occur.
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 | | | | | | |
----------------------------------------------------------
State Table
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 it's 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.
StJohns Expires June 2, 2007 [Page 7]
Internet-Draft trustanchor-update November 2006
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 either hasn't yet
been seen at the resolver or was seen but was absent from the last
DNSKEY RRSet (e.g. KeyRem event).
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.
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. (Note: this state is
more or less equivalent to the "Start" state, except that it's bad
practice to re-introduce previously used keys - think of this as
the holding state for all the old keys for which the resolver no
longer needs to track state.)
5. Trust Point Deletion
A trust point which has all of its trust anchors revoked is
considered deleted and is treated as if the trust point was never
configured. If there are no superior configured trust points, data
at and below the deleted trust point are considered insecure by the
resolver. If there ARE superior configured trust points, data at and
below the deleted trust point are evaluated with respect to the
superior trust point(s).
Alternately, a trust point which is subordinate to another configured
trust point MAY be deleted by a resolver after 180 days where such
subordinate trust point validly chains to a superior trust point.
The decision to delete the subordinate trust anchor is a local
StJohns Expires June 2, 2007 [Page 8]
Internet-Draft trustanchor-update November 2006
configuration decision. Once the subordinate trust point is deleted,
validation of the subordinate zone is dependent on validating the
chain of trust to the superior trust point.
6. Scenarios - Informative
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.
6.1. Adding a Trust Anchor
Assume an existing trust anchor key 'A'.
1. Generate a new key pair.
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 (i.e. for various resolvers timers to go off and for
them to retrieve the new DNSKEY RRSet and signatures).
6. The new trust anchor will be populated at the resolvers on the
schedule described by the state table and update algorithm - see
Section 2 above
6.2. Deleting a Trust Anchor
Assume existing trust anchors 'A' and 'B' and that you want to revoke
and delete 'A'.
1. Set the revocation 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.
StJohns Expires June 2, 2007 [Page 9]
Internet-Draft trustanchor-update November 2006
6.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.
6.4. Active Key Compromised
This is the same as the mechanism for Key Roll-Over (Section 6.3)
above assuming 'A' is the active key.
6.5. Stand-by Key Compromised
Using the same assumptions and naming conventions as Key Roll-Over
(Section 6.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.
6.6. Trust Point Deletion
To delete a trust point which is subordinate to another configured
trust point (e.g. example.com to .com) requires some juggling of the
data. The specific process is:
1. Generate a new DNSKEY and DS record and provide the DS record to
the parent along with DS records for the old keys
2. Once the parent has published the DSs, add the new DNSKEY to the
RRSet and revoke ALL of the old keys at the same time while
signing the DNSKEY RRSet with all of the old and new keys.
3. After 30 days stop publishing the old, revoked keys and remove
any corresponding DS records in the parent.
Revoking the old trust point keys at the same time as adding new keys
that chain to a superior trust prevents the resolver from adding the
new keys as trust anchors. Adding DS records for the old keys avoids
a race condition where either the subordinate zone becomes unsecure
StJohns Expires June 2, 2007 [Page 10]
Internet-Draft trustanchor-update November 2006
(because the trust point was deleted) or becomes bogus (because it
didn't chain to the superior zone).
7. IANA Considerations
The IANA will need to assign a bit in the DNSKEY flags field (see
section 4.3 of [RFC3755]) for the REVOKE bit. There are no other
IANA actions required.
8. Security Considerations
In addition to the following sections, see also Theory of Operation
above and especially Section 2.2 for related discussions.
8.1. Key Ownership vs Acceptance Policy
The reader should note that, while the zone owner is responsible for
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 to
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.
8.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.
8.3. Dynamic Updates
Allowing a resolver to update its trust anchor set based on 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
StJohns Expires June 2, 2007 [Page 11]
Internet-Draft trustanchor-update November 2006
lack of a standard management framework for DNS, this approach is no
worse than the existing situation.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Editorial Comments
[msj2] msj: To be assigned.
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 June 2, 2007 [Page 12]
Internet-Draft trustanchor-update November 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
StJohns Expires June 2, 2007 [Page 13]

1063
doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
View File

File diff suppressed because it is too large Load Diff

1848
doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
View File

File diff suppressed because it is too large Load Diff

300
doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
View File

@@ -1,300 +0,0 @@
Internet Engineering Task Force A.Durand
INTERNET-DRAFT SUN Microsystems,inc.
November, 24, 2003 J. Ihren
Expires May 25, 2004 Autonomica
DNS IPv6 transport operational guidelines
<draft-ietf-dnsop-ipv6-transport-guidelines-01.txt>
Status of this Memo
This memo provides information to the Internet community. It does not
specify an Internet standard of any kind. This memo is in full
conformance with all provisions of Section 10 of RFC2026
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo provides guidelines and Best Current Practice to operate
DNS in a world where queries and responses are carried in a mixed
environment of IPv4 and IPv6 networks.
Acknowledgment
This document is the result of many conversations that happened in
the DNS community at IETF and elsewhere since 2001. During that
period of time, a number of Internet drafts have been published to
clarify various aspects of the issues at stake. This document focuses
on the conclusion of those discussions.
The authors would like to acknowledge the role of Pekka Savola in his
thorough review of the document.
1. Terminology
The phrase "IPv4 name server" indicates a name server available over
IPv4 transport. It does not imply anything about what DNS data is
served. Likewise, "IPv6 name server" indicates a name server
available over IPv6 transport. The phrase "dual-stack DNS server"
indicates a DNS server that is actually configured to run both
protocols, IPv4 and IPv6, and not merely a server running on a system
capable of running both but actually configured to run only one.
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 [2119].
2. Introduction to the Problem of Name Space Fragmentation:
following the referral chain
The caching resolver that tries to look up a name starts out at the
root, and follows referrals until it is referred to a nameserver that
is authoritative for the name. If somewhere down the chain of
referrals it is referred to a nameserver that is only accessible over
an unavailable type of transport, a traditional nameserver is unable
to finish the task.
When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
only a matter of time until this starts to happen. The complete DNS
hierarchy then starts to fragment into a graph where authoritative
nameservers for certain nodes are only accessible over a certain
transport. What is feared is that a node using only a particular
version of IP, querying information about another node using the same
version of IP can not do it because, somewhere in the chain of
servers accessed during the resolution process, one or more of them
will only be accessible with the other version of IP.
With all DNS data only available over IPv4 transport everything is
simple. IPv4 resolvers can use the intended mechanism of following
referrals from the root and down while IPv6 resolvers have to work
through a "translator", i.e. they have to use a second name server on
a so-called "dual stack" host as a "forwarder" since they cannot
access the DNS data directly.
With all DNS data only available over IPv6 transport everything would
be equally simple, with the exception of old legacy IPv4 name servers
having to switch to a forwarding configuration.
However, the second situation will not arise in a foreseeable time.
Instead, it is expected that the transition will be from IPv4 only to
a mixture of IPv4 and IPv6, with DNS data of theoretically three
categories depending on whether it is available only over IPv4
transport, only over IPv6 or both.
Having DNS data available on both transports is the best situation.
The major question is how to ensure that it as quickly as possible
becomes the norm. However, while it is obvious that some DNS data
will only be available over v4 transport for a long time it is also
obvious that it is important to avoid fragmenting the name space
available to IPv4 only hosts. I.e. during transition it is not
acceptable to break the name space that we presently have available
for IPv4-only hosts.
3. Policy Based Avoidance of Name Space Fragmentation
Today there are only a few DNS "zones" on the public Internet that
are available over IPv6 transport, and most of them can be regarded
as "experimental". However, as soon as the root and top level domains
are available over IPv6 transport, it is reasonable to expect that it
will become more common to have zones served by IPv6 servers.
Having those zones served only by IPv6-only name server would not be
a good development, since this will fragment the previously
unfragmented IPv4 name space and there are strong reasons to find a
mechanism to avoid it.
The RECOMMENDED approach to maintain name space continuity is to use
administrative policies, as described in the next section.
4. DNS IPv6 Transport RECOMMENDED Guidelines
In order to preserve name space continuity, the following administrative
policies are RECOMMENDED:
- every recursive DNS server SHOULD be either IPv4-only or dual
stack,
- every single DNS zone SHOULD be served by at least one IPv4
reachable DNS server.
This rules out IPv6-only DNS servers performing full recursion and
DNS zones served only by IPv6-only DNS servers. However, one could
very well design a configuration where a chain of IPv6 only DNS
servers forward queries to a set of dual stack DNS servers actually
performing those recursive queries. This approach could be revisited
if/when translation techniques between IPv4 and IPv6 were to be
widely deployed.
In order to help enforcing the second point, the optional operational
zone validation processes SHOULD ensure that there is at least one
IPv4 address record available for the name servers of any child
delegations within the zone.
5. Security Considerations
Being a critical piece of the Internet infrastructure, the DNS is a
potential value target and thus should be protected. Great care
should be taken not to weaken the security of DNS while introducing
IPv6 operation.
Keeping the DNS name space from fragmenting is a critical thing for
the availability and the operation of the Internet; this memo
addresses this issue by clear and simple operational guidelines.
The RECOMMENDED guidelines are compatible with the operation of
DNSSEC and do not introduce any new security issues.
6. Author Addresses
Alain Durand
SUN Microsystems, Inc
17 Network circle UMPK17-202
Menlo Park, CA, 94025
USA
Mail: Alain.Durand@sun.com
Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
Mail: johani@autonomica.se
7. Normative References
[2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8. Full Copyright Statement
"Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.

389
doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
View File

@@ -1,389 +0,0 @@
DNSOP G. Guette
Internet-Draft IRISA / INRIA
Expires: July 19, 2005 O. Courtay
Thomson R&D
January 18, 2005
Requirements for Automated Key Rollover in DNSSEC
draft-ietf-dnsop-key-rollover-requirements-02.txt
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 July 19, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes problems that appear during an automated
rollover and gives the requirements for the design of communication
between parent zone and child zone during an automated rollover
process. This document is essentially about in-band key rollover.
Guette & Courtay Expires July 19, 2005 [Page 1]
Internet-Draft Automated Rollover Requirements January 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
4. Messages authentication and information exchanged . . . . . . 5
5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
6. Security consideration . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
A. Documents details and changes . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Guette & Courtay Expires July 19, 2005 [Page 2]
Internet-Draft Automated Rollover Requirements January 2005
1. Introduction
The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
cryptography and digital signatures. It stores the public part of
keys in DNSKEY Resource Records (RRs). Because old keys and
frequently used keys are vulnerable, they must be renewed
periodically. In DNSSEC, this is the case for Zone Signing Keys
(ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key
exchanges between parents and children is necessary for large zones
because there are too many changes to handle.
Let us consider for example a zone with 100000 secure delegations.
If the child zones change their keys once a year on average, that
implies 300 changes per day for the parent zone. This amount of
changes is hard to manage manually.
Automated rollover is optional and resulting from an agreement
between the administrator of the parent zone and the administrator of
the child zone. Of course, key rollover can also be done manually by
administrators.
This document describes the requirements for a protocol to perform
the automated key rollover process and focusses on interaction
between parent and child zone.
2. The Key Rollover Process
Key rollover consists of renewing the DNSSEC keys used to sign
resource records in a given DNS zone file. There are two types of
rollover, ZSK rollovers and KSK rollovers.
During a ZSK rollover, all changes are local to the zone that renews
its key: there is no need to contact other zones administrators to
propagate the performed changes because a ZSK has no associated DS
record in the parent zone.
During a KSK rollover, new DS RR(s) must be created and stored in the
parent zone. In consequence, data must be exchanged between child
and parent zones.
The key rollover is built from two parts of different nature:
o An algorithm that generates new keys and signs the zone file. It
can be local to the zone,
o the interaction between parent and child zones.
One example of manual key rollover [3] is:
o The child zone creates a new KSK,
Guette & Courtay Expires July 19, 2005 [Page 3]
Internet-Draft Automated Rollover Requirements January 2005
o the child zone waits for the creation of the DS RR in its parent
zone,
o the child zone deletes the old key,
o the parent zone deletes the old DS RR.
This document concentrates on defining interactions between entities
present in key rollover process.
3. Basic Requirements
This section provides the requirements for automated key rollover in
case of normal use. Exceptional case like emergency rollover is
specifically described later in this document.
The main condition during a key rollover is that the chain of trust
must be preserved to every validating DNS client. No matter if this
client retrieves some of the RRs from recursive caching name server
or from the authoritative servers for the zone involved in the
rollover.
Automated key rollover solution may be interrupted by a manual
intervention. This manual intervention should not compromise the
security state of the chain of trust. If the chain is safe before
the manual intervention, the chain of trust must remain safe during
and after the manual intervention
Two entities act during a KSK rollover: the child zone and its parent
zone. These zones are generally managed by different administrators.
These administrators should agree on some parameters like
availability of automated rollover, the maximum delay between
notification of changes in the child zone and the resigning of the
parent zone. The child zone needs to know this delay to schedule its
changes and/or to verify that the changes had been taken into account
in the parent zone. Hence, the child zone can also avoid some
critical cases where all child key are changed prior to the DS RR
creation.
By keeping some resource records during a given time, the recursive
cache servers can act on the automated rollover. The existence of
recursive cache servers must be taken into account by automated
rollover solution.
Indeed, during an automated key rollover a name server could have to
retrieve some DNSSEC data. An automated key rollover solution must
ensure that these data are not old DNSSEC material retrieved from a
recursive name server.
Guette & Courtay Expires July 19, 2005 [Page 4]
Internet-Draft Automated Rollover Requirements January 2005
4. Messages authentication and information exchanged
This section addresses in-band rollover, security of out-of-band
mechanisms is out of scope of this document.
The security provided by DNSSEC must not be compromised by the key
rollover, thus every exchanged message must be authenticated to avoid
fake rollover messages from malicious parties.
Once the changes related to a KSK are made in a child zone, there are
two ways for the parent zone to take this changes into account:
o the child zone notify directly or not directly its parent zone in
order to create the new DS RR and store this DS RR in parent zone
file,
o or the parent zone poll the child zone.
In both cases, the parent zone must receive all the child keys that
need the creation of associated DS RRs in the parent zone.
Because errors could occur during the transmission of keys between
child and parent, the key exchange protocol must be fault tolerant.
Should an error occured during the automated key rollover, an
automated key rollover solution must be able to keep the zone files
in a consistent state.
5. Emergency Rollover
Emergency key rollover is a special case of rollover decided by the
zone administrator generally for security reasons. In consequence,
emergency key rollover can break some of the requirement described
above.
A zone key might be compromised and an attacker can use the
compromised key to create and sign fake records. To avoid this, the
zone administrator may change the compromised key or all its keys as
soon as possible, without waiting for the creation of new DS RRs in
its parent zone.
Fast changes may break the chain of trust. The part of DNS tree
having this zone as apex can become unverifiable, but the break of
the chain of trust is necessary if the administrator wants to prevent
the compromised key from being used (to spoof DNS data).
Parent and child zones sharing an automated rollover mechanism,
should have an out-of-band way to re-establish a consistent state at
the delegation point (DS and DNSKEY RRs). This allows to avoid that
a malicious party uses the compromised key to roll the zone keys.
Guette & Courtay Expires July 19, 2005 [Page 5]
Internet-Draft Automated Rollover Requirements January 2005
6. Security consideration
The automated key rollover process in DNSSEC allows automated renewal
of any kind of DNS key (ZSK or KSK). It is essential that parent
side and child side can do mutual authentication. Moreover,
integrity of the material exchanged between the parent and child zone
must be provided to ensure the right DS are created.
As in any application using public key cryptography, in DNSSEC a key
may be compromised. What to do in such a case can be describe in the
zone local policy and can violate some requirements described in this
draft. The emergency rollover can break the chain of trust in order
to protect the zone against the use of the compromised key.
7. Acknowledgments
The authors want to thank members of IDsA project for their
contribution to this document.
8 Normative References
[1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
RFC 3658, December 2003.
[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] Kolkman, O., "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practice-01 (work in
progress), May 2004.
[4] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Resource Records for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-11 (work in progress), October
2004.
[6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
2004.
[7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
Guette & Courtay Expires July 19, 2005 [Page 6]
Internet-Draft Automated Rollover Requirements January 2005
2004.
Authors' Addresses
Gilles Guette
IRISA / INRIA
Campus de Beaulieu
35042 Rennes CEDEX
FR
EMail: gilles.guette@irisa.fr
URI: http://www.irisa.fr
Olivier Courtay
Thomson R&D
1, avenue Belle Fontaine
35510 Cesson S?vign? CEDEX
FR
EMail: olivier.courtay@thomson.net
Appendix A. Documents details and changes
This section is to be removed by the RFC editor if and when the
document is published.
Section about NS RR rollover has been removed
Remarks from Samuel Weiler and Rip Loomis added
Clarification about in-band rollover and in emergency section
Section 3, details about recursive cache servers added
Guette & Courtay Expires July 19, 2005 [Page 7]
Internet-Draft Automated Rollover Requirements January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
IETF Documents can be found in BCP 78 and 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 which may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr.org.
Full 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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Guette & Courtay Expires July 19, 2005 [Page 8]

618
doc/draft/draft-ietf-dnsop-serverid-06.txt
View File

@@ -1,618 +0,0 @@
Network Working Group S. Woolf
Internet-Draft Internet Systems Consortium, Inc.
Expires: September 6, 2006 D. Conrad
Nominum, Inc.
March 5, 2006
Requirements for a Mechanism Identifying a Name Server Instance
draft-ietf-dnsop-serverid-06
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 September 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
With the increased use of DNS anycast, load balancing, and other
mechanisms allowing more than one DNS name server to share a single
IP address, it is sometimes difficult to tell which of a pool of name
servers has answered a particular query. A standardized mechanism to
determine the identity of a name server responding to a particular
query would be useful, particularly as a diagnostic aid for
administrators. Existing ad hoc mechanisms for addressing this need
Woolf & Conrad Expires September 6, 2006 [Page 1]
Internet-Draft Serverid March 2006
have some shortcomings, not the least of which is the lack of prior
analysis of exactly how such a mechanism should be designed and
deployed. This document describes the existing convention used in
some widely deployed implementations of the DNS protocol, including
advantages and disadvantages, and discusses some attributes of an
improved mechanism.
Woolf & Conrad Expires September 6, 2006 [Page 2]
Internet-Draft Serverid March 2006
1. Introduction and Rationale
Identifying which name server is responding to queries is often
useful, particularly in attempting to diagnose name server
difficulties. This is most obviously useful for authoritative
nameservers in the attempt to diagnose the source or prevalence of
inaccurate data, but can also conceivably be useful for caching
resolvers in similar and other situations. Furthermore, the ability
to identify which server is responding to a query has become more
useful as DNS has become more critical to more Internet users, and as
network and server deployment topologies have become more complex.
The traditional means for determining which of several possible
servers is answering a query has traditionally been based on the use
of the server's IP address as a unique identifier. However, the
modern Internet has seen the deployment of various load balancing,
fault-tolerance, or attack-resistance schemes such as shared use of
unicast IP addresses as documented in [RFC3258]. An unfortunate side
effect of these schemes has been to make the use of IP addresses as
identifiers somewhat problematic. Specifically, a dedicated DNS
query may not go to the same server as answered a previous query,
even though sent to the same IP address. Non-DNS methods such as
ICMP ping, TCP connections, or non-DNS UDP packets (such as those
generated by tools like "traceroute"), etc., may well be even less
certain to reach the same server as the one which receives the DNS
queries.
There is a well-known and frequently-used technique for determining
an identity for a nameserver more specific than the possibly-non-
unique "server that answered the query I sent to IP address XXX".
The widespread use of the existing convention suggests a need for a
documented, interoperable means of querying the identity of a
nameserver that may be part of an anycast or load-balancing cluster.
At the same time, however, it also has some drawbacks that argue
against standardizing it as it's been practiced so far.
Woolf & Conrad Expires September 6, 2006 [Page 3]
Internet-Draft Serverid March 2006
2. Existing Conventions
For some time, the commonly deployed Berkeley Internet Name Domain
implementation of the DNS protocol suite from the Internet Systems
Consortium [BIND] has supported a way of identifying a particular
server via the use of a standards-compliant, if somewhat unusual, DNS
query. Specifically, a query to a recent BIND server for a TXT
resource record in class 3 (CHAOS) for the domain name
"HOSTNAME.BIND." will return a string that can be configured by the
name server administrator to provide a unique identifier for the
responding server. (The value defaults to the result of a
gethostname() call). This mechanism, which is an extension of the
BIND convention of using CHAOS class TXT RR queries to sub-domains of
the "BIND." domain for version information, has been copied by
several name server vendors.
A refinement to the BIND-based mechanism, which dropped the
implementation-specific string, replaces ".BIND" with ".SERVER".
Thus the query string to learn the unique name of a server may be
queried as "ID.SERVER".
(For reference, the other well-known name used by recent versions of
BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
query for a CHAOS TXT RR for this name will return an
administratively defined string which defaults to the version of the
server responding. This is, however, not generally implemented by
other vendors.)
2.1. Advantages
There are several valuable attributes to this mechanism, which
account for its usefulness.
1. The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is
within the DNS protocol itself. An identification mechanism that
relies on the DNS protocol is more likely to be successful
(although not guaranteed) in going to the same system as a
"normal" DNS query.
2. Since the identity information is requested and returned within
the DNS protocol, it doesn't require allowing any other query
mechanism to the server, such as holes in firewalls for
otherwise-unallowed ICMP Echo requests. Thus it is likely to
reach the same server over a path subject to the same routing,
resource, and security policy as the query, without any special
exceptions to site security policy.
Woolf & Conrad Expires September 6, 2006 [Page 4]
Internet-Draft Serverid March 2006
3. It is simple to configure. An administrator can easily turn on
this feature and control the results of the relevant query.
4. It allows the administrator complete control of what information
is given out in the response, minimizing passive leakage of
implementation or configuration details. Such details are often
considered sensitive by infrastructure operators.
5. Hypothetically, since it's an ordinary DNS record and the
relevant DNSSEC RRs are class independent, the id.server response
RR could be signed, which has the advantages described in
[RFC4033].
2.2. Disadvantages
At the same time, there are some serious drawbacks to the CHAOS/TXT
query mechanism that argue against standardizing it as it currently
operates.
1. It requires an additional query to correlate between the answer
to a DNS query under normal conditions and the supposed identity
of the server receiving the query. There are a number of
situations in which this simply isn't reliable.
2. It reserves an entire class in the DNS (CHAOS) for what amounts
to one zone. While CHAOS class is defined in [RFC1034] and
[RFC1035], it's not clear that supporting it solely for this
purpose is a good use of the namespace or of implementation
effort.
3. The initial and still common form, using .BIND, is implementation
specific. BIND is one DNS implementation. At the time of this
writing, it is probably the most prevalent for authoritative
servers. This does not justify standardizing on its ad hoc
solution to a problem shared across many operators and
implementors. Meanwhile, the proposed refinement changes the
string but preserves the ad hoc CHAOS/TXT mechanism.
4. There is no convention or shared understanding of what
information an answer to such a query for a server identity could
or should include, including a possible encoding or
authentication mechanism.
The first of the listed disadvantages may be technically the most
serious. It argues for an attempt to design a good answer to the
problem that "I need to know what nameserver is answering my
queries", not simply a convenient one.
Woolf & Conrad Expires September 6, 2006 [Page 5]
Internet-Draft Serverid March 2006
2.3. Characteristics of an Implementation Neutral Convention
The discussion above of advantages and disadvantages to the
HOSTNAME.BIND mechanism suggest some requirements for a better
solution to the server identification problem. These are summarized
here as guidelines for any effort to provide appropriate protocol
extensions:
1. The mechanism adopted must be in-band for the DNS protocol. That
is, it needs to allow the query for the server's identifying
information to be part of a normal, operational query. It should
also permit a separate, dedicated query for the server's
identifying information. But it should preserve the ability of
the CHAOS/TXT query-based mechanism to work through firewalls and
in other situations where only DNS can be relied upon to reach
the server of interest.
2. The new mechanism should not require dedicated namespaces or
other reserved values outside of the existing protocol mechanisms
for these, i.e. the OPT pseudo-RR. In particular, it should not
propagate the existing drawback of requiring support for a CLASS
and top level domain in the authoritative server (or the querying
tool) to be useful.
3. Support for the identification functionality should be easy to
implement and easy to enable. It must be easy to disable and
should lend itself to access controls on who can query for it.
4. It should be possible to return a unique identifier for a server
without requiring the exposure of information that may be non-
public and considered sensitive by the operator, such as a
hostname or unicast IP address maintained for administrative
purposes.
5. It should be possible to authenticate the received data by some
mechanism analogous to those provided by DNSSEC. In this
context, the need could be met by including encryption options in
the specification of a new mechanism.
6. The identification mechanism should not be implementation-
specific.
Woolf & Conrad Expires September 6, 2006 [Page 6]
Internet-Draft Serverid March 2006
3. IANA Considerations
This document proposes no specific IANA action. Protocol extensions,
if any, to meet the requirements described are out of scope for this
document. A proposed extension, specified and adopted by normal IETF
process, is described in [NSID], including relevant IANA action.
Woolf & Conrad Expires September 6, 2006 [Page 7]
Internet-Draft Serverid March 2006
4. Security Considerations
Providing identifying information as to which server is responding to
a particular query from a particular location in the Internet can be
seen as information leakage and thus a security risk. This motivates
the suggestion above that a new mechanism for server identification
allow the administrator to disable the functionality altogether or
partially restrict availability of the data. It also suggests that
the serverid data should not be readily correlated with a hostname or
unicast IP address that may be considered private to the nameserver
operator's management infrastructure.
Propagation of protocol or service meta-data can sometimes expose the
application to denial of service or other attack. As DNS is a
critically important infrastructure service for the production
Internet, extra care needs to be taken against this risk for
designers, implementors, and operators of a new mechanism for server
identification.
Both authentication and confidentiality of serverid data are
potentially of interest to administrators-- that is, operators may
wish to make serverid data available and reliable to themselves and
their chosen associates only. This would imply both an ability to
authenticate it to themselves and keep it private from arbitrary
other parties. This led to Characteristics 4 and 5 of an improved
solution.
Woolf & Conrad Expires September 6, 2006 [Page 8]
Internet-Draft Serverid March 2006
5. Acknowledgements
The technique for host identification documented here was initially
implemented by Paul Vixie of the Internet Software Consortium in the
Berkeley Internet Name Daemon package. Comments and questions on
earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
ICANN Root Server System Advisory Committee. The newest version
takes a significantly different direction from previous versions,
owing to discussion among contributors to the DNSOP working group and
others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
Weiler, and Rob Austein.
6. References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 0013, November 1987.
[2] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, STD 0013, November 1987.
[3] Hardie, T., "Distributing Authoritative Name Servers via Shared
Unicast Addresses", RFC 3258, April 2002.
[4] ISC, "BIND 9 Configuration Reference".
[5] Austein, S., "DNS Name Server Identifier Option (NSID)",
Internet Drafts http://www.ietf.org/internet-drafts/
draft-ietf-dnsext-nsid-01.txt, January 2006.
[6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
Woolf & Conrad Expires September 6, 2006 [Page 9]
Internet-Draft Serverid March 2006
Authors' Addresses
Suzanne Woolf
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
US
Phone: +1 650 423-1333
Email: woolf@isc.org
URI: http://www.isc.org/
David Conrad
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94063
US
Phone: +1 1 650 381 6003
Email: david.conrad@nominum.com
URI: http://www.nominum.com/
Woolf & Conrad Expires September 6, 2006 [Page 10]
Internet-Draft Serverid March 2006
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 (2006). 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.
Woolf & Conrad Expires September 6, 2006 [Page 11]

1588
doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
View File

File diff suppressed because it is too large Load Diff

1200
doc/draft/draft-ietf-ipv6-node-requirements-08.txt
View File

File diff suppressed because it is too large Load Diff

614
doc/draft/draft-ietf-secsh-dns-05.txt
View File

@@ -1,614 +0,0 @@
Secure Shell Working Group J. Schlyter
Internet-Draft OpenSSH
Expires: March 5, 2004 W. Griffin
SPARTA
September 5, 2003
Using DNS to Securely Publish SSH Key Fingerprints
draft-ietf-secsh-dns-05.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 March 5, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a method to verify SSH host keys using
DNSSEC. The document defines a new DNS resource record that contains
a standard SSH key fingerprint.
Schlyter & Griffin Expires March 5, 2004 [Page 1]
Internet-Draft DNS and SSH Fingerprints September 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3
2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3
2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4
2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4
3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4
3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 5
3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5
3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5
3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
Normative References . . . . . . . . . . . . . . . . . . . . 8
Informational References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10
Schlyter & Griffin Expires March 5, 2004 [Page 2]
Internet-Draft DNS and SSH Fingerprints September 2003
1. Introduction
The SSH [6] protocol provides secure remote login and other secure
network services over an insecure network. The security of the
connection relies on the server authenticating itself to the client
as well as the user authenticating itself to the server.
If a connection is established to a server whose public key is not
already known to the client, a fingerprint of the key is presented to
the user for verification. If the user decides that the fingerprint
is correct and accepts the key, the key is saved locally and used for
verification for all following connections. While some
security-conscious users verify the fingerprint out-of-band before
accepting the key, many users blindly accept the presented key.
The method described here can provide out-of-band verification by
looking up a fingerprint of the server public key in the DNS [1][2]
and using DNSSEC [5] to verify the lookup.
In order to distribute the fingerprint using DNS, this document
defines a new DNS resource record, "SSHFP", to carry the fingerprint.
Basic understanding of the DNS system [1][2] and the DNS security
extensions [5] is assumed by this document.
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 RFC 2119 [3].
2. SSH Host Key Verification
2.1 Method
Upon connection to a SSH server, the SSH client MAY look up the SSHFP
resource record(s) for the host it is connecting to. If the
algorithm and fingerprint of the key received from the SSH server
match the algorithm and fingerprint of one of the SSHFP resource
record(s) returned from DNS, the client MAY accept the identity of
the server.
2.2 Implementation Notes
Client implementors SHOULD provide a configurable policy used to
select the order of methods used to verify a host key. This document
defines one method: Fingerprint storage in DNS. Another method
defined in the SSH Architecture [6] uses local files to store keys
for comparison. Other methods that could be defined in the future
might include storing fingerprints in LDAP or other databases. A
Schlyter & Griffin Expires March 5, 2004 [Page 3]
Internet-Draft DNS and SSH Fingerprints September 2003
configurable policy will allow administrators to determine which
methods they want to use and in what order the methods should be
prioritized. This will allow administrators to determine how much
trust they want to place in the different methods.
One specific scenario for having a configurable policy is where
clients do not use fully qualified host names to connect to servers.
In this scenario, the implementation SHOULD verify the host key
against a local database before verifying the key via the fingerprint
returned from DNS. This would help prevent an attacker from injecting
a DNS search path into the local resolver and forcing the client to
connect to a different host.
2.3 Fingerprint Matching
The public key and the SSHFP resource record are matched together by
comparing algorithm number and fingerprint.
The public key algorithm and the SSHFP algorithm number MUST
match.
A message digest of the public key, using the message digest
algorithm specified in the SSHFP fingerprint type, MUST match the
SSHFP fingerprint.
2.4 Authentication
A public key verified using this method MUST NOT be trusted if the
SSHFP resource record (RR) used for verification was not
authenticated by a trusted SIG RR.
Clients that do validate the DNSSEC signatures themselves SHOULD use
standard DNSSEC validation procedures.
Clients that do not validate the DNSSEC signatures themselves MUST
use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
between themselves and the entity performing the signature
validation.
3. The SSHFP Resource Record
The SSHFP resource record (RR) is used to store a fingerprint of a
SSH public host key that is associated with a Domain Name System
(DNS) name.
The RR type code for the SSHFP RR is TBA.
Schlyter & Griffin Expires March 5, 2004 [Page 4]
Internet-Draft DNS and SSH Fingerprints September 2003
3.1 The SSHFP RDATA Format
The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
type and the fingerprint of the public host key.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | fp type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ fingerprint /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1 Algorithm Number Specification
This algorithm number octet describes the algorithm of the public
key. The following values are assigned:
Value Algorithm name
----- --------------
0 reserved
1 RSA
2 DSS
Reserving other types requires IETF consensus [4].
3.1.2 Fingerprint Type Specification
The fingerprint type octet describes the message-digest algorithm
used to calculate the fingerprint of the public key. The following
values are assigned:
Value Fingerprint type
----- ----------------
0 reserved
1 SHA-1
Reserving other types requires IETF consensus [4].
For interoperability reasons, as few fingerprint types as possible
should be reserved. The only reason to reserve additional types is
to increase security.
3.1.3 Fingerprint
Schlyter & Griffin Expires March 5, 2004 [Page 5]
Internet-Draft DNS and SSH Fingerprints September 2003
The fingerprint is calculated over the public key blob as described
in [7].
The message-digest algorithm is presumed to produce an opaque octet
string output which is placed as-is in the RDATA fingerprint field.
3.2 Presentation Format of the SSHFP RR
The RDATA of the presentation format of the SSHFP resource record
consists of two numbers (algorithm and fingerprint type) followed by
the fingerprint itself presented in hex, e.g:
host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
The use of mnemonics instead of numbers is not allowed.
4. Security Considerations
Currently, the amount of trust a user can realistically place in a
server key is proportional to the amount of attention paid to
verifying that the public key presented actually corresponds to the
private key of the server. If a user accepts a key without verifying
the fingerprint with something learned through a secured channel, the
connection is vulnerable to a man-in-the-middle attack.
The overall security of using SSHFP for SSH host key verification is
dependent on the security policies of the SSH host administrator and
DNS zone administrator (in transferring the fingerprint), detailed
aspects of how verification is done in the SSH implementation, and in
the client's diligence in accessing the DNS in a secure manner.
One such aspect is in which order fingerprints are looked up (e.g.
first checking local file and then SSHFP). We note that in addition
to protecting the first-time transfer of host keys, SSHFP can
optionally be used for stronger host key protection.
If SSHFP is checked first, new SSH host keys may be distributed by
replacing the corresponding SSHFP in DNS.
If SSH host key verification can be configured to require SSHFP,
SSH host key revocation can be implemented by removing the
corresponding SSHFP from DNS.
As stated in Section 2.2, we recommend that SSH implementors provide
a policy mechanism to control the order of methods used for host key
verification. One specific scenario for having a configurable policy
is where clients use unqualified host names to connect to servers. In
this case, we recommend that SSH implementations check the host key
Schlyter & Griffin Expires March 5, 2004 [Page 6]
Internet-Draft DNS and SSH Fingerprints September 2003
against a local database before verifying the key via the fingerprint
returned from DNS. This would help prevent an attacker from injecting
a DNS search path into the local resolver and forcing the client to
connect to a different host.
A different approach to solve the DNS search path issue would be for
clients to use a trusted DNS search path, i.e., one not acquired
through DHCP or other autoconfiguration mechanisms. Since there is no
way with current DNS lookup APIs to tell whether a search path is
from a trusted source, the entire client system would need to be
configured with this trusted DNS search path.
Another dependency is on the implementation of DNSSEC itself. As
stated in Section 2.4, we mandate the use of secure methods for
lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This
is especially important if SSHFP is to be used as a basis for host
key rollover and/or revocation, as described above.
Since DNSSEC only protects the integrity of the host key fingerprint
after it is signed by the DNS zone administrator, the fingerprint
must be transferred securely from the SSH host administrator to the
DNS zone administrator. This could be done manually between the
administrators or automatically using secure DNS dynamic update [11]
between the SSH server and the nameserver. We note that this is no
different from other key enrollment situations, e.g. a client sending
a certificate request to a certificate authority for signing.
5. IANA Considerations
IANA needs to allocate a RR type code for SSHFP from the standard RR
type space (type 44 requested).
IANA needs to open a new registry for the SSHFP RR type for public
key algorithms. Defined types are:
0 is reserved
1 is RSA
2 is DSA
Adding new reservations requires IETF consensus [4].
IANA needs to open a new registry for the SSHFP RR type for
fingerprint types. Defined types are:
0 is reserved
1 is SHA-1
Adding new reservations requires IETF consensus [4].
Schlyter & Griffin Expires March 5, 2004 [Page 7]
Internet-Draft DNS and SSH Fingerprints September 2003
Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-14 (work in progress), July 2003.
[7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Transport Layer Protocol",
draft-ietf-secsh-transport-16 (work in progress), July 2003.
Informational References
[8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
Roadmap", RFC 2411, November 1998.
[9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[10] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
Schlyter & Griffin Expires March 5, 2004 [Page 8]
Internet-Draft DNS and SSH Fingerprints September 2003
Authors' Addresses
Jakob Schlyter
OpenSSH
812 23rd Avenue SE
Calgary, Alberta T2G 1N8
Canada
EMail: jakob@openssh.com
URI: http://www.openssh.com/
Wesley Griffin
SPARTA
7075 Samuel Morse Drive
Columbia, MD 21046
USA
EMail: wgriffin@sparta.com
URI: http://www.sparta.com/
Appendix A. Acknowledgements
The authors gratefully acknowledge, in no particular order, the
contributions of the following persons:
Martin Fredriksson
Olafur Gudmundsson
Edward Lewis
Bill Sommerfeld
Schlyter & Griffin Expires March 5, 2004 [Page 9]
Internet-Draft DNS and SSH Fingerprints September 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Schlyter & Griffin Expires March 5, 2004 [Page 10]
Internet-Draft DNS and SSH Fingerprints September 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schlyter & Griffin Expires March 5, 2004 [Page 11]

519
doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
View File

@@ -1,519 +0,0 @@
Internet Draft Johan Ihren
draft-ihren-dnsext-threshold-validation-00.txt Autonomica
February 2003
Expires in six months
Threshold Validation:
A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This memo documents a proposal for a different method of validation
for DNSSEC aware resolvers. The key change is that by changing from
a model of one Key Signing Key, KSK, at a time to multiple KSKs it
will be possible to increase the aggregated trust in the signed
keys by leveraging from the trust associated with the different
signees.
By having multiple keys to chose from validating resolvers get the
opportunity to use local policy to reflect actual trust in
different keys. For instance, it is possible to trust a single,
particular key ultimately, while requiring multiple valid
signatures by less trusted keys for validation to succeed.
Furthermore, with multiple KSKs there are additional redundancy
benefits available since it is possible to roll over different KSKs
at different times which may make rollover scenarios easier to
manage.
Contents
1. Terminology
2. Introduction and Background
3. Trust in DNSSEC Keys
3.1. Key Management, Split Keys and Trust Models
3.2. Trust Expansion: Authentication versus Authorization
4. Proposed Semantics for Signing the KEY Resource Record
Set
4.1. Packet Size Considerations
5. Proposed Use of Multiple "Trusted Keys" in a Validating
Resolver
5.1. Not All Possible KSKs Need to Be Trusted
5.2. Possible to do Threshold Validation
5.3. Not All Trusted Keys Will Be Available
6. Additional Benefits from Having Multiple KSKs
6.1. More Robust Key Rollovers
6.2. Evaluation of Multiple Key Distribution Mechanisms
7. Security Considerations
8. IANA Considerations.
9. References
9.1. Normative.
9.2. Informative.
10. Acknowledgments.
11. Authors' Address
1. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in
RFC 2119.
The term "zone" refers to the unit of administrative control in the
Domain Name System. "Name server" denotes a DNS name server that is
authoritative (i.e. knows all there is to know) for a DNS zone,
typically the root zone. A "resolver", is a DNS "client", i.e. an
entity that sends DNS queries to authoritative nameservers and
interpret the results. A "validating resolver" is a resolver that
attempts to perform DNSSEC validation on data it retrieves by doing
DNS lookups.
2. Introduction and Background
From a protocol perspective there is no real difference between
different keys in DNSSEC. They are all just keys. However, in
actual use there is lots of difference. First and foremost, most
DNSSEC keys have in-band verification. I.e. the keys are signed by
some other key, and this other key is in its turn also signed by
yet another key. This way a "chain of trust" is created. Such
chains have to end in what is referred to as a "trusted key" for
validation of DNS lookups to be possible.
A "trusted key" is a the public part of a key that the resolver
acquired by some other means than by looking it up in DNS. The
trusted key has to be explicitly configured.
A node in the DNS hierarchy that issues such out-of-band "trusted
keys" is called a "security apex" and the trusted key for that apex
is the ultimate source of trust for all DNS lookups within that
entire subtree.
DNSSEC is designed to be able to work with more than on security
apex. These apexes will all share the problem of how to distribute
their "trusted keys" in a way that provides validating resolvers
confidence in the distributed keys.
Maximizing that confidence is crucial to the usefulness of DNSSEC
and this document tries to address this issue.
3. Trust in DNSSEC Keys
In the end the trust that a validating resolver will be able to put
in a key that it cannot validate within DNSSEC will have to be a
function of
* trust in the key issuer, aka the KSK holder
* trust in the distribution method
* trust in extra, out-of-band verification
The KSK holder needs to be trusted not to accidentally lose private
keys in public places. Furthermore it needs to be trusted to
perform correct identification of the ZSK holders in case they are
separate from the KSK holder itself.
The distribution mechanism can be more or less tamper-proof. If the
key holder publishes the public key, or perhaps just a secure
fingerprint of the key in a major newspaper it may be rather
difficult to tamper with. A key acquired that way may be easier to
trust than if it had just been downloaded from a web page.
Out-of-band verification can for instance be the key being signed
by a certificate issued by a known Certificate Authority that the
resolver has reason to trust.
3.1. Simplicity vs Trust
The fewer keys that are in use the simpler the key management
becomes. Therefore increasing the number of keys should only be
considered when the complexity is not the major concern. A perfect
example of this is the distinction between so called Key Signing
Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
overall complexity but simplifies real life operations and was an
overall gain since operational simplification was considered to be
a more crucial issue than the added complexity.
In the case of a security apex there are additional issues to
consider, among them
* maximizing trust in the KSK received out-of-band
* authenticating the legitimacy of the ZSKs used
In some cases this will be easy, since the same entity will manage
both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
similar to a self-signed certificate). In some environments it will
be possible to get the trusted key installed in the resolver end by
decree (this would seem to be a likely method within corporate and
government environments).
In other cases, however, this will possibly not be sufficient. In
the case of the root zone this is obvious, but there may well be
other cases.
3.2. Expanding the "Trust Base"
For a security apex where the ZSKs and KSK are not held by the same
entity the KSK will effectively authenticate the identity of
whoever does real operational zone signing. The amount of trust
that the data signed by a ZSK will get is directly dependent on
whether the end resolver trusts the KSK or not, since the resolver
has no OOB access to the public part of the ZSKs (for practical
reasons).
Since the KSK holder is distinct from the ZSK holder the obvious
question is whether it would then be possible to further improve
the situation by using multiple KSK holders and thereby expanding
the trust base to the union of that available to each individual
KSK holder. "Trust base" is an invented term intended to signify
the aggregate of Internet resolvers that will eventually choose to
trust a key issued by a particular KSK holder.
A crucial issue when considering trust expansion through addition
of multiple KSK holders is that the KSK holders are only used to
authenticate the ZSKs used for signing the zone. I.e. the function
performed by the KSK is basically:
"This is indeed the official ZSK holder for this zone,
I've verified this fact to the best of my abilitites."
Which can be thought of as similar to the service of a public
notary. I.e. the point with adding more KSK holders is to improve
the public trust in data signed by the ZSK holders by improving the
strength of available authentication.
Therefore adding more KSK holders, each with their own trust base,
is by definition a good thing. More authentication is not
controversial. On the contrary, when it comes to authentication,
the more the merrier.
4. Proposed Semantics for Signing the KEY Resource Record Set
In DNSSEC according to RFC2535 all KEY Resource Records are used to
sign all authoritative data in the zone, including the KEY RRset
itself, since RFC2535 makes no distinction between Key Signing
Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS]
it is possible to change this to the KEY RRset being signed with
all KSKs and ZSKs but the rest of the zone only being signed by the
ZSKs.
This proposal changes this one step further, by recommending that
the KEY RRset is only signed by the Key Signing Keys, KSK, and
explicitly not by the Zone Signing Keys, ZSK. The reason for this
is to maximize the amount of space in the DNS response packet that
is available for additional KSKs and signatures thereof. The rest
of the authoritative zone contents are as previously signed by only
the ZSKs.
4.1. Packet Size Considerations
The reason for the change is to keep down the size of the aggregate
of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
perform validation of data below a security apex. For DNSSEC data
to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
set, and therefore the allowed packet size can be assumed to be at
least the EDNS0 minimum of 4000 bytes.
When querying for KEY + SIG(KEY) for "." (the case that is assumed
to be most crucial) the size of the response packet after the
change to only sign the KEY RR with the KSKs break down into a
rather large space of possibilities. Here are a few examples for
the possible alternatives for different numbers of KSKs and ZSKs
for some different key lengths (all RSA keys, with a public
exponent that is < 254). This is all based upon the size of the
response for the particular example of querying for
". KEY IN"
with a response of entire KEY + SIG(KEY) with the authority and
additional sections empty:
ZSK/768 and KSK/1024 (real small)
Max 12 KSK + 3 ZSK at 3975
10 KSK + 8 ZSK at 3934
8 KSK + 13 ZSK at 3893
ZSK/768 + KSK/1280
MAX 10 KSK + 2 ZSK at 3913
8 KSK + 9 ZSK at 3970
6 KSK + 15 ZSK at 3914
ZSK/768 + KSK/1536
MAX 8 KSK + 4 ZSK at 3917
7 KSK + 8 ZSK at 3938
6 KSK + 12 ZSK at 3959
ZSK/768 + KSK/2048
MAX 6 KSK + 5 ZSK at 3936
5 KSK + 10 ZSK at 3942
ZSK/1024 + KSK/1024
MAX 12 KSK + 2 ZSK at 3943
11 KSK + 4 ZSK at 3930
10 KSK + 6 ZSK at 3917
8 KSK + 10 ZSK at 3891
ZSK/1024 + KSK/1536
MAX 8 KSK + 3 ZSK at 3900
7 KSK + 6 ZSK at 3904
6 KSK + 9 ZSK at 3908
ZSK/1024 + KSK/2048
MAX 6 KSK + 4 ZSK at 3951
5 KSK + 8 ZSK at 3972
4 KSK + 12 ZSK at 3993
Note that these are just examples and this document is not making
any recommendations on suitable choices of either key lengths nor
number of different keys employed at a security apex.
This document does however, based upon the above figures, make the
recommendation that at a security apex that expects to distribute
"trusted keys" the KEY RRset should only be signed with the KSKs
and not with the ZSKs to keep the size of the response packets
down.
5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
In DNSSEC according to RFC2535[RFC2535] validation is the process
of tracing a chain of signatures (and keys) upwards through the DNS
hierarchy until a "trusted key" is reached. If there is a known
trusted key present at a security apex above the starting point
validation becomes an exercise with a binary outcome: either the
validation succeeds or it fails. No intermediate states are
possible.
With multiple "trusted keys" (i.e. the KEY RRset for the security
apex signed by multiple KSKs) this changes into a more complicated
space of alternatives. From the perspective of complexity that may
be regarded as a change for the worse. However, from a perspective
of maximizing available trust the multiple KSKs add value to the
system.
5.1. Possible to do Threshold Validation
With multiple KSKs a new option that opens for the security
concious resolver is to not trust a key individually. Instead the
resolver may decide to require the validated signatures to exceed a
threshold. For instance, given M trusted keys it is possible for
the resolver to require N-of-M signatures to treat the data as
validated.
I.e. with the following pseudo-configuration in a validating
resolver
security-apex "." IN {
keys { ksk-1 .... ;
ksk-2 .... ;
ksk-3 .... ;
ksk-4 .... ;
ksk-5 .... ;
};
validation {
# Note that ksk-4 is not present below
keys { ksk-1; ksk-2; ksk-3; ksk-5; };
# 3 signatures needed with 4 possible keys, aka 75%
needed-signatures 3;
};
};
we configure five trusted keys for the root zone, but require two
valid signatures for the top-most KEY for validation to
succeed. I.e. threshold validation does not force multiple
signatures on the entire signature chain, only on the top-most
signature, closest to the security apex for which the resolver has
trusted keys.
5.2. Not All Trusted Keys Will Be Available
With multiple KSKs held and managed by separate entities the end
resolvers will not always manage to get access to all possible
trusted keys. In the case of just a single KSK this would be fatal
to validation and necessary to avoid at whatever cost. But with
several fully trusted keys available the resolver can decide to
trust several of them individually. An example based upon more
pseudo-configuration:
security-apex "." IN {
keys { ksk-1 .... ;
ksk-2 .... ;
ksk-3 .... ;
ksk-4 .... ;
ksk-5 .... ;
};
validation {
# Only these two keys are trusted independently
keys { ksk-1; ksk-4; };
# With these keys a single signature is sufficient
needed-signatures 1;
};
};
Here we have the same five keys and instruct the validating
resolver to fully trust data that ends up with just one signature
from by a fully trusted key.
The typical case where this will be useful is for the case where
there is a risk of the resolver not catching a rollover event by
one of the KSKs. By doing rollovers of different KSKs with
different schedules it is possible for a resolver to "survive"
missing a rollover without validation breaking. This improves
overall robustness from a management point of view.
5.3. Not All Possible KSKs Need to Be Trusted
With just one key available it simply has to be trusted, since that
is the only option available. With multiple KSKs the validating
resolver immediately get the option of implementing a local policy
of only trusting some of the possible keys.
This local policy can be implemented either by simply not
configuring keys that are not trusted or, possibly, configure them
but specify to the resolver that certain keys are not to be
ultimately trusted alone.
6. Additional Benefits from Having Multiple KSKs
6.1. More Robust Key Rollovers
With only one KSK the rollover operation will be a delicate
operation since the new trusted key needs to reach every validating
resolver before the old key is retired. For this reason it is
expected that long periods of overlap will be needed.
With multiple KSKs this changes into a system where different
"series" of KSKs can have different rollover schedules, thereby
changing from one "big" rollover to several "smaller" rollovers.
If the resolver trusts several of the available keys individually
then even a failure to track a certain rollover operation within
the overlap period will not be fatal to validation since the other
available trusted keys will be sufficient.
6.2. Evaluation of Multiple Key Distribution Mechanisms
Distribution of the trusted keys for the DNS root zone is
recognized to be a difficult problem that ...
With only one trusted key, from one single "source" to distribute
it will be difficult to evaluate what distribution mechanism works
best. With multiple KSKs, held by separate entitites it will be
possible to measure how large fraction of the resolver population
that is trusting what subsets of KSKs.
7. Security Considerations
From a systems perspective the simplest design is arguably the
best, i.e. one single holder of both KSK and ZSKs. However, if that
is not possible in all cases a more complex scheme is needed where
additional trust is injected by using multiple KSK holders, each
contributing trust, then there are only two alternatives
available. The first is so called "split keys", where a single key
is split up among KSK holders, each contributing trust. The second
is the multiple KSK design outlined in this proposal.
Both these alternatives provide for threshold mechanisms. However
split keys makes the threshold integral to the key generating
mechanism (i.e. it will be a property of the keys how many
signatures are needed). In the case of multiple KSKs the threshold
validation is not a property of the keys but rather local policy in
the validating resolver. A benefit from this is that it is possible
for different resolvers to use different trust policies. Some may
configure threshold validation requiring multiple signatures and
specific keys (optimizing for security) while others may choose to
accept a single signature from a larger set of keys (optimizing for
redundancy). Since the security requirements are different it would
seem to be a good idea to make this choice local policy rather than
global policy.
Furthermore, a clear issue for validating resolvers will be how to
ensure that they track all rollover events for keys they
trust. Even with operlap during the rollover (which is clearly
needed) there is still a need to be exceedingly careful not to miss
any rollovers (or fail to acquire a new key) since without this
single key validation will fail. With multiple KSKs this operation
becomes more robust, since different KSKs may roll at different
times according to different rollover schedules and losing one key,
for whatever reason, will not be crucial unless the resolver
intentionally chooses to be completely dependent on that exact key.
8. IANA Considerations.
NONE.
9. References
9.1. Normative.
[RFC2535] Domain Name System Security Extensions. D. Eastlake.
March 1999.
[RFC3090] DNS Security Extension Clarification on Zone Status.
E. Lewis. March 2001.
9.2. Informative.
[RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
(DNS). D. Eastlake 3rd. May 2001.
[RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad.
December 2001.
[DS] Delegation Signer Resource Record.
O. Gudmundsson. October 2002. Work In Progress.
10. Acknowledgments.
Bill Manning came up with the original idea of moving complexity
from the signing side down to the resolver in the form of threshold
validation. I've also had much appreciated help from (in no
particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
Olaf Kolkman.
11. Authors' Address
Johan Ihren
Autonomica AB
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
johani@autonomica.se

1830
doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
View File

File diff suppressed because it is too large Load Diff

4
doc/rfc/index
View File

@@ -106,6 +106,8 @@
4159: Deprecation of "ip6.int"
4193: Unique Local IPv6 Unicast Addresses
4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
4294: IPv6 Node Requirements
4339: IPv6 Host Configuration of DNS Server Information Approaches
4343: Domain Name System (DNS) Case Insensitivity Clarification
4367: What's in a Name: False Assumptions about DNS Names
4398: Storing Certificates in the Domain Name System (DNS)
@@ -114,11 +116,13 @@
in E-Mail, Version 1
4470: Minimally Covering NSEC Records and DNSSEC On-line Signing
4471: Derivation of DNS Name Predecessor and Successor
4472: Operational Considerations and Issues with IPv6 DNS
4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
4634: US Secure Hash Algorithms (SHA and HMAC-SHA)
4635: HMAC SHA TSIG Algorithm Identifiers
4641: DNSSEC Operational Practices
4648: The Base16, Base32, and Base64 Data Encodings
4697: Observed DNS Resolution Misbehavior
4701: A DNS Resource Record (RR) for Encoding
Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
4892: Requirements for a Mechanism Identifying a Name Server Instance

1123
doc/rfc/rfc4294.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1459
doc/rfc/rfc4339.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1483
doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt → doc/rfc/rfc4472.txt
View File

File diff suppressed because it is too large Load Diff

1011
doc/rfc/rfc4697.txt Normal file
View File

File diff suppressed because it is too large Load Diff