idnits 2.17.1 draft-ietf-smime-bfibecms-07.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 639. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (September 2007) is 6061 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) ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 2822 (ref. 'TEXTMSG') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) == Outdated reference: A later version (-07) exists of draft-martin-ibcs-06 == Outdated reference: A later version (-09) exists of draft-ietf-smime-ibearch-04 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L. Martin 3 S/MIME Working Group Voltage Security 4 Internet Draft Mark Schertler 5 Expires: March 2008 Tumbleweed Communications 6 September 2007 8 Using the Boneh-Franklin and Boneh-Boyen identity-based 9 encryption algorithms with the Cryptographic Message Syntax 10 (CMS) 12 14 Status of this Document 16 By submitting this Internet-Draft, each author represents 17 that any applicable patent or other IPR claims of which he 18 or she is aware have been or will be disclosed, and any of 19 which he or she becomes aware will be disclosed, in 20 accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or obsoleted by 29 other documents at any time. It is inappropriate to use 30 Internet-Drafts as reference material or to cite them other 31 than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be 37 accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 This document describes the conventions for using the Boneh- 43 Franklin (BF) and Boneh-Boyen (BB1) identity-based 44 encryption algorithms in the Cryptographic Message Syntax 45 (CMS) to encrypt content-encryption keys. Object identifiers 46 and the convention for encoding a recipient's identity are 47 also defined. 49 Table of Contents 51 1. Introduction............................................2 52 1.1. Terminology........................................3 53 1.2. IBE overview.......................................3 54 2. Using identity-based encryption.........................3 55 3. Key encryption algorithm identifiers....................7 56 4. Processing by the sender................................7 57 5. Processing by the receiver..............................8 58 6. ASN.1 module............................................9 59 7. Security considerations................................10 60 7.1. Attacks that are outside the scope of this document10 61 7.2. Attacks that are within the scope of this document11 62 7.3. Attacks to which the protocols defined in this 63 document are susceptible...............................11 64 8. IANA considerations....................................12 65 9. References.............................................13 66 9.1. Normative references..............................13 67 9.2. Informative references............................13 68 Authors' Addresses........................................14 69 Intellectual property statement...........................14 70 Disclaimer of validity....................................15 71 Copyright statement.......................................15 72 Acknowledgment............................................15 74 1. Introduction 76 This document defines the way to use the Boneh-Franklin 77 [IBCS] and Boneh-Boyen [IBCS] identity-based encryption 78 (IBE) public-key algorithms in the Cryptographic Message 79 Syntax (CMS) [CMS]. IBE is a public key technology for 80 encrypting content-encryption keys (CEKs) that can be 81 implemented within the framework of the CMS: the recipient's 82 identity is incorporated into the EnvelopedData CMS content 83 type using the OtherRecipientInfo CHOICE in the 84 RecipientInfo field as defined in section 6.2.5 of [CMS]. 85 This document does not describe the implementation of the BF 86 and BB1 algorithms, which are described in detail in [IBCS]. 88 IBE algorithms are a type of public-key cryptographic 89 algorithm in which the public key is calculated directly 90 from a user's identity instead of being generated randomly. 91 This requires a different set of steps for encryption and 92 decryption than would be used with other public-key 93 algorithms, and these steps are defined in Sections 4 and 5 94 of this document respectively. 96 This document also defines the object identifiers and syntax 97 of the object that is used to define the identity of a 98 message recipient. 100 CMS values and identity objects are defined using ASN.1 101 [ASN1]. 103 1.1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 106 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 107 and "OPTIONAL" in this document are to be interpreted as 108 described in RFC-2119 [KEYWORDS]. 110 1.2. IBE overview 112 In addition to the client components that are described in 113 this document, the following additional components are 114 required for a complete IBE messaging system: 116 o A Private-key Generator (PKG). The PKG contains the 117 cryptographic material, known as a master secret, 118 for generating an individual's IBE private key. A 119 PKG accepts an IBE user's private key request and, 120 after successfully authenticating them in some way, 121 returns their IBE private key. 123 o A Public Parameter Server (PPS). IBE System 124 Parameters include publicly sharable cryptographic 125 material, known as IBE public parameters, and 126 policy information for the PKG. A PPS provides a 127 well-known location for secure distribution of IBE 128 public parameters and policy information for the 129 IBE PKG. 131 The interaction of senders and receivers of IBE-encrypted 132 messages are described in [IBE]. 134 2. Using identity-based encryption 136 To use IBE, the ori field in RecipientInfo MUST be used. The 137 fields are set as follows: oriType is set to ibeORIType; 138 oriValue is set to ibeORIValue. 140 These fields have the following meanings: 142 ibeORIType defines the object identifier (OID) that 143 indicates that the subsequent ibeORIValue is the information 144 necessary to decrypt the message using IBE. This field MUST 145 be set to 147 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) 148 country(16) 149 us(840) organization(1) identicrypt(114334) ibcs(1) 150 cms(4) ori-oid(1) } 152 ibeORIValue defines the identity that was used in the IBE 153 algorithm to encrypt the CEK. This is an IBERecipientInfo 154 type. 156 IBERecipientInfo ::= SEQUENCE { 157 cmsVersion INTEGER { v3(3) }, 158 keyFetchMethod OBJECT IDENTIFIER, 159 recipientIdentity IBEIdentityInfo, 160 serverInfo SEQUENCE SIZE (1..MAX) OF 161 OIDValuePairs OPTIONAL, 162 encryptedKey EncryptedKey 163 } 165 The fields of IBERecipientInfo have the following meanings: 167 The cmsVersion MUST be set to 3. 169 The keyFetchMethod is the OID that defines the method of 170 retrieving the private key that the recipient MUST use. How 171 to retrieve an IBE private key using the steps defined in 172 [IBE] is defined by the keyFetchMethod OID. The method for 173 retrieving private keys that is specified in [IBE] is 174 defined by cmsPPSOID. 176 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 177 country(16) 178 us(840) organization(1) identicrypt(114334) pps-schemas(3) 179 ic-schemas(1) pps-uri(1) 180 } 182 The recipientIdentity is the data that was used to calculate 183 the IBE public key that was used to encrypt the content- 184 encryption key. This MUST be an IBEIdentityInfo type. This 185 recipientIdentity is used to calculate IBE public and 186 private keys as described in [IBCS]. 188 IBEIdentityInfo ::= SEQUENCE { 189 district IA5String, 190 serial INTEGER, 191 identitySchema OBJECT IDENTIFIER, 192 identityData OCTET STRING 193 } 195 The fields of IBEIdentityInfo have the following meanings. 197 The district and serial are unique identifiers that are used 198 to construct the URI for the location of the necessary IBE 199 public parameters. The construction and use of this URI is 200 defined in [IBE]. 202 The identitySchema defines the format that is used to encode 203 the information that defines the identity of the recipient. 204 This MUST be set to cmsIdentityOID to indicate that 205 identityData contains an EmailIdentitySchema type. 207 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 208 country(16) 209 us(840) organization(1) identicrypt(114334) keyschemas(2) 210 icschemas(1) rfc822email(1) 211 } 213 The identityData field contains the identify information for 214 the recipient. If the contents of the field is an ASN.1 215 structure, the structure MUST be DER encoded [DER] before 216 placing it in the OCTET STRING. 218 EmailIdentitySchema ::= SEQUENCE { 219 rfc822email IA5String, 220 time GeneralizedTime 221 } 223 The rfc822email is the e-mail address of the recipient in 224 the format defined by [TEXTMSG]. E-mail addresses that 225 contain non-ASCII characters MUST be encoded using punycode 226 [PUNYCODE]. 228 The value of "time" is the UTC time after which the sender 229 wants to let the recipient decrypt the message, so it may be 230 called the "not-before" time. This is usually set to the 231 time when the message is encrypted, but MAY be set to a 232 future time. UTC time values are expressed to the nearest 233 second. 235 The sender of an IBE-encrypted message may want to express 236 this time rounded to a time interval to create a key 237 lifetime. A key lifetime reduces the number of IBE private 238 keys that a recipient needs to retrieve, but still forces 239 the IBE user to periodically re-authenticate. Based on the 240 time interval chosen a recipient would only have to retrieve 241 a new IBE key once during the interval. To do this, follow 242 the following steps. Let "time-interval" be the number of 243 seconds in this larger time interval. 245 1. Find the GeneralizedTime for the not-before value. 246 2. Convert this GeneralizedTime into the number of 247 seconds 248 since January 1, 1970. Call this "total-time." 249 3. Calculate reduced-time = (floor (total-time / 250 time-interval)) * time-interval. 251 4. Convert reduced-time to a GeneralizedTime to get the 252 not-before "time" value. 254 An example of this algorithm for computing a one week time 255 interval is as follows. 257 1. Say the GeneralizedTime is 20020401000000Z. 258 2. Then the total-time is 1017612000. 259 3. A time-interval of 1 week is 604800 seconds. 260 So the reduced-time = (floor(1017612000/604800))* 261 604800 = 1017273600. 262 4. This gives the reduced-time GeneralizedTime form of 263 the 264 reduced-time of 20020328000000Z. 266 When issuing IBE private keys, a PKG SHOULD NOT issue them 267 too far into the future. This restriction is to prevent an 268 adversary who obtains an IBE user's authentication 269 credentials from requesting private keys far into the future 270 and therefore negating the periodic IBE user re- 271 authentication that key lifetime provides. For example if a 272 one week period is chosen for the key lifetime, then IBE 273 private keys should not be issued more than 1 week in 274 advance. Otherwise once an adversary gains access to the PKG 275 via the stolen IBE user credentials they can request all 276 future keys and negate the IBE user authentication 277 restraints in place. 279 The serverInfo is an optional series of OID-value pairs that 280 can be used to convey any other information that might be 281 used by a PKG. Examples of such information could include 282 the user interface that the recipient will experience. 283 Differences in the user interface could include localization 284 information or commercial branding information. 286 The encryptedKey is the result of encrypting the CEK with an 287 IBE algorithm using recipientIdentity as the IBE public key. 289 3. Key encryption algorithm identifiers 291 The BF and BB1 algorithms as defined in [IBCS] have the 292 following object identifiers. These object identifiers are 293 also defined in the ASN.1 module in [IBCS]. 295 bf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 296 us(840) 297 organization(1) identicrypt(114334) ibcs(1) ibcs1(1) 298 ibe-algorithms(2) bf(1) } 300 This is the object identifier that MUST be inserted in the 301 keyEncryptionAlgorithm field in the CMS when the BF 302 algorithm is used to encrypt the CEK. 304 bb1 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 305 us(840) 306 organization(1) identicrypt(114334) ibcs(1) ibcs1(1) 307 ibe-algorithms(2) bb1(2) } 309 This is the object identifier that MUST be inserted in the 310 keyEncryptionAlgorithm field in the CMS when the BB1 311 algorithm is used to encrypt the CEK. 313 4. Processing by the sender 315 The sender of a message that uses IBE to encrypt content- 316 encryption keys performs the following steps: 318 1. Selects a set of IBE public parameters to use in the 319 subsequent steps in accordance with his local security 320 policy. He then determines the URI where the public 321 parameters can be obtained using the process described in 322 [IBE]. This information MUST be encoded in the 323 IBEIdentityInfo as described in Section 2. 325 2. Sets the fields of an OtherRecipientInfo object to 326 their appropriate values as described in Section 2. 328 3. Calculates an IBE public key as defined in [IBCS] 329 using this IBEIdentityInfo as the identity information. 331 4. This IBE public key is then used to encrypt the 332 content-encryption key (CEK), using the algorithms that are 333 defined in [IBCS]. 335 5. Sets encryptedKey to the IBE-encrypted CEK. 337 6. Within the CMS, keyEncryptionAlgorithm MUST then be 338 set to the appropriate OID for the IBE algorithm that was 339 used (see Section 3). 341 5. Processing by the receiver 343 Upon receiving a message that has a CEK encrypted with IBE, 344 the recipient performs the following steps to decrypt the 345 CEK: 347 1. Determines that the CEK is IBE-encrypted by noting that 348 the oriType of the OtherRecipientInfo type is set to 349 ibeORIType. 351 2. Determines that the recipientIdentity was used as the 352 identity in IBE encryption of the CEK. 354 3. Determines the location of the IBE public parameters 355 and the IBE Private Key Generator as described in 356 [IBE]. 358 4. Obtains the IBE public parameters from the location 359 determined in Step 3 using the process defined in 360 [IBE]. 362 5. Obtains the IBE private key needed to decrypt the 363 encrypted CEK using the process defined in [IBE]. 365 6. Decrypts the CEK using the IBE private key obtained in 366 Step 4 using the algorithms described in [IBCS]. 368 6. ASN.1 module 370 IBECMS-module { joint-iso-itu-t(2) country(16) us(840) 371 organization(1) identicrypt(114334) ibcs(1) cms(4) 372 module(5) version(1) 373 } 375 DEFINITIONS IMPLICIT TAGS ::= BEGIN 377 IBEOtherRecipientInfo ::= SEQUENCE { 378 oriType OBJECT IDENTIFIER, 379 oriValue IBERecipientInfo 380 } 382 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 383 country(16) 384 us(840) organization(1) identicrypt(114334) ibcs(1) 385 cms(4) ori-oid(1) 386 } 388 IBERecipientInfo ::= SEQUENCE { 389 cmsVersion INTEGER { v3(3) }, 390 keyFetchMethod OBJECT IDENTIFIER, 391 recipientIdentity IBEIdentityInfo, 392 serverInfo SEQUENCE SIZE (1..MAX) OF 393 OIDValuePairs OPTIONAL, 394 encryptedKey EncryptedKey 395 } 397 IBEIdentityInfo ::= SEQUENCE { 398 district IA5String, 399 serial INTEGER, 400 identitySchema OBJECT IDENTIFIER, 401 identityData OCTET STRING 402 } 404 OIDValuePairs ::= SEQUENCE { 405 fieldID OBJECT IDENTIFIER, 406 fieldData OCTET STRING 407 } 409 EncryptedKey ::= OCTET STRING 411 EmailIdentitySchema ::= SEQUENCE { 412 rfc822email IA5String, 413 time GeneralizedTime 414 } 415 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 416 country(16) 417 us(840) organization(1) identicrypt(114334) keyschemas(2) 418 icschemas(1) rfc822email(1) 419 } 421 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 422 country(16) 423 us(840) organization(1) identicrypt(114334) pps-schemas(3) 424 ic-schemas(1) pps-uri(1) 425 } 427 END 429 7. Security considerations 431 This document is based on [CMS] and [IBCS], and the relevant 432 security considerations of those documents apply. 434 7.1. Attacks that are outside the scope of this document 436 Attacks on the cryptographic algorithms that are used to 437 implement IBE are outside the scope of this document. Such 438 attacks are detailed in [IBCS], which defines parameters 439 that give 80-bit, 112-bit, 128-bit and 256-bit encryption 440 strength. We assume that capable administrators of an IBE 441 system will select parameters that provide a sufficient 442 resistance to cryptanalytic attacks by adversaries. 444 Attacks that give an adversary the ability to access or 445 change the information on a PPS or PKG, especially the 446 cryptographic material (referred to in this document as the 447 master secret), will defeat the security of an IBE system. 448 In particular, if the cryptographic material is compromised 449 the adversary will have the ability to recreate any user's 450 private key and therefore decrypt all messages protected 451 with the corresponding public key. To address this concern, 452 it is highly RECOMMENDED that best practices for physical 453 and operational security for PPS and PKG servers be followed 454 and that these servers be configured (sometimes known as 455 hardened) in accordance with best current practices [NIST]. 456 An IBE system SHOULD be operated in an environment where 457 illicit access to the PPS and PKG is infeasible for 458 attackers to obtain. 460 Attacks that require administrative or IBE user equivalent 461 access to machines used by either the client or the server 462 components defined in this document are also outside the 463 scope of this document. 465 We also assume that all administrators of a system 466 implementing the protocols that are defined in this document 467 are trustworthy and will not abuse their authority to bypass 468 the security provided by an IBE system. This is of 469 particular importance with an IBE system, for an 470 administrator of a PKG could potentially abuse his authority 471 and configure the PKG to grant him any IBE private key that 472 the PKG is capable of calculating. To minimize the 473 possibility of administrators doing this, a system 474 implementing IBE SHOULD implement n-out-of-m control for 475 critical administrative functions and SHOULD maintain 476 auditable logs of all security-critical events that occur in 477 an operating IBE system. 479 Similarly, we assume that users of an IBE system will behave 480 responsibly, not sharing their authentication credentials 481 with others. Thus attacks that require such assumptions are 482 outside the scope of this document. 484 7.2. Attacks that are within the scope of this document 486 Attacks within the scope of this document are those that 487 allow an adversary to: 489 o passively monitor information transmitted between 490 users of an IBE system and the PPS and PKG 492 o masquerade as a PPS or PKG 494 o perform a DOS attack on a PPS or PKG 496 o easily guess an IBE user's authentication 497 credential 499 7.3. Attacks to which the protocols defined in this document 500 are susceptible 502 All communications between users of an IBE system and the 503 PPS or PKG are protected using TLS [TLS]. The IBE system 504 defined in this document provides no additional security for 505 the communications between IBE users and the PPS or PKG. 506 Therefore the described IBE system is completely dependent 507 on the TLS security mechanisms for authentication of the PKG 508 or PPS server and for confidentiality and integrity of the 509 communications. Should there be a compromise of the TLS 510 security mechanisms, the integrity of all communications 511 between an IBE user and the PPS or PKG will be suspect. 513 The protocols defined in this document do not explicitly 514 defend against an attacker masquerading as a legitimate IBE 515 PPS or PKG. The protocols rely on the server authentication 516 mechanism of TLS [TLS]. In addition to the TLS server 517 authentication mechanism IBE client software can provide 518 protection against this possibility by providing user 519 interface capabilities that allows users to visually 520 determine that a connection to PPS and PKG servers is 521 legitimate. This additional capability can help ensure that 522 users cannot easily be tricked into providing valid 523 authorization credentials to an attacker. 525 The protocols defined in this document are also vulnerable 526 to attacks against an IBE PPS or PKG. Denial of service 527 attacks against either component can result in users unable 528 to encrypt or decrypt using IBE, and users of an IBE system 529 SHOULD take the appropriate countermeasures [DOS, BGPDOS] 530 that their use of IBE requires. 532 The IBE user authentication method used by an IBE PKG SHOULD 533 be of sufficient strength to prevent attackers from easily 534 guessing the IBE user's authentication credentials through 535 trial and error. 537 8. IANA considerations 539 All of the object identifiers used in this document were 540 assigned by the National Institute of Standards and 541 Technology (NIST), so no further action by the IANA is 542 necessary for this document. 544 9. References 546 9.1. Normative references 548 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3852, 549 July 2004. 551 [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering: 552 Defeating Denial of Service Attacks which employ 553 IP Source Address Spoofing," RFC 2827, BCP 38, May 554 2000. 556 [KEYWORDS] S. Brander, "Key Words for Use in RFCs to 557 Indicate Requirement Levels," BCP 14, RFC 2119, 558 March 1997. 560 [PUNYCODE] A. Costello, "Punycode: A Bootstring encoding of 561 Unicode for Internationalized Domain Names in 562 Applications (IDNA)," RFC 3492, March 2003. 564 [TEXTMSG] D. Crocker, "Standard for the format of ARPA 565 internet text messages," RFC 2822, April 2001. 567 [TLS] T. Dierks and E. Rescorla, "The Transport Layer 568 Security (TLS) Protocol Version 1.1," RFC 4346, 569 April 2006. 571 9.2. Informative references 573 [ASN1] CCITT, "Recommendation X.209: Specification of Basic 574 Encoding Rules for Abstract Syntax Notation One 575 (ASN.1)," 1998. 577 [DER] ITU-T Recommendation X.680: Information Technology - 578 Abstract Syntax Notation One, 1997. 580 [IBCS] X. Boyen, L. Martin, "Identity-based Cryptography 581 Standard (IBCS) #1: Supersingular Curve 582 Implementations of the BF and BB1 Cryptosystems," 583 draft-martin-ibcs-06.txt. 585 [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity- 586 based Encryption Architecture," draft-ietf-smime- 587 ibearch-04.txt. 589 [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- 590 Service Attacks," RFC 3882, September 2004. 592 [NIST] M. Souppaya, J. Wack and K. Kent, "Security 593 Configuration Checklist Program for IT Products - 594 Guidance for Checklist Users and Developers," NIST 595 Special Publication SP 800-70, May 2005. 597 Authors' Addresses 599 Luther Martin 600 Voltage Security 601 1070 Arastradero Rd Suite 100 602 Palo Alto CA 94304 604 Phone: +1 650 543 1280 605 Email: martin@voltage.com 607 Mark Schertler 608 Tumbleweed Communications 609 700 Saginaw Dr 610 Redwood City CA 94063 612 Phone: +1 650 216 2039 613 Email: mark.schertler@tumbleweed.com 615 Intellectual property statement 617 The IETF takes no position regarding the validity or scope 618 of any Intellectual Property Rights or other rights that 619 might be claimed to pertain to the implementation or use of 620 the technology described in this document or the extent to 621 which any license under such rights might or might not be 622 available; nor does it represent that it has made any 623 independent effort to identify any such rights. Information 624 on the procedures with respect to rights in RFC documents 625 can be found in BCP 78 and BCP 79. 627 Copies of IPR disclosures made to the IETF Secretariat and 628 any assurances of licenses to be made available, or the 629 result of an attempt made to obtain a general license or 630 permission for the use of such proprietary rights by 631 implementers or users of this specification can be obtained 632 from the IETF on-line IPR repository at 633 http://www.ietf.org/ipr. 635 The IETF invites any interested party to bring to its 636 attention any copyrights, patents or patent applications, or 637 other proprietary rights that may cover technology that may 638 be required to implement this standard. Please address the 639 information to the IETF at ietf-ipr@ietf.org. 641 Disclaimer of validity 643 This document and the information contained herein are 644 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 645 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 646 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 647 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 648 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 649 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 650 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 651 A PARTICULAR PURPOSE. 653 Copyright statement 655 Copyright (C) The IETF Trust (2007). 657 This document is subject to the rights, licenses and 658 restrictions contained in BCP 78, and except as set forth 659 therein, the authors retain all their rights. 661 Acknowledgment 663 Funding for the RFC Editor function is currently provided by 664 the Internet Society.