DNS Extensions Working Group W. Wijngaards Internet-Draft NLnet Labs Intended status: Standards Track March 2007 Expires: September 2, 2007 DNSSEC Trust Anchor History Service draft-wijngaards-dnsext-trust-history-00 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 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off. The service can be made to withstand multiple key compromises and large-scale spoofing. Wijngaards Expires September 2, 2007 [Page 1] Internet-Draft Trust History Service March 2007 Requirements Language 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 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 3. Key History Resource Record Types . . . . . . . . . . . . . . 4 3.1. The KEYHIST_LOC RRType . . . . . . . . . . . . . . . . . . 4 3.1.1. Wire Format . . . . . . . . . . . . . . . . . . . . . 4 3.1.2. Presentation Format . . . . . . . . . . . . . . . . . 5 3.2. The KEYHIST_CHAIN RRType . . . . . . . . . . . . . . . . . 5 3.2.1. Wire Format . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Presentation Format . . . . . . . . . . . . . . . . . 6 3.3. The KEYHIST_SIG RRType . . . . . . . . . . . . . . . . . . 7 4. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Rollover of Stale Trust Anchors . . . . . . . . . . . . . 7 4.2. Validator Check of History Node . . . . . . . . . . . . . 8 5. Signer Considerations . . . . . . . . . . . . . . . . . . . . 9 6. Priming Keys . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Wijngaards Expires September 2, 2007 [Page 2] Internet-Draft Trust History Service March 2007 1. Introduction When DNS validators have trusted keys, but have been offline for a longer period, trusted key rollover will fail. A method is presented to establish trust in current DNSKEYs. The method requires new RR types to hold the historical information, and requires implementation of the algorithm by the zone signer and validator. Zone operators and validators can deploy the method independently and incrementally. The stale trust anchor rollover is vulnerable to a single key compromise coupled with a server take-over. A more secure rollover method can be selected by the zone owner. This more secure priming (with the prime bit set) rollover is described in Section 6. The priming rollover method can resist N-1 key compromises, with N the number of keys in the trusted priming key set held by the validator. For priming keys, which are retrieved using many small queries, key size is limited by the size that will fit in one packet. The number of keys can be up to 255. A zone operator can choose the keysize and number of keys. 2. Theory of Operation The basic mode of operation for the trust anchor history is to present a playback of historical states of the DNSKEY RRSet to the validator. The validator can then roll-forward the trust anchor using its trust anchor rollover algorithm. It is assumed [draft- timers] is used to rollover, however, if it fails with stale trust anchors the mechanism from this draft can be used to freshen the trust anchors. The validator that requests history replay starts by requesting the DNSKEY RRSet as is currently present for the trust point. The validator then requests the previous RRSet, which comes signed and dated with a timestamp. The validator continues to request previous RRSets until it finds one that is signed by a key it trusts, or the server indicates no more are available. The validator can then reconstruct the key rollover from the past timepoints to the current keyset at the trust point. The validator does not have to cache all of the zone history, it can use queries to walk forwards and backwards through the list of keysets. To be able to request and serve historical DNSKEY RRSets, new RR Types are added, KEYHIST_LOC, KEYHIST_CHAIN and KEYHIST_SIG. The KEYHIST_LOC RR is used to locate the historical information. The Wijngaards Expires September 2, 2007 [Page 3] Internet-Draft Trust History Service March 2007 historical information can be spread out over a number of domains, so that packet size can stay small. The validator queries each of these domains, and assembles the final set of DNSKEY, KEYHIST_SIG and KEYHIST_CHAIN RRs together. In this way the zone operator can use very large key sizes, while keeping packets within acceptable limits. The DNSKEY RRs hold the keys. The KEYHIST_CHAIN RR holds hashes of DNSKEY RRsets, and is signed. It securely links together the historical information. The KEYHIST_SIG RR is the same format as an RRSIG, but the signature is historical. The signature it holds can be expired, but valid in the past. It is used to sign the DNSKEY and KEYHIST_CHAIN types. The time at which the KEYHIST_SIGs are valid is stored in the KEYHIST_CHAIN type. 3. Key History Resource Record Types 3.1. The KEYHIST_LOC RRType The KEYHIST_LOC RR type has type code (TBD) (decimal). It is class independent. History RR types pertaining to DNSKEYs MUST be of the same class as those DNSKEYs. This RR Type is used to find the historical information that is stored in the DNS. It is signed with the regular zone signing key(s). 3.1.1. Wire Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|P|MBZ flags|I| Previous moment (dname) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Next moment (dname) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / more history storage (dname) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the N or P flag (Bit 0, 1) is set, then the Next or Previous moment field is not present. Other flag fields MUST be set to zero, validators MUST ignore KEYHIST_LOC RRs with these flags set. Bit 7 (I) is the prime flag, denoting that the validator needs to have a priming key set to use this set of history data. The more history storage dname is always present. At this domain another KEYHIST_LOC is present, forming a cyclic linked list. All domain names are Wijngaards Expires September 2, 2007 [Page 4] Internet-Draft Trust History Service March 2007 stored in uncompressed format. 3.1.2. Presentation Format KEYHIST_LOC flags: unsigned integer octet representing flags. Bit 0 means 'no next record'. Bit 1 means 'no previous record'. Bit 7 means 'priming keys'. prev_domain: The domain name where a KEYHIST_LOC older than this set of information can be found. Stored as an uncompressed domain name. Not presented if the 'no previous record' flag is set. next_domain: The domain name where a KEYHIST_LOC newer than this information can be found. Stored as an uncompressed domain name. Not presented if the 'no next record' flag is set. more_domain: A domain name where another KEYHIST_LOC is present. And also more historical data is present at that point. The KEYHIST_LOCs form a cyclic linked list with the more_domains pointing to another. The prev and next moment of all the KEYHIST_LOCs in the same more_domain list are all the same. This is where the historical information can be found. At these domains the RR Types KEYHIST_CHAIN, KEYHIST_SIG and DNSKEY can be found. Stored as uncompressed domain name. 3.2. The KEYHIST_CHAIN RRType The KEYHIST_CHAIN RR type has type code (TBD) (decimal). It is class independent. This RR Type is used to sign hashes of historical DNSKEY RRsets. It MAY be signed with the regular zone signing keys as well, but MUST be signed with KEYHIST_SIG signatures by all keys in the DNSKEY RRset covered by this_hash. The DNSKEY keys and KEYHIST_SIG signatures is spread out over the list of domains from the KEYHIST_LOC type. 3.2.1. Wire Format Wijngaards Expires September 2, 2007 [Page 5] Internet-Draft Trust History Service March 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|P|MBZ Flags|I| Hash algo. | Hash length | number of keys| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous hash data octets / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | This hash data octects / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next hash data octets / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | first key_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key_id ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If bit 0 or 1 (Next or Previous omitted) is set, the previous hash or the next hash field is omitted. The this_hash field is always present. The hash length is in octets. The hashes use the same algorithm, and so have the same length, if they are present. The hash length depends on the hash algorithm. The MBZ flags MUST be set to zero. Validators MUST ignore RRs with these flags set. The I field, bit 7, is the priming keys flag, denoting that all keys MUST match the known trusted keys by the validator, for the validator to consider trusting this KEYHIST_CHAIN and ending rollover. 3.2.2. Presentation Format KEYHIST_CHAIN ... flags: Presented as unsigned integer. Bit 7 means 'priming keys'. Bits 0 and 1 are set if there are no next or previous historical rrsets. The hashes are then ommitted from presentation. algo: Hash algorithm used. Unsigned integer presentation format, one octet. Same list of values as the DS record. hash_length: This field is presented as an unsigned integer. num_keys: The number of DNSKEYs in the DNSKEY RRset covered by this_hash. Unsigned integer, one octet. prev_hash: The hashes are presented by a sequence of hexadecimal characters. The field is ommitted if not present. The prev_hash is the hash algorithm applied to the DNSKEY RRset before this one, the owner names of the DNSKEY RRset are set to the zone apex when taking the hash and signatures (exactly as the DNSKEY RRset was when it was in use). If there is no previous DNSKEY RRset it is not present. Wijngaards Expires September 2, 2007 [Page 6] Internet-Draft Trust History Service March 2007 this_hash: Encoded like prev_hash. Hash over the DNSKEY RRset as found when querying all data_domains from the KEYHIST_LOC RR, taken together, with owner name equal to the zone apex. next_hash: Encoded like prev_hash. Hash over the next DNSKEY RRset. If there is no next DNSKEY RRset, it is not present. timestamp: The timestamp is presented the same as the RRSIG timestamps. Either as an unsigned decimal integer indicating seconds since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC [RFC4034]. This is the time at which this DNSKEY RRset is valid. The KEYHIST_SIGs over the DNSKEY and KEYHIST_CHAIN RRsets MUST be valid at this time. key_ids: The Key ID of every DNSKEY RR key is given, in ascending order as unsigned 16-bit numbers. If there are keys in the RRset with the same ID, that ID is stated twice. This is the same ID as stored in RRSIGs. These ids are present to assist validator lookups, so that the validator can check number and IDs of keys that were fetched before attempting validation. 3.3. The KEYHIST_SIG RRType This RRtype has type code (TBD) (decimal). The presentation and wireformat of the rdata is the same as for the RRSIG type. It is used to sign the DNSKEY and KEYHIST_CHAIN types. It is different from RRSIG in that the signature may be expired, but was valid at the time in the timestamp from the KEYHIST_CHAIN. Another difference with RRSIGs is that KEYHIST_SIG does not require special processing. It is queried for directly. KEYHIST_SIG signatures may be stored at a different node than the RRset they sign. The KEYHIST_LOC type provides the location of the historical RRsets and signatures. Both historical DNSKEY and historical KEYHIST_CHAIN types require that the owner name be set to the zone apex name of the zone for which trust anchors are sought, before the KEYHIST_SIG signature is validated. 4. Processing 4.1. Rollover of Stale Trust Anchors 1. The first step is a query that looks exactly like a regular rollover query. This query is for the zone DNSKEY RRset. It MUST be exactly like a regular rollover, so that an attacker finds it hard to distinguish clients with stale keys from regular clients. The results from this query MUST be stored. The rollover algorithm MUST end up at this DNSKEY RRset. If any or all of these checks fail the rollover fails. Wijngaards Expires September 2, 2007 [Page 7] Internet-Draft Trust History Service March 2007 2. The validator then looks for history service. Query for KEYHIST_LOC at the zone apex. If no history is available, the rollover fails. If history is available, the KEYHIST_LOC type will point to the data domains where the KEYHIST_CHAIN, DNSKEY and KEYHIST_SIG RRs for the DNSKEY rrset that is currently in use can be found. The validator MUST fetch these. The DNSKEYs found MUST equal the SEP keys from the set found in step 1. 3. The validator checks the gathered types, as described in Section 4.2. If checks fail, the rollover fails. 4. The validator fetches the KEYHIST_LOC type from the domain name listed in the prev_domain field. This can lead to a subzone of the original zone. In that case the delegation MUST be signed (with valid DS) by the keys from step 1. This KEYHIST_LOC type MUST be signed by one of the zone keys from step 1. 5. Fetch the history RRs from the data domains. Check them as described in Section 4.2. 6. If this RRset contains trusted keys, then the rollover is done. The trust anchor state can be brought into correct state by performing key rollover at the timepoints from KEYHIST_CHAIN. This rollover MUST end in the keyset from step 1. 7. Because of DNS timing issues, the trust keys held by a validator may not be exactly one DNSKEY RRset from the history. In that case some of the trusted keys can be found in older DNSKEY RRsets. 8. The validator continues to an older DNSKEY RRset, go to step 4. 4.2. Validator Check of History Node This section describes the checks needed to validate a history node. First the necessary information MUST be queried from the more data domains listed in the KEYHIST_LOC type. Also the owner name of the KEYHIST_LOC RR MUST be queried for historical data. Note that the last KEYHIST_LOC more_domain points back to the first, and all have the same priming flag, previous and next values. The hashvalue of the DNSKEY RRset at this node, with the owner names replaced by the zone apex (of the zone that is rolled over) MUST match the this_hash value. The reason to replace the owner name before hashing is so that the history data may be moved after creation without needing the old key private data. The hashvalues prev_hash and next_hash MUST also be correct. The next_hash value MUST be NULL if the KEYHIST_LOC has been retrieved from the rollover zone apex domain name. The prev_hash value is only NULL if no more history is available. The prev_hash value MUST be equal to the hash of the DNSKEY RRset from the previous history node. The next_hash value MUST be equal to the hash of the DNSKEY RRset from the next history node. Wijngaards Expires September 2, 2007 [Page 8] Internet-Draft Trust History Service March 2007 Since the validator algorithm specifies to walk the history from new to old, the hash checking is as follows. The this_hash is checked for the current node. The last seen node's prev_hash value MUST equal the hash of the DNSKEYs found in the current node. The next_hash value for this node MUST equal the hash of the DNSKEYs from the last seen node. The number of DNSKEYs in the KEYHIST_CHAIN, and the key ids in the KEYHIST_CHAIN MUST be correct. The KEYHIST_SIG over the KEYHIST_CHAIN MUST validate. Validation is performed at the time from the timestamp in the KEYHIST_CHAIN. All keys in the DNSKEY RRset MUST sign the KEYHIST_CHAIN in this way. This signs the timestamp, and hashes of the current, previous and next DNSKEY RRsets. The KEYHIST_SIG over the DNSKEY MUST validate. Validation is performed at the time from the timestamp in the KEYHIST_CHAIN. All keys in the DNSKEY RRset MUST sign the DNSKEY RRset in this way. Keys MUST NOT be used for signatures, using KEYHIST_SIG entries in the history chain, when they have previously been revoked. Keys are revoked via a self-signed revocation signature. The revocation flag in DNSKEY is discussed in [draft-timers]. To check that this does not happen, the validator MUST keep track of the keys that have been used to sign keysets in the future, which means it has seen them already since it queries from future to past. If a revocation of a key is seen which is also used for signatures at a future moment, then the rollover fails. The timestamp MUST be smaller (using serial arithmatic [RFC1982]) than the timestamp from the last seen newer node. 5. Signer Considerations The zone operator is to provide a key history to the server, produced by a signer. The RR formats are such that private key data for old keys can be discarded, only the current and the previous set of keys are needed. The data can be treated as unknown RR types by servers, caches and intermediate resolvers. The zone operator may opt to move the history data after it has been created, since it is not the location but content that verifies the keys. The data may be moved without needing private key data, since the KEYHIST_LOC type is signed using the current zone signing keys. Also, the owner name of DNSKEY and KEYHIST_CHAIN types is changed to the rollover zone apex name before hashing or verifying signatures. The zone operator may move history service to a signed subzone of the zone, to move key history query load to other authoritative servers. The history store Wijngaards Expires September 2, 2007 [Page 9] Internet-Draft Trust History Service March 2007 is stored at domain names chosen by the operator, for example numbered sequentially, or by date. The data may be divided onto many domains to make packet sizes smaller. The signer SHOULD provide an option to set a maximum history reply size that is acceptable so that it can divide the data over multiple domains as needed. The signer produces normal zone signing RRSIGs as well as KEYHIST_SIGs as needed for historical data storage points. 6. Priming Keys Because the stale trust anchor rollover presented before can be broken by an attacker obtaining the key material for one of the trust keys, a more secure method is presented here. The zone owner can opt to provide priming keys. These keys MUST NOT be kept up to date using frequent polls. That is what [draft-timers] is for. A validator only needs to rollover priming keys when the trust anchors go stale. Priming key RRsets MUST be kept as a whole RRset. All the priming keys MUST be used whenever the set is used to sign or validate. The priming bit in the flags field of KEYHIST_LOC and KEYHIST_CHAIN RRs found MUST be set, when validating a priming key rollover. The method for rollover is the same. However, rollover does not stop when one trust key is detected, but when the set of DNSKEYs equals the set of priming keys that the validator trusts, and all signatures validate. The effect is that instead of one trust anchor key, all priming keys provide protection. Since no trust anchor intermediate states are retrieved, the keys found in step 1 are set as trusted keys without performing the rollover algorithm and possibly an updated set of priming keys is stored for later use. 7. Security Considerations If the attacker does not crack current keys, or spoof the initial queries, the trust roll over will end at the current SEP keys. The situation where the attacker cracks current keys is not considered further. There is no security using key history service in that case. Assuming the attacker spoofs the initial queries, in addition the attacker needs to have obtained the trusted keys that the validator possesses. An additional obstacle presented to the attacker by history service is that validators with stale trust anchors are not distinguishable from validators with valid ones, when they query for Wijngaards Expires September 2, 2007 [Page 10] Internet-Draft Trust History Service March 2007 the current zone DNSKEY RRset. And further, the validator does not reveal which trust anchor it is holding until it stops the query process. An attacker needs other information (such as IP addresses) to identify victims. Or the attacker provides false information to validators with correct trust anchors. Those validators will flag the information as bogus, and attract attention from the zone operator, revealing the attack attempt. In the case that the attacker has obtained the old trust anchor, can spoof all of the queries, and is able to identify the victim or willing to reveal the attack in progress, then the algorithm for stale trust anchor rollover fails to be secure. If operators feel that their zone needs additional security against this threat, they can use the priming keys option, described in Section 6. A validator can download a set of priming keys using a valid trust anchor at any time, or get them via software updates. The priming keys can be very large, and a large number. Priming keys are only rolled over when trust anchors go stale. Priming keys are always obtained in a full set and they MUST all verify the RRsets together. This means an attacker needs to obtain the key material for all of the priming keys, and spoof queries as for the above case, to be able to subvert the rollover. The validator can follow a signed delegation to a subzone to get history information. The signature uses the untrusted current zone keys. A spoofing attacker can redirect a validator in this way. However, this simply amounts to more spoofing by the attacker. The signatures and DS are validated to raise the bar on spoofing the delegation. The stale trust anchor rollover performs rollover of the trust anchor according to [draft-timers]. However, the final state is then under a hold-down timer of 30 days. This means no trust anchors may be used for 30 days, which is not attractive for people who have been offline for a long time (and need their software security updates from a secure site). The KEYHIST_CHAIN self-signed timestamps MAY be used to determine if the hold-down period has passed for some of the keys from the final keyset, but this fails to provide real timing security. The priming keys algorithm, which has larger keysizes or more keys, also defeats the hold-down period for the final keyset, as it is trusted immediately. None of the historical key private material needs to be online for a server to provide history service. They are only needed by the signer, when the key is rolled over. Private key material may be discarded for old keys. Wijngaards Expires September 2, 2007 [Page 11] Internet-Draft Trust History Service March 2007 Because the validator walks the history in reverse first, it will see all revoked keys with the revocation bit on first. The validator MUST NOT trust such keys for present-day validation. If the priming keys method is used, a validator may opt to walk the non-priming key history service to determine which keys have been revoked, or simply choose to remove all stale trust anchors when the priming rollover completes. Keys that have been revoked can be used to self-sign keysets at time moments before their revocation. The older entries are unchanged, partly to make it possible to discard old key private data. And partly because the validator can handle these cases. Since the validator walks the history backwards, it sees revocations first, and can ignore signatures from revoked keys on older keysets in the history chain. If all keys that a validator trusts are revoked, then, although rollover fails, the validator has gained the revocation knowledge and will not put false trust these keys. The KEYHIST_CHAIN requires second preimage resistance of the hash function. But if that property is lost, RRSIGs on the current zone are broken as well. The algorithm can be abused to provide a secure method to get (close to) the current month or year. Validators without clock then know the date that validates DNSKEY RRSIGs currently in use by the zone. 8. IANA Considerations New Resource Record type codes for KEYHIST_LOC, KEYHIST_CHAIN and KEYHIST_SIG. 9. Normative References [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. Wijngaards Expires September 2, 2007 [Page 12] Internet-Draft Trust History Service March 2007 Author's Address Wouter Wijngaards NLnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands Phone: +31-20-888-4551 Fax: +31-20-888-4462 EMail: wouter@nlnetlabs.nl Wijngaards Expires September 2, 2007 [Page 13] Internet-Draft Trust History Service March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wijngaards Expires September 2, 2007 [Page 14]