Network Working Group J. Ihren
Internet-Draft Autonimica AB
Expires: January 7, 2005 O. Kolkman
RIPE NCC
B. Manning
EP.net
July 9, 2004
An In-Band Rollover Algorithm and a Out-Of-Band Priming Method for
DNS Trust Anchors.
draft-kolkman-dnsext-dnssec-in-band-rollover-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The DNS Security Extensions (DNSSEC) works by validating so called
chains of authority. The start of these chains of authority are
usually public keys that are anchored in the DNS clients, the so
called trust anchors.
Ihren, et al. Expires January 7, 2005 [Page 1]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
This memo describes a method how these client trust anchors can be
replaced using the DNS validation and querying mechanisms (in-band)
if the key pairs used for signing by zone owner are rolled.
This memo also describes a method to establish the validity of trust
anchors for initial configuration, or priming, using out of band
mechanisms.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Key Signing Keys, Zone Signing Keys and Secure Entry
Points. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and Background . . . . . . . . . . . . . . . . . 4
3. M-N Trust Anchor Rollover. . . . . . . . . . . . . . . . . . . 5
3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 The Algorithm. . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Implementation notes . . . . . . . . . . . . . . . . . . . 7
3.4 Possible transactions. . . . . . . . . . . . . . . . . . . 7
3.4.1 Single DNSKEY replaced. . . . . . . . . . . . . . . . 7
3.4.2 Addition of a new DNSKEY (no removal) . . . . . . . . 8
3.4.3 Removal of old DNSKEY (no addition). . . . . . . . . . 8
3.4.4 Multiple DNSKEYs replaced. . . . . . . . . . . . . . . 8
3.4.5 Only some RRSIGs validate over an unchanged DNSKEY
set. . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 No need for resolver-side overlap of old and new keys. . . 8
4. Bootstrapping automatic rollovers. . . . . . . . . . . . . . . 8
4.1 Priming Keys. . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 Bootstrapping trust-anchors using a priming key. . . . 9
4.1.2 Distribution of priming keys. . . . . . . . . . . . . 9
5. M-N algorithm vs Priming . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
6.1 M-N Algorithm Security Considerations . . . . . . . . . . 10
6.2 Priming Key Security Considerations . . . . . . . . . . . 11
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
B. Document History . . . . . . . . . . . . . . . . . . . . . . . 12
B.1 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
Ihren, et al. Expires January 7, 2005 [Page 2]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
1. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in
RFC2119 [1].
The term "zone" refers to the unit of administrative control in the
Domain Name System. In this document "name server" denotes a DNS
name server that is authoritative (i.e. knows all there is to know)
for a DNS zone. A "zone owner" is the entity responsible for signing
and publishing a zone on a name server. The terms "authentication
chain", "bogus", "trust anchors" and "Island of Security" are defined
in [4]. Throughout this document we use the term "resolver" to mean
"Validating Stub Resolvers" as defined in [4].
We use the term "security apex" as the zone for which a trust anchor
has been configured and which is therefore, by definition, at the
root of an island of security. The configuration of trust anchors is
a client side issue therefore a zone owner may not always know if
their zone has become a security apex.
A "stale anchor" is a trust anchor (a public key) that relates to a
key that is not used for signing. Since trust anchors indicate that
a zone is supposed to be secure a validator will mark the all data in
an island of security as bogus when all trust anchors become stale.
It is assumed that the reader is familiar with public key
cryptography concepts [REF: Schneier Applied Cryptography] and is
able to distinguish between the private and public parts of a key
based on the context in which we use the term "key", if there is a
possible ambiguity we will explicitly mention if a private or a
public part of a key is used.
The term "administrator" is used loosely throughout the text. In
some cases an administrator is meant to be a person, in other cases
the administrator may be a process that has been delegated certain
responsibilities.
1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points.
Although the DNSSEC protocol does not make a distinction between
different keys the operational practice is that a distinction is made
between zone signing keys and key signing keys. A key signing key is
used to exclusively sign the DNSKEY Resource Record (RR) set at the
apex of a zone and the zone signing keys sign all the data in the
zone (including the DNSKEY RR set at the apex).
Keys that are intended to be used as the start of the authentication
Ihren, et al. Expires January 7, 2005 [Page 3]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
chain for a particular zone, either because they are pointed to by a
parental DS RR or because they are configured as a trust anchor, are
called Secure Entry Point (SEP) keys. In practice these SEP keys
will be key signing keys.
In order for the mechanism described herein to work the keys that are
intended to be used as secure entry points MUST have the SEP [2] flag
set. In the examples it is assumed that keys with the SEP flag set
are used as key signing keys and thus exclusively sign the DNSKEY RR
set published at the apex of the zone.
2. Introduction and Background
When DNSSEC signatures are validated the resolver constructs a chain
of authority from a pre-configured trust anchor to the DNSKEY
Resource Record (RR), which contains the public key that validates
the signature stored in a RRSIG RR. DNSSEC is designed so that the
administrator of a resolver can create multiple islands of security
by configuring multiple trust anchors.
It is expected that resolvers will have more than one trust-anchor
configured. Although there is no deployment experience it is not
unreasonable to expect resolvers to be configured with a number of
trust anchors that varies between order 1 and order 1000. Because
zone owners are expected to roll their keys, trust-anchors will have
to be maintained in order not to become stale.
Since there is no global key maintenance policy for zone owners and
there are no mechanisms in the DNS to signal the key maintenance
policy it may be very hard for resolvers administrators to keep their
set of trust anchors up to date. For instance, if there is only one
trust anchor configured and the key maintenance policy is clearly
published, through some out of band trusted channel, than a resolver
administrator can probably keep track of key rollovers and update the
trust anchor annually. With more than 100 different policies all
published through different channels this soon becomes an
unmanageable problem.
In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
track key rollovers and modify the trust-anchor's accordingly. The
algorithm is stateless and does not need protocol extensions.
In Section 4 we describe a method [Editors note: for now only the
frame work and a set of requirements] to install trust anchors. This
method can be used at first configuration or when the trust anchors
became out of sync with the keys published by a zone owner.
The choice for which domains trust anchors are to be configured is a
Ihren, et al. Expires January 7, 2005 [Page 4]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
local policy issue. So is the choice which trust anchors has
prevalence if there are multiple chains of trust to a given piece of
DNS data (e.g. when a domain and its sub-domain both have a trust
anchor configured). Both issues are out of the scope of this
document.
3. M-N Trust Anchor Rollover.
3.1 The Rollover
When a key pair is replaced all signatures (in DNSSEC these are the
RRSIG records) created with the old key will be replaced by new
signatures created by the new key. Access to the new public key is
needed to verify these signatures.
Since a zone signing keys are in "the middle" of a chain of authority
the can be verified using the signature made by a key signing key.
Rollover is therefore transparent to validators. But if a key
signing key is rolled a resolver can determine its authenticity by
either following the authorization chain from the parents DS RR, an
out-of-DNS authentication or by relying on other trust anchors known
for the zone in which the key is rolled. The M-N trust anchor
rollover mechanism, described below, is based on using existing trust
anchors to verify a subset of the available signatures.
Our example pseudo zone below contains a number of key signing keys
numbered 1 through Y and two zone signing keys A and B. During a key
rollover key 2 is replaced by key Y+1. The zone content changes
from:
example.com. DNSKEY key1
example.com. DNSKEY key2
example.com. DNSKEY key3
...
example.com. DNSKEY keyN
example.com. DNSKEY keyA
example.com. DNSKEY keyB
example.com. RRSIG DNSKEY ... (key1)
example.com. RRSIG DNSKEY ... (key2)
example.com. RRSIG DNSKEY ... (key3)
...
example.com. RRSIG DNSKEY ... (keyY)
example.com. RRSIG DNSKEY ... (keyA)
example.com. RRSIG DNSKEY ... (keyB)
to:
Ihren, et al. Expires January 7, 2005 [Page 5]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
example.com. DNSKEY key1
example.com. DNSKEY key3
...
example.com. DNSKEY keyY
example.com. DNSKEY keyY+1
example.com. RRSIG DNSKEY ... (key1)
example.com. RRSIG DNSKEY ... (key3)
...
example.com. RRSIG DNSKEY ... (keyY)
example.com. RRSIG DNSKEY ... (keyY+1)
When the rollover becomes visible to the verifying stub resolver it
will be able to verify the RRSIGs associated with key1, key3 ...
keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will
not be used for validation, since that key is previously unknown and
thereby not trusted.
Note that this example is simplified. Because of operational
considerations described in [5] having a period where the two key
signing keys are available is actually a good idea.
3.2 The Algorithm.
The M-N trust anchor rollover algorithm applies as follows. If for a
particular zone
o at least M public keys from the trust anchors directly verify the
related RRSIGs over the DNSKEY RRset. (the M criterion)
and if
o the number of element in the set difference between 'the set of
keys from the DNSKEY RRset with the SEP bit set' and 'the set of
keys configured as trust anchors' is smaller or equal than N.
(the N criterion)
then all the trust-anchors for the particular zone replaced by the
keys from the zones DNSKEY RR set that have the SEP flag set
The choices for the rollover acceptance policy parameters M and N are
left to the administrator of the resolver. To be certain that a
rollover is picked up by resolvers running this algorithm zone owners
should only roll 1 SEP key at a time. That way they comply to the
most strict rollover acceptance policy of N=1. The value of M is
limited by the amount of SEP keys a zone owner publishes. If the
policy of the zone owner is to use Y SEP keys than the value of M
should be M<=Y-N.
If the rollover acceptance policy is M=1 then the result for the
rollover in our example above should be that the local database of
trusted keys is updated by removing key "key2" and adding key
Ihren, et al. Expires January 7, 2005 [Page 6]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
"keyN+1" to the key store.
3.3 Implementation notes
The DNSSEC protocol ordains that all DNSKEYs should be self-signed.
The implementation should check this. In order to be resilient
against failures the implementation should collect the DNSKEY RRsets
from (other) authoritative servers if verification of the self
signatures fails.
The algorithm SHOULD only be applied to algorithms, as represented in
the algorithm field in the DNSKEY/RRSIG [3], that the resolver is
aware of. In other words the SEP keys of unknown algorithms should
not be used when calculating the set difference for the N parameter
and the SEP keys of unknown algorithm should not be entered as trust
anchors.
If a the M criterion is not met then the set of trust-anchors is out
of sync with the SEP keys in the DNSKEY RRset and some or all of the
trust-anchors are stale. This condition should be flagged. The most
appropriate action is human audit possibly followed by re-priming
(Section 4) the keyset.
An implementation should regularly probe the the authoritative
nameservers for new keys. Since there is no mechanism to publish
rollover frequencies this document RECOMMENDS zone owners not to roll
their key signing keys more often than once per month and resolver
administrators to probe for key rolls (and apply the M-N algorithm)
not less often than once per month. If the rollover frequency is
higher than the probing frequency than trust anchors may become
stale. The exact relation between the frequencies depends on the
amount of SEP keys rolled by the zone owner and the value M
configured by the resolver administrator.
In all the cases below a transaction where M-N algorithm does not
validate should be considered bad (i.e. possibly spoofed or
otherwise corrupted data). The most appropriate action is human
audit.
3.4 Possible transactions.
3.4.1 Single DNSKEY replaced.
This is probably the most typical transaction on the zone owners
part. The result should be that if the M-N algorithm validates then
the key store is updated by removal of the old key and addition of
the new key. Note that if the DNSKEY RRset contains exactly M keys
replacement of keys is not possible.
Ihren, et al. Expires January 7, 2005 [Page 7]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
3.4.2 Addition of a new DNSKEY (no removal)
If M-N algorithm validates then the new key is added to the key
store. Not more than N keys can be added at once.
3.4.3 Removal of old DNSKEY (no addition).
If the M-N algorithm validates then the old key is removed from the
key store. Note that it is not possible to reduce the keyset to a
size smaller than M.
3.4.4 Multiple DNSKEYs replaced.
Not more than N keys can be replace at one time. Since M keys need
to validate the total number of SEP keys in the DNSKEY RRset is M+N.
Since the value of N is set by the resolvers local policy zone owners
should assume N==1 in order to prevent a subset of the resolvers to
become stale because they did not pick up the change.
3.4.5 Only some RRSIGs validate over an unchanged DNSKEY set.
This is a case where the M criterion may not be met, see Section 3.3.
3.5 No need for resolver-side overlap of old and new keys.
It is worth pointing out that there is no need for the resolver to
keep state about old keys versus new keys. From the resolver point
of view there are only trusted and not trusted keys. The reason is
that the zone owner needs to do proper maintenance of RRSIGs
regardless of the resolver rollover mechanism and hence must ensure
that a key is not rolled out out the DNSKEY set until there cannot be
any RRSIGs created by this key still legally cached.
Hence the rollover mechanism is stateless: as soon as the resolver
(or in this case the rollover tracking utility) detects a change in
the DNSKEY set with a sufficient number of matching RRSIGs the
trusted key definition is immediately updated.
4. Bootstrapping automatic rollovers.
It is expected that with the ability to automatically roll trust
anchors at trust points will follow a diminished unwillingness to
roll these keys, since the risks associated with stale keys are
minimized.
The problem of "priming" the trust anchors, or bringing them into
sync (which could happen if a resolver is off line for a long period
Ihren, et al. Expires January 7, 2005 [Page 8]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
in which a set of SEP keys in a zone 'evolve' away from its trust
anchor configuration) remains.
For (re)priming we can rely on out of band technology and we propose
the following framework.
4.1 Priming Keys.
If all the trust anchors roll somewhat frequently (on the order of
months or at most about a year) then it will not be possible to
design a device, or a software distribution that includes trust
anchors, that after being manufactured is put on a shelf for several
key rollover periods before being brought into use (since no trust
anchors that were known at the time of manufacture remain active).
To alleviate this we propose the concept of "priming keys". Priming
keys are ordinary DNSSEC Key Signing Keys with the characteristic
that
o The private part of a priming key signs the DNSKEY RRset at the
security apex, i.e. at least one RRSIG DNSKEY is created by a
priming key rather than by an "ordinary" trust anchor
o the public parts of priming keys are not included in the DNSKEY
RRset. Instead the public parts of priming keys are only
available out-of-band.
o The public parts of the priming keys have a validity period.
Within this period they can be used to obtain trust anchors.
o The priming key pairs are long lived (relative to the key rollover
period.)
4.1.1 Bootstrapping trust-anchors using a priming key.
To install the trust-anchor for a particular security apex an
administrator of a validating resolver will need to:
o query for the DNSKEY RR set of the zone at the security apex;
o verify the self signatures of all DNSKEYs in the RRset;
o verify the signature of the RRSIG made with a priming key --
verification using one of the public priming keys that is valid at
that moment is sufficient;
o create the trust anchors by extracting the DNSKEY RRs with the SEP
flag set.
The SEP keys with algorithms unknown to the validating resolver
SHOULD be ignored during the creation of the trust anchors.
4.1.2 Distribution of priming keys.
The public parts of the priming keys SHOULD be distributed
exclusively through out-of-DNS mechanisms. The requirements for a
distribution mechanism are:
Ihren, et al. Expires January 7, 2005 [Page 9]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
o it can carry the "validity" period for the priming keys;
o it can carry the self-signature of the priming keys;
o and it allows for verification using trust relations outside the
DNS.
A distribution mechanism would benefit from:
o the availability of revocation lists;
o the ability of carrying zone owners policy information such as
recommended values for "M" and "N" and a rollover frequency;
o and the technology on which is based is readily available.
[Editors Note:
X.509 technology is a logical candidate for the distribution of
priming keys. The exact details need further research.
What we probably need a convention on the use id-ce-keyUsage, the
id-ce-extKeyUsage (assignment of a KeyPurposeId) and other relevant
field [6]. Is there a possibility to store the keyroll policy
information? PKIX specialist are invited to give their input.
End of Editors note]
5. M-N algorithm vs Priming
There is overlap in the M-N algorithm and the Priming method. One
could exclusively use the Priming method for maintaining the trust
anchors. However the priming method probably relies on "non-DNS'
technology and may therefore not be available for all devices that
have a resolver.
6. Security Considerations.
6.1 M-N Algorithm Security Considerations
A clear issue for resolvers will be how to ensure that they track all
rollover events for the zones they have configure trust anchors for.
Because of temporary outages validating resolvers may have missed a
rollover of a KSK. The parameters that determine the robustness
against failures are: a long period between rollovers during which
the KSK set is stable and validating resolvers can actually notice
the change; the number of KSKs and the value of M.
With a large number of KSKs and a small value of M this operation
becomes more robust since losing one key, for whatever reason, will
not be crucial. Unfortunately the choice for the number of KSKs is a
local policy issue for the zone owner while the choice for the
parameter M is a local policy issue resolvers administrator.
Ihren, et al. Expires January 7, 2005 [Page 10]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
Higher values of M increase the resilience against attacks somewhat;
more signatures need to verify before a rollover is approved.
The M-N algorithm does not provide a revocation mechanism. In the
case that the private keys of a zone owner are compromised the
culprit may use these private keys to roll the trust anchors of (a
subset of) the resolvers.
6.2 Priming Key Security Considerations
Since priming keys are not included in the DNSKEY RR set they are
less sensitive to packet size constraints and can be chosen
relatively large. The private parts are only needed to sign the
DNSKEY RR set during the validity period of the particular priming
key pair. Note that the private part of the priming key is used each
time when a DNSKEY RRset has to be resigned in practice there shall
little difference between the usage pattern of the private part of
key signing keys and priming keys.
7. IANA Considerations.
NONE.
8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
(DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
RFC 3757, May 2004.
[3] Arends, R., "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-04 (work in progress),
September 2003.
8.2 Informative References
[4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
"DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-10 (work in progress), May 2004.
[5] Kolkman, O., "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practices-01 (work in
progress), May 2004.
Ihren, et al. Expires January 7, 2005 [Page 11]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
[6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", RFC
2459, January 1999.
Authors' Addresses
Johan Ihren
Autonimica AB
Bellmansgaten 30
Stockholm SE-118 47
Sweden
EMail: johani@autonomica.se
Olaf M. Kolkman
RIPE NCC
Singel 256
Amsterdam 1016 AB
NL
Phone: +31 20 535 4444
EMail: olaf@ripe.net
URI: http://www.ripe.net/
Bill Manning
EP.net
Marina del Rey, CA 90295
USA
Appendix A. Acknowledgments
The present design for in-band automatic rollovers of DNSSEC trust
anchors is the result of many conversations and it is no longer
possible to remember exactly who contributed what.
In addition we've also had appreciated help from (in no particular
order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
Larson and Mark Kosters.
Appendix B. Document History
This appendix will be removed if and when the document is submitted
to the RFC editor.
The version you are reading is tagged as $Revision: 1.5 $.
Ihren, et al. Expires January 7, 2005 [Page 12]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
Text between square brackets, other than references, are editorial
comments and will be removed.
B.1 version 00
Kolkman documented the ideas provided by Ihren and Manning. In the
process of documenting (and prototyping) Kolkman changed some of the
details of the M-N algorithms working. Ihren did not have a change
to review the draft before Kolkman posted;
Kolkman takes responsibilities for omissions, fuzzy definitions and
mistakes.
Ihren, et al. Expires January 7, 2005 [Page 13]
Internet-Draft DNSSEC Key Rollover and Priming July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ihren, et al. Expires January 7, 2005 [Page 14]