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