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, 0 insertions, 730 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 deleted file mode 100644 index 7cb9063..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt +++ /dev/null @@ -1,730 +0,0 @@ - - - - -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] - - |
