idnits 2.17.1 draft-ietf-opes-smtp-security-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 541. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2006) is 6342 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3914 (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '4') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3852 (ref. '10') (Obsoleted by RFC 5652) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Pluggable Edge Services M. Stecher 3 Internet-Draft Secure Computing 4 Expires: June 18, 2007 December 15, 2006 6 Integrity, privacy and security in OPES for SMTP 7 draft-ietf-opes-smtp-security-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on June 18, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The Open Pluggable Edge Services (OPES) framework is application 41 agnostic. Application specific adaptations extend that framework. 42 Previous work has focussed on HTTP and work for SMTP is in progress. 43 These protocols differ fundamentally in the way data flows and it 44 turns out that existing OPES requirements and IAB considerations for 45 OPES need to be reviewed with regards to how well they fit for SMTP 46 adaptation. This document analysis aspects about the integrity of 47 SMTP and mail message adaptation by OPES systems and privacy and 48 security issues when the OPES framework is adapted to SMTP and lists 49 requirements that must be considered when creating the "SMTP 50 adaptation with OPES" document. 52 Table of Contents 54 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Differences between unidirectional and bidirectional 57 application protocols . . . . . . . . . . . . . . . . . . 4 58 2.2 Non-standardized SMTP adaptations at SMTP gateways . . . . 4 59 2.3 Non-OPES issues of SMTP . . . . . . . . . . . . . . . . . 5 60 2.4 Opportunities of OPES/SMTP to address some issues . . . . 5 61 2.5 Limitations of OPES in regards to fixing SMTP issues . . . 5 62 3. Integrity, privacy and security considerations . . . . . . . . 7 63 3.1 Tracing info in OPES/SMTP . . . . . . . . . . . . . . . . 7 64 3.2 Bypass in OPES/SMTP . . . . . . . . . . . . . . . . . . . 7 65 3.3 Compatibility with Cryptographic Protection Mechanisms . . 8 66 4. Protocol requirements for OPES/SMTP . . . . . . . . . . . . . 10 67 5. IAB Considerations for OPES/SMTP . . . . . . . . . . . . . . . 11 68 5.1 IAB Consideration (2.1) One-Party Consent . . . . . . . . 11 69 5.2 IAB Consideration (2.2) IP-Layer Communications . . . . . 11 70 5.3 IAB Consideration (3.1) Notification . . . . . . . . . . . 11 71 5.4 IAB Consideration (3.2) Notification . . . . . . . . . . . 11 72 5.5 IAB Consideration (3.3) Non-Blocking . . . . . . . . . . . 12 73 5.6 IAB Consideration Application Layer Addresses (4.x) . . . 12 74 5.7 IAB Consideration (5.1) Privacy . . . . . . . . . . . . . 12 75 5.8 IAB Consideration Encryption . . . . . . . . . . . . . . . 13 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 7.1 Normative References . . . . . . . . . . . . . . . . . . . 15 79 7.2 Informative References . . . . . . . . . . . . . . . . . . 15 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 81 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 82 Intellectual Property and Copyright Statements . . . . . . . . 18 84 1. Terminology 86 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [1]. When used with 89 the normative meanings, these keywords will be all uppercase. 90 Occurrences of these words in lowercase comprise normal prose usage, 91 with no normative implications. 93 2. Introduction 95 Because OPES is a protocol that is built over application layer 96 transports, its security may depend on the specifics of the 97 transport. OPES designs are guided by the IAB considerations for 98 OPES document [2], and those considerations are revisited here in the 99 context of the SMTP protocol. 101 2.1 Differences between unidirectional and bidirectional application 102 protocols 104 The IAB listed considerations for Open Pluggable Edge Services (OPES) 105 in [2] and OPES treatment of those considerations has been discussed 106 in [3]. Both documents make use of HTTP as an example for the 107 underlying protocol in OPES flows, and focus on web protocols that 108 have requests and responses in the classic form (client sends a 109 request to a server that replies with a response of the same protocol 110 within a single protocol transaction). 112 RFC 3914 [3] already indicates that other protocols may not fit in 113 this context, for example in section 5.3: "Moreover, some application 114 protocols may not have explicit responses...". 116 When using SMTP there are still client and server applications and 117 requests and responses handled within SMTP, but email messages are 118 sent by the data provider to the recipients (data consumers) without 119 a previous request; on that abstraction layer, email delivery via 120 SMTP is a unidirectional process and different from the previously 121 handled web protocols such as HTTP. For example: Bypass has been 122 defined for OPES so far by allowing the data consumer to request an 123 OPES bypass by adding information to the application protocol 124 request; the OPES system can then react on the bypass request in both 125 the application request and response. For SMTP, the data consumer 126 (email recipient) cannot request in-band that the OPES bypass 127 handling of his/her messages. 129 The IAB considerations need to be revisited and special requirements 130 may be needed for OPES handling of SMTP. 132 2.2 Non-standardized SMTP adaptations at SMTP gateways 134 A large number of email filters are deployed at SMTP gateways today; 135 in fact all usecases listed in "OPES SMTP Use Cases" [6] are already 136 deployed, often in non standardized ways. This opens a number of 137 integrity, privacy and security concerns that are not addressed, and 138 SMTP itself does not provide effective measures to detect and defend 139 against compromised implementations. 141 OPES will most likely not be able to solve these issues completely, 142 but at least might be able to improve the situaton to some extent. 144 2.3 Non-OPES issues of SMTP 146 The SMTP specifications [4] require that NDRs (Non Delivery Reports) 147 be sent to the originator of an undeliverable mail that has been 148 accepted by an SMTP server. But it has become common practice for 149 some sorts of mail (spam, worms) to be silently dropped without 150 sending an NDR, a violation of the MUST statement of SMTP (see 151 section 3.7 of [4]). While the user of a web protocol notices if a 152 resource cannot be fetched, neither the email sender nor email 153 recipient may notice that an email was not delivered. These kind of 154 issues already exist and are not introduced by OPES. 156 2.4 Opportunities of OPES/SMTP to address some issues 158 Adding SMTP adaptations with OPES allows us to define a standardized 159 way for SMTP gateway filtering, to offload filtering services to 160 callout servers and address a number of the integrity, privacy and 161 security issues. OPES offers methods to add OPES tracing information 162 and to request bypass of filtering, and by that can make email 163 gateway filtering a more reliable and standardized function. But 164 OPES won't make email delivery via SMTP a reliable communication. 166 2.5 Limitations of OPES in regards to fixing SMTP issues 168 The biggest concerns when adding OPES services to a network flow are 169 that compromised, misconfigured or faulty OPES systems may change 170 messages in a way that the consumer can no longer read them or that 171 messages are not longer delivered at all. 173 Defining a standard way to mark mails that have been handled by OPES 174 systems is fairly simple and does not require new techniques by SMTP 175 gateways; they already today MUST leave tracing information by adding 176 "Received" headers to mails. Therefore, recipients receiving broken 177 mail have a fair chance of finding the compromised OPES system by 178 using the trace information. There is still no guarantee, as the 179 email have been broken in a way that makes even the tracing 180 information unreadable; but the chance will be even better than with 181 other protocols such as HTTP, because most email clients allow the 182 user to display mail headers, while many browsers have no mechanism 183 to show the HTTP headers that might include tracing info. 185 Email that cannot be delivered because a compromised OPES system 186 prevented the delivery of legitimate mail, MUST result in a an NDR to 187 be sent to the originator of the mail according to the SMTP 188 specifications [4]. OPES should not be forced to fix the issue that 189 NDRs are not reliable over SMTP. 191 3. Integrity, privacy and security considerations 193 3.1 Tracing info in OPES/SMTP 195 Tracing is an important requirement for OPES systems. Tracing 196 information added to mails should follow a similar syntax and 197 structure to that defined for OPES/HTTP in HTTP Adaptation with Open 198 Pluggable Edge Services [5], and with the same guidelines as the SMTP 199 specifications [4] define for the "Received" headers. 201 Trace information is then seen by mail recipients when the mails 202 reach the recipient. Mail that cannot be delivered or that is 203 blocked by the OPES service will either be rejected or cannot be 204 delivered after it has been accepted by an SMTP server. In the 205 latter case SMTP specifications [4] require that a NDR MUST be sent 206 to the originator; OPES requires that if a NDR is sent that the 207 report MUST also contain information about the OPES system so that 208 the sender gets informed. If an email is rejected, an OPES system 209 MUST also include trace data in the SMTP response so that the 210 originator can find out why and where the mail was rejected. 212 3.2 Bypass in OPES/SMTP 214 If a mail message was rejected or could not be delivered (and a NDR 215 was sent), the originator of the message may want to bypass the OPES 216 system that blocked the message. 218 If the recipient of a message receives a mail with OPES trace 219 information, he may want to receive a non-OPES version of the 220 message. Although there is no direct in-band request from the 221 recipient back to the OPES system, the recipient can contact the 222 sender and ask her to send the message again and to add a bypass 223 request for the OPES system. 225 An OPES system MAY also define out-of-band methods to request a 226 bypass, for example a web interface or an email message sent to it 227 that results in the creation of a white list entry for the sender/ 228 recipient pair. Examples for these out-of-band methods are email 229 systems that keep a copy of the original email in a quarantaine queue 230 and only send the recipient a block notification plus either a direct 231 link, or a digest notification with the ability to retrieve the 232 original message from quarantaine. 234 OPES MUST implement methods to request a bypass but there cannot be a 235 guarantee that the bypass request will be approved. The security 236 needs of the receiver or the receiver's network may demand that 237 certain filters must not by bypassed (such as virus scanners for 238 example). In general, the receiver should be able to configure a 239 client centric OPES system, i.e. the receiver should be able to 240 indicate if he/she wants to receive a non-OPES version if it is 241 available. 243 Bypass requests could be added to the mail message or within the SMTP 244 dialog. Bypass request data added to the mail message cannot bypass 245 OPES services that operate on other SMTP dialog commands, which are 246 sent before the mail message has been received (such as RCPT 247 commands). 249 Bypass request data sent at the beginning of a SMTP dialog may not 250 reach the OPES system if intermediate SMTP relays do not support 251 those bypass request commands and don't forward that information. 253 3.3 Compatibility with Cryptographic Protection Mechanisms 255 Cryptography can be used to assure message privacy, to authenticate 256 the originator of messages, and to detect message modification. 257 There are standard methods for achieving some or all these 258 protections for generic messages ([9], [10], [11]), and these can be 259 used to protect SMTP data without changing the SMTP protocol. 261 The content of encrypted mail messages cannot be inspected by OPES 262 systems because only the intended recipient has the information 263 necessary for decryption. The IAB and others have suggested that 264 users might want to share that information with OPES systems, thus 265 permitting decryption by intermediates. For most cryptographic 266 systems that are compatible with email, this would require end users 267 to share their most valuable keys, in essence their "identities", 268 with OPES machines. Some key management systems, particularly those 269 which have centralized administrative control of keys, might have 270 trust models in which such sharing would be sensible and secure. 272 Once having decrypted the message, if the OPES box modifies the 273 content, it would be faced with the task of re-encrypting it in order 274 to maintain some semblance of "end-to-end" privacy. 276 If OPES/SMTP had a way to interact with end users on a per message 277 basis, it might be possible to communicate cryptographic key 278 information from individual messages to end users, have them compute 279 the message encrypting key for particular message, and to send that 280 back to the OPES box. This would perhaps ameliorate the need to 281 share a user's "master" message decrypting key with the OPES box. 282 This kind of communication has not been defined for OPES. 284 Message protection systems generally include some message integrity 285 mechanisms by which recipient can check for message modification that 286 may have occurred after the sender released the message. This 287 protection can be applied to encrypted or plaintext messages and can 288 be accomplished through either symmetric or asymmetric cryptography. 289 In the case of symmetric cryptography, the key sharing problem is 290 exactly similar to the encryption case discussed previously. If the 291 OPES box modified the content, then the message integrity (or 292 authentication) code would have to be re-calculated and included with 293 the modified message. 295 For asymmetric cryptography the situation is more complicated. The 296 message integrity is tied to the sender's public key, and although 297 anyone who can get the sender's public key can also check for message 298 modification, no one but the sender can compute the sender's 299 signature on a modified message. Thus, an OPES system could not 300 modify messages and have them appear to come from the purported 301 sender. The notion of sharing the sender's signing key with the OPES 302 system is unpalatable, because few trust models would be compatible 303 with sharing digital identities across organization boundaries. 304 However, if the OPES system doing the modification were under the 305 control of the sender's local administration, the sharing might be 306 sensible (as discussed for decryption, above). 308 OPES/SMTP systems could present modified content showing the modified 309 regions in a form that permits authentication of the original message 310 and authentication of the OPES modifications (assuming the OPES box 311 had a digital signature identity and key). One method for doing this 312 is outlined in [12], but to our knowledge this method is not in any 313 standard. 315 There are security risks associated with sharing cryptographic keys 316 that must be addressed by implementors. Because this is not a simple 317 task, it is not a requirement for OPES/SMTP. 319 4. Protocol requirements for OPES/SMTP 321 In addition to other documents listing requirements for OPES, the 322 discussion in this document implies specific requirements for 323 designing and implementing SMTP adaptations with OPES: 325 o OPES Systems MUST add tracing headers to mail messages 327 o If an email message that has been accepted by an OPES system 328 cannot be delivered, the non delivery report MUST include trace 329 information of the OPES system. 331 o The OPES/SMTP specifications MUST define a bypass request option 332 that can be included in mail messages. 334 o The OPES/SMTP specifications MUST define a bypass request option 335 as an extension for SMTP dialogs. 337 5. IAB Considerations for OPES/SMTP 339 This section lists the IAB considerations for OPES [2] and summarizes 340 how OPES/SMTP addresses them. 342 5.1 IAB Consideration (2.1) One-Party Consent 344 The IAB recommends that all OPES services be explicitly authorized by 345 one of the application-layer end-hosts (that is, either the data 346 consumer application or the data provider application). For OPES/ 347 SMTP this means consent of either the email message sender or the 348 recipient. 350 The application agnostic architecture of OPES [7] requires that "OPES 351 processors MUST be consented to by either the data consumer or data 352 provider application" (OPES processor is the email gateway for OPES/ 353 SMTP). This cannot prevent the consent-less introduction of OPES 354 processors by incompliant OPES entities. 356 5.2 IAB Consideration (2.2) IP-Layer Communications 358 The IAB recommends that OPES processors must be explicitly addressed 359 at the IP layer by the end user (data consumer application). 361 This requirement has been addressed by the architecture requirements 362 in section 2.1 of [7] and has been further clarified in section 2.2 363 of [3]. 365 5.3 IAB Consideration (3.1) Notification 367 "The overall OPES framework needs to assist content providers in 368 detecting and responding to client-centric actions by OPES 369 intermediaries that are deemed inappropriate by the content provider" 370 [2]. 372 For OPES/SMTP this translates into assistance for the email message 373 sender to detect and respond to recipient-centric actions that are 374 deemed inappropriate by the sender. 376 This has been addressed in Section 3.1 and by the second tracing 377 requirements in Section 4. As discussed in Section 2.3 OPES/SMTP 378 cannot prevent that NDRs are not sent or get blocked before reaching 379 the sender of the original message. 381 5.4 IAB Consideration (3.2) Notification 383 "The overall OPES framework should assist end users in detecting the 384 behavior of OPES intermediaries, potentially allowing them to 385 identify imperfect or compromised intermediaries" [2]. 387 This is addressed in Section 3.1 and by the first tracing requirement 388 in Section 4. It must be noted that some email systems do not make 389 the email headers available to the end user although the headers 390 belong to the payload that is transferred via SMTP. Building an OPES 391 architecture with those email systems should be avoided or requires 392 that the tracing information is made available to the end users in a 393 different way. 395 5.5 IAB Consideration (3.3) Non-Blocking 397 "If there exists a "non-OPES" version of content available from the 398 content provider, the OPES architecture must not prevent users from 399 retrieving this "non-OPES" version from the content provider" [2]. 401 For OPES/SMTP this has been discussed in Section 3.2 and is addressed 402 by the two bypass requirements of Section 4. 404 5.6 IAB Consideration Application Layer Addresses (4.x) 406 While "most application layer addressing revolves around URIs" 407 (section 8 of [2]), SMTP uses email addresses, for which the 408 considerations apply to some degree only. 410 The SMTP use cases document [6] includes a use case for Mail 411 Rerouting and Address Rewriting. Alias and email list address 412 resolution are standard function of an email gateway described in 413 [4]. 415 Translating the reference validity consideration regarding inter- and 416 intra-document reference validity to SMTP, OPES services mapping 417 internal to external email addresses MUST ensure to properly map 418 addresses in all affected email headers. 420 5.7 IAB Consideration (5.1) Privacy 422 This consideration recommends that the overall OPES framework must 423 provide for mechanisms for end users to determine the privacy 424 policies of OPES intermediaries. 426 The application agnostic part for OPES and has been discussed in 427 section 10 of [3]. Email specific trace information that will be 428 added to OPES/SMTP according to the requirements in Section 4 may 429 raise additional privacy issues that MUST be added to the privacy 430 policy description of the OPES system. 432 5.8 IAB Consideration Encryption 434 "If OPES was compatible with end-to-end encryption, this would 435 effectively ensure that OPES boxes would be restricted to ones that 436 are known, trusted, explicitly addressed at the IP layer, and 437 authorized (by the provision of decryption keys) by at least one of 438 the ends" [2]. 440 This has been discussed in Section 3.3. 442 6. Security Considerations 444 The document itself discusses security considerations of OPES/SMTP. 445 General security threats of OPES are described in Security Threats 446 for OPES [8] 448 Section 3.3 (about compatibility with cryptographic protection 449 mechanisms) mentions that an OPES system could eventually deal with 450 cryptographic keys. This raises security issues (such as 451 availability and storage of cryptographic keys) that must be 452 addressed by the implementer. 454 7. References 456 7.1 Normative References 458 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 459 Levels", BCP 14, RFC 2119, March 1997. 461 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 462 Considerations for Open Pluggable Edge Services", RFC 3238, 463 January 2002. 465 [3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) 466 Treatment of IAB Considerations", RFC 3914, October 2004. 468 7.2 Informative References 470 [4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 471 April 2001. 473 [5] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open 474 Pluggable Edge Services (OPES)", RFC 4236, November 2005. 476 [6] Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES) 477 SMTP Use Cases", RFC 4496, May 2006. 479 [7] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An 480 Architecture for Open Pluggable Edge Services (OPES)", 481 RFC 3835, August 2004. 483 [8] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. 484 Orman, "Security Threats and Risks for Open Pluggable Edge 485 Services (OPES)", RFC 3837, August 2004. 487 [9] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME 488 Security with OpenPGP", RFC 3156, August 2001. 490 [10] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, 491 July 2004. 493 [11] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 494 Language) XML-Signature Syntax and Processing", RFC 3275, 495 March 2002. 497 [12] Orman, H., "Data Integrity for Mildly Active Content", 498 Proceedings of the Third Annual International Workshop on 499 Active Middleware Services p.73, August 2001. 501 Author's Address 503 Martin Stecher 504 Secure Computing Corporation 505 Vattmannstr. 3 506 33100 Paderborn 507 Germany 509 Email: martin.stecher@webwasher.com 510 URI: http://www.securecomputing.com/ 512 Appendix A. Acknowledgements 514 Many thanks to everybody who provided input and feedback for this 515 document. Very special thanks to Hilarie Orman for her input and 516 suggestions, especially for the content of Section 3.3 (about 517 compatibility with cryptographic protection mechanisms). 519 Intellectual Property Statement 521 The IETF takes no position regarding the validity or scope of any 522 Intellectual Property Rights or other rights that might be claimed to 523 pertain to the implementation or use of the technology described in 524 this document or the extent to which any license under such rights 525 might or might not be available; nor does it represent that it has 526 made any independent effort to identify any such rights. Information 527 on the procedures with respect to rights in RFC documents can be 528 found in BCP 78 and BCP 79. 530 Copies of IPR disclosures made to the IETF Secretariat and any 531 assurances of licenses to be made available, or the result of an 532 attempt made to obtain a general license or permission for the use of 533 such proprietary rights by implementers or users of this 534 specification can be obtained from the IETF on-line IPR repository at 535 http://www.ietf.org/ipr. 537 The IETF invites any interested party to bring to its attention any 538 copyrights, patents or patent applications, or other proprietary 539 rights that may cover technology that may be required to implement 540 this standard. Please address the information to the IETF at 541 ietf-ipr@ietf.org. 543 Disclaimer of Validity 545 This document and the information contained herein are provided on an 546 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 547 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 548 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 549 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 550 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 551 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 553 Copyright Statement 555 Copyright (C) The Internet Society (2006). This document is subject 556 to the rights, licenses and restrictions contained in BCP 78, and 557 except as set forth therein, the authors retain all their rights. 559 Acknowledgment 561 Funding for the RFC Editor function is currently provided by the 562 Internet Society.