Internet Draft D. Groth Intended status: Experimental ITUA Inc. Expires: 11 January 2009 15 July 2008 DNS Encryption draft-groth-dns-encryption-02.txt 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 11 January 2009. Abstract This document requests IANA registration of a new DNS OpCode and ErrorCode type in facilitating encryption of DNS requests and replies and feed back to the client if plain text requests are not acceptable. Once this OpCode is seen the DNS server attempts to decrypt the request using its private OpenPGP key. Inside the encrypted packet is the AES key which the client expects to be used when the server encrypts a response. A server may advertise that it is capable of DNS encryption by returning OpenPGP fingerprints in TXT records using a similar format to Public Key Association (PKA). The full pubic keys are returned from DNS servers by using a CERT request against the host name(s) of the domain's NS records or via OpenPGP key servers. Groth, D. Expires 11 January 2009 [Page 1] Internet-Draft DNS Encryption July 2008 Table of Contents 1. Introduction.....................................................4 2. Why not to use X.509.............................................4 2.1. X.509 and Web Browser Pop-ups...............................4 2.2. X.509 and SMTP..............................................4 2.3. Problems with X.509 and SMTP................................4 2.4. The Skype Solution..........................................5 2.5. Windows and the Mozilla Foundation..........................5 3. One way to secure DNS............................................5 3.1. Using X.509 and SMTP as a basis.............................5 3.2. So why use OpenPGP instead of X.509.........................6 3.3. Extended or No Expiry Keys and Certificates.................6 4. Using OpenPGP to Compute Key Confidence..........................6 4.1. Confidence Introduction.....................................6 4.2. 6 degrees of separation in a practical sense................7 4.3. Refining Confidence Scores..................................7 4.4. Out of band fingerprint verification........................8 4.5. OpenPGP information and commercial services.................8 5. Structure of Host Information in OpenPGP Keys....................8 5.1. FQDN........................................................8 5.2. The Use of Wild Cards.......................................9 5.3. Extended Information in User Ids............................9 5.4. Separation of Fields........................................9 5.5. Name Servers with Multiple Host Names......................10 5.6. Multiple Host Name Example.................................10 6. Storing OpenPGP keys in DNS.....................................10 6.1. Storing Stripped Public Keys...............................10 6.2. Retrieving Meta Information................................10 7. DNS Packet Structure............................................10 7.1. Unencrypted DNS Packet Structure...........................10 7.2. Encrypted DNS Packet Structure.............................11 8. Advertising Encryption Capability With Additional Records.......11 8.1. Fingerprints in TXT Records................................11 8.2. Structure of TXT Records...................................11 8.3. TXT Record Example.........................................12 8.4. Glue Records...............................................12 8.5. Additional Records.........................................12 9. Security Considerations.........................................12 9.1. DNS is inherently insecure.................................12 9.2. Reducing Information Leaks.................................12 10. IANA Considerations............................................13 11. Conclusions....................................................13 12. Informative References.........................................14 13. Acknowledgements...............................................15 Author's Addresses.................................................15 Intellectual Property Statements...................................16 Disclaimer of Validity.............................................16 Copyright Statement................................................16 Groth, D. Expires 11 January 2009 [Page 2] Internet-Draft DNS Encryption July 2008 1. Introduction DNS (RFC 1034, RFC 1035) is a global system; NAPTR records (RFC 3401, RFC 3402, RFC 3403, RFC 3404, RFC 3761), a subset of DNS services, is the first of possibly many such DNS services which reveal sensitive information about the querying agent when requests are sent, regardless of any replies returned. This query information alone is of value to entities in a position to monitor network points. While there is ongoing work with DNSsec to verify the authenticity of DNS replies which would facilitate the detection of tampering, no active effort is focused on protecting the confidentiality of DNS requests and replies. 2. Why not to use X.509 2.1. X.509 and Web Browser Pop-ups X.509 certificates (RFC 5280) combined with web browser pop-ups have, in hind sight, proven to be bad for security. The adoption of self- signed and invalid or expired SSL certificates for websites out number certificates that would be deemed valid by most web browsers. However the overall adoption of SSL for websites is very low, less then a tenth of a percent according to Netcraft. 2.2. X.509 and SMTP X.509 usage with SMTP on the other hand seems to buck the trend observed with web browsers in the absence of pop-up warnings. Adoption estimates currently range up to 50% of all legitimate MTA servers on the Internet. Very few servers use commercial certificates as most people see no advantage in spending money on something they perceive to have no additional tangible benefit, and there is no disadvantage in not purchasing one. 2.3. Problems with X.509 and SMTP Even with the comparatively high adoption rate of X.509 with SMTP there is still problems. Most problems stem from X.509 extensions being incorrectly set, which in most cases prevents the key pair from being used for both client and server purposes. This can lead to lost email if the MTA fails or refuses to fall back to non-encrypted transfers. Due to the way X.509 has been implemented in most software there is no clear path to easily increase security across the internet as a whole for SMTP beyond installing a large number of root certificates, self signed certificates or simply accepting all. This is a big Groth, D. Expires 11 January 2009 [Page 3] Internet-Draft DNS Encryption July 2008 disadvantage in the long term in achieving strong confidence that servers being connected to really are who they claim to be and not a man-in-the-middle attack. 2.4. The Skype Solution Looking beyond X.509, it is imperative to reach security paradigms that will actually be beneficial for internet users, rather than road blocks. Skype has proven this to some extent by hiding all the encryption from the user and just letting them get on and use it, rather than annoying the user with a constant barrage of pop-up windows. 2.5. Windows and the Mozilla Foundation Windows Vista on the other hand has demonstrated how a constant barrage of pop-up windows does little, if anything for security, and only serves to confuse or annoy most users who click through regardless of what the pop-up is, most of the time. Mozilla Foundation also seems to be ignoring the lessons from the present and the past and has gone down a similar path for certificates of unknown origin. It is now easier to install a root certificate than accept a connection to a server with a self signed or invalid certificate. 3. One way to secure DNS 3.1. Using X.509 and SMTP as a basis To achieve a beneficial outcome we can review similar protocols that achieve a somewhat successful outcome, since Skype doesn't disclose what they do on a technical level we will instead turn our focus to X.509 with SMTP, which seems to be most widely deployed protocol that is openly documented. One method to enable encryption with SMTP that cannot be directly transferred to DNS is by escalating the TLS session by sending the 'STARTTLS' command. This is because SMTP only uses ASCII, where as DNS is a binary based protocol. Instead all we need to do is examine the OpCode contained at the third byte of all DNS requests to determine if the DNS request is encrypted, this draft requests that IANA allocate a new OpCode for this purpose. Once this OpCode is detected, name servers supporting this capability will attempt to decrypt from the 4th byte onwards. Groth, D. Expires 11 January 2009 [Page 4] Internet-Draft DNS Encryption July 2008 3.2. So why use OpenPGP instead of X.509 Unlike X.509, OpenPGP (RFC 4880) is currently widely used, people have been holding key signing parties for more than a decade. Instead of trying to build completely new infrastructure it makes more sense to make use of what's already available in abundance. Other more structured examples of this include CAcert www.cacert.org and The Gossamer Spider Web of Trust www.gswot.org. 3.3. Extended or No Expiry Keys and Certificates With current threats existing for very short periods, typically hours to days at most, there is no practical reason for keys to expire in 1 or even 5 years, the primary reason most certificates expire with such frequency is due to monetary reason which is detrimental to security. OpenPGP keys can be cached which is advantageous in preventing or detecting man in the middle attacks. This would make such attacks more costly to operate. While not directly related to the this topic, internet browsers do not warn or otherwise notify the user when a certificate for a website has changed, making it virtually impossible to detect a man in the middle attack to be discovered, or even notice once it has ceased. Constantly changing certificates seem to be a bad security practise. 4. Using OpenPGP to Compute Key Confidence 4.1. Confidence Introduction The word trust has long been abused by mathematicians and cryptographers alike to mean how much confidence you have that the key belongs to the people you think it does. No two people use the OpenPGP trust options in an identical manner, just like no two people would rank a room full of people in the same manner with respect to the task of how much confidence they would place in the person really having the OpenPGP User ID they purport to own. Currently most X.509 certificates are issued in a way that people see virtually no difference between certificate authorities, it's not until you get into the finer points of their issuing practises and policies that you can begin to build a similar confidence in each certificate authority and the certificates they issue. The confidence system OpenPGP adopted normally has coarse options in which individuals can be grouped, that isn't to say software built around OpenPGP keys can't build its own system in a much more refined way, either with individual exceptions or by being able to Groth, D. Expires 11 January 2009 [Page 5] Internet-Draft DNS Encryption July 2008 group individuals into groups or classes of users based on the confidence you have in those people to introduce other keys to you. 4.2. 6 degrees of separation in a practical sense The PGP web of trust is in part based on the 6 degrees of separation principal, that is everyone in the world knows everyone else through 6 other people. For the purpose of generating a tangible confidence rating that a host controls a particular host key we will be using arbitrary numbers. Default values of 50 points for fully trusted keys and 30 points for marginally trusted keys are good base values although any arbitrary number should work, but may vary based on individual circumstances. For anyone we don't know directly we will calculate trust paths between keys by decaying points from the second relationship outwards. Again these are arbitrary values and they can be customised based on individual needs. The general case will use a base of 50% for full trust introduction, 25% trust for marginal introduction, -25% for untrustworthy and 0% for don't know. You follow trust paths between the local key ring and the key of the name server you are intending to request information from, branching out until you get a points value of 0 or less, or find a direct path to the host key. In either case you no longer follow that branch any further. For the system to be confident about an OpenPGP key you set the minimum points required, again this can be any arbitrary number such as 100. 4.3. Refining Confidence Scores The system must have the ability for more finely grained control over individual scores. The default method in OpenPGP is too coarse, and doesn't easily allow you to distinguish between the capabilities of different individuals. For example you trust Bob's judgement when verifying other people holding the right keys more than most. You add an exception for Bob so that anything he trusts will be assigned 75 points instead of 50. Alice on the other hand is gullible. While you trust Alice, you don't trust the verifications she makes. An exception is made for Alice so that anything Alice trusts will only be assigned 10 points. In this hypothetical example, even with both Alice and Bob trusting a key your system still wouldn't hit the 100 points needed, so you obviously need to get out and make more friends. Groth, D. Expires 11 January 2009 [Page 6] Internet-Draft DNS Encryption July 2008 4.4. Out of band fingerprint verification Just as people already hold key signing parties to verify each others OpenPGP user ids, variations on this would start to appear depending on the level each party needs or wants to secure their resources. It is a reasonable assumption that not all domains need strong protection, and it is up to both the administrators of domains and those making DNS requests to have the right level of security for their needs. For example the domain of a bank would be at more at risk and hence worth protecting more than a personal domain for someone's blog that gets 10 hits a month. Banks already have a relationship with their customers and it would be easy for them to provide the fingerprint of their user ids on business cards and other stationary items. This process is commonly used to verify personal keys but there is no reason this concept couldn't be extended so people could also sign host keys. The worst level of security would be no different to most mail servers using self signed certificates for SMTP-TLS. 4.5. OpenPGP information and commercial services It is possible to leverage existing OpenPGP web of trust meta information to draw similar security decisions about X.509 certificates issued by commercial Certificate Authorities. While the focus of this draft is on individuals making their own security choices, there is nothing preventing commercial entities from offering signing services against host keys. The standard practise is for OpenPGP user ids to be signed by multiple entities, and this practise could be utilised by multiple commercial entities, which would potentially increase security. 5. Structure of Host Information in OpenPGP Keys 5.1. FQDN OpenPGP was designed specifically for text based communication and file encryption, so most of the user id sections of keys contain a name, an email address and possibly a comment. This field can contain any valid UTF-8 string, so computer based systems can easily parse the information present in this string there needs to be a fixed format adhered to, unlike computers humans can more easily cope with variations. The client will compare the host name of the system it connects with to all host names appearing in user ids. All host names MUST BE prefixed with 'dns:'; Groth, D. Expires 11 January 2009 [Page 7] Internet-Draft DNS Encryption July 2008 dns:nameserver.example.com 5.2. The Use of Wild Cards Wild card host names are allowed, however only one level is allowed, so *.example.com would match nameserver.example.com and a.example.com but would not match this.nameserver.example.com. Multiple wild card characters per host name are not allowed, *.*.example.com 5.3. Extended Information in User Ids Extended information in OpenPGP user ids such as the information that can be contained in X.509 certificates (RFC 3280) is desirable. These fields must be only used for informational purposes only. All prefixes must be lower case and the 'dns' prefix is mandatory and must always exist in each host user id however all other prefixes may be absent or must only appear once per user id, for the purposes of this internet draft the only valid prefixes in OpenPGP user ids are; c: can be used as the prefix for any valid 2 letter ISO country code, e.g. c:ccTLD st: can be used as the prefix for state, province or territory designation, e.g. st:State Name l: can be used as the prefix for location, such as town, suburb or city name, e.g. l:Town Name o: can be used as the prefix for organisation or company name, e.g. o:Example Company ou: can be used as the prefix for organisation unit, or department in the organisation the information applies to, e.g. ou:Server Administration uri: can be used as the prefix for valid URIs, e.g. uri:http://www.example.com 5.4. Separation of Fields The pipe character '|' must be used to separate the different sections, this character must not be used as part of the information contained within any section. URIs must use hex encoding if the pipe character is needed. The following is an example of a valid OpenPGP user id for the purpose of a DNS name server host name; dns:example.com|dns:*.example.com|c:ccTLD|st:No State|l:No Place|\ o:Example Company|ou:Server Administration|uri:http://example.com Groth, D. Expires 11 January 2009 [Page 8] Internet-Draft DNS Encryption July 2008 5.5. Name Servers with Multiple Host Names A single name server may be authoritative for multiple host names and/or IPs, the 'dns' prefix is the only prefix allowed to exist multiple times on the same user id. If the organisation information is different you could use multiple user ids, one per entity, or multiple OpenPGP keys. The information contained in one user id MUST NOT be mixed or used with host name(s) on other user ids of the same OpenPGP key. Alternatively multiple OpenPGP keys could be used to facilitate this. 5.6. Multiple Host Name Example The following is an example of a valid OpenPGP key with multiple user ids for the purpose of a DNS name server host name; dns:example.com|dns:*.example.com|c:ccTLD|st:No State|l:No Place|\ o:Example Company|ou:Server Administration|uri:http://example.com dns:example.net|dns:*.example.net|c:ccTLD|st:No State|l:No Place|\ o:Example Company|ou:Server Administration|uri:http://example.net 6. Storing OpenPGP keys in DNS 6.1. Storing Stripped Public Keys The usual method of storing OpenPGP keys in DNS is to strip all meta information except for the user id(s) and transmit in binary format. Dig and other utilities output this information in base64 encoding. 6.2. Retrieving Meta Information To be able to calculate confidence scores the full host keys will need to be retrieved from PGP key servers, this can be a timely process and will need to be periodically re-run to ensure signatures are still valid. 7. DNS Packet Structure 7.1. Unencrypted DNS Packet Structure 0 1 2 3 4 5 6 7 8 9 A B C D E F +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| OpCode | 0x0 | Encrypted Data | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID The first 2 bytes must be random but distinct from the real query ID inside the encrypted packet, this is to minimise Groth, D. Expires 11 January 2009 [Page 9] Internet-Draft DNS Encryption July 2008 the risk of spoofed error replies. QR A one bit field for backward compatibility, it must always be 0x0 for questions and 0x1 for replies. OPCODE A new OpCode needs to be allocated by IANA for this purpose to be compatible with existing DNS infrastructure. DATA RFC 3766 indicates that 2048 bit RSA and 128 bit AES should be secure until 2016, at which point 4096 bit RSA and 256 bit AES MUST BE used however these key sizes may be prior to this date as well. 7.2. Encrypted DNS Packet Structure When decoding the encrypted packet the first 4 bytes of the DNS request should be discarded, the rest of the DNS request should be encrypted using the public key of the DNS server. Once the packet has been decrypted, the next 32 bytes is the AES key and possibly null padding if the AES key is less than 256 bit. The AES key can be 16, 24 or 32 bytes in length depending if it is a 128, 192 or 256 bit key being sent. The client is expecting the reply to be returned encrypted with this AES key. The packet contains the DNS request from the 33rd byte which can then be processed in the same manner as any other DNS request except that the reply must be encrypted using the AES key. If the AES key is not 256 bit or 32 bytes there must be null padding used to ensure that no part of the DNS request is found in the first 32 bytes of the DNS request. 8. Advertising Encryption Capability With Additional Records 8.1. Fingerprints in TXT Records The use of TXT records to associate fingerprints with host names will make it easier to use OpenPGP on subsequent connections as it can simply be loaded from the local key ring. These fingerprints should be returned by authoritative name servers and as glue records from registries and registrars. 8.2. Structure of TXT Records Unfortunately PKA was designed in a very email centric manner so it isn't possible to use PKA format directly, however using TXT records which follow a similar formating to PKA is possible but with a few minor differences. Usually _pka is placed in the hostname replacing the at symbol, with host names this distinction isn't needed, and the hostnames instead can be prefixed with _fingerprint instead to avoid confusion of this record type and PKA information. Groth, D. Expires 11 January 2009 [Page 10] Internet-Draft DNS Encryption July 2008 As with PKA, semi-colons are used to separate the three fields. The fields are; v= for the revision number, t= for the type, which can be OpenPGP or PKI, f= for the full 40 byte hexadecimal fingerprint of the public key. 8.3. TXT Record Example _fingerprint.example.com. IN TXT \ "v=1;t=OpenPGP;f=0123456789ABCDEF0123456789ABCDEF01234567" 8.4. Glue Records If registries and registrars allowed fingerprint glue records in their respective zones and returned these with any IP glue records, this would minimise the number of packets required to facilitate encryption. Each glue record must be per name server host name, not per zone to minimise the disruption caused when IPs for hostnames change. 8.5. Additional Records TXT fingerprint records must be returned as additional records when a client makes a NS request on the zone that shares the same domain as any name server host name(s). Additionally the same records must be returned for any matching TXT requests. 9. Security Considerations 9.1. DNS is inherently insecure DNS encryption does not introduce any new security issues beyond any already present in DNS, DNS is inherently insecure, and this draft attempts to solve some of the attacks that can occur with DNS. As DNS is further extended beyond its original uses, it has become more imperative to protect the confidentiality of both the query and the response, however at the cost of efficiency there is a trade off towards information leakage. In an ideal world if the server responds that the request was corrupt or unable to decrypt the request should be sent to the next name server, once the pool of name servers is exhausted the recursive look-up could fall back to plain text mode to ensure best effort is met. Any software implementing this internet draft must implement the ability to have domains that are exempt from using plain text mode. 9.2. Reducing Information Leaks During a normal DNS look-up the full host name is sent to each name server, and then either a suitable reply is returned, record not Groth, D. Expires 11 January 2009 [Page 11] Internet-Draft DNS Encryption July 2008 found or other error, or a NS to submit a new query to. While this method appears to be the most efficient, when switching between systems that can handle encrypted look-ups and systems that can't this could leak too much information about the information being sought after. DNS clients and resolvers must split the gTLD or ccTLD zone name from the fully qualified host name being requested. The zone information must be used to find relevant NS records and only the relevant name servers that may have the information must receive the full query. 10. IANA Considerations This internet draft requests that IANA delegate a new OpCode so name servers can distinguish encrypted DNS requests, this is critical that it appear at the 3rd byte and must be allocated in the original OpCode space only. This internet draft requests that IANA delegate a new ErrorCode so name servers can respond to plain text requests that they only reply to encrypted DNS requests, this isn't critical and only needs to be in EDNS error space. 11. Conclusions As with other protocols, it is becoming imperative to prevent disclosure of dialogues between the intended client and server in the interest of security and privacy. Even though DNS is a public database, the general public is unaware of how DNS works or that their requests and replies can be intercepted or altered. If a large number of popular name servers were to adopt strong cryptography, many attacks on DNS would be rendered useless. Even though this draft is specifically about securing DNS by using OpenPGP key pairs, there is nothing special about the methods used or the way the structure of the information in OpenPGP keys is implemented that would prevent them from being re-utilised for other purposes. Groth, D. Expires 11 January 2009 [Page 12] Internet-Draft DNS Encryption July 2008 12. Informative References [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", Network Working Group, RFC 3401, October 2002. [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", Network Working Group, RFC 3402, October 2002. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", Network Working Group, RFC 3403, October 2002. [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", Network Working Group, RFC 3404, October 2002. [RFC3761] Faltstrom, P., "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", Network Working Group, RFC 3761, April 2004. [RFC3766] Orman, H., "Determining Strengths For Public Keys Used", VPN Consortium, RFC 3766, April 2004. [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", Network Working Group, RFC 4398, March 2006. [RFC4880] Callas, et. al., "OpenPGP Message Format", Network Working Group, RFC 4880, November 2007. [RFC5280] Cooper, et. al., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Network Working Group, RFC 5280, May 2008. Groth, D. Expires 11 January 2009 [Page 13] Internet-Draft DNS Encryption July 2008 13. Acknowledgements This document was prepared using 2-Word-v2.0.template.dot. Although it seems to mostly work in Open Office its a shame that ODF wasn't specifically supported. This document also used draft-timms-encrypt- naptr-00.txt as inspiration. Big thanks to Philipp Guehring and Ian G. for letting me bounce initial ideas off them, as well other finer points along the way. Suggestions and tips from Paul Vixie, Simon P. Ditner, and many others on mailing lists and forums. Finally a great big thanks to Denise Khoo, without her help none of this would be possible. Funding for the RFC Editor function is currently provided by the Internet Society. Author's Addresses Duane Groth Internet Telephony Users Association Inc. P.O. Box 75 Banksia NSW 2216 Australia Email: support@e164.org Groth, D. Expires 11 January 2009 [Page 14] Internet-Draft DNS Encryption July 2008 Intellectual Property Statements 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, 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. Copyright Statement Copyright (C) The IETF Trust (2008). 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. Groth, D. Expires 11 January 2009 [Page 15]