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