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