idnits 2.17.1 draft-mraihi-totp-timebased-00.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 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 588. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 29 characters in excess of 72. ** The abstract seems to contain references ([RFC4226]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 341 has weird spacing: '...eyBytes the ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (March 27, 2008) is 5871 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 382 -- Looks like a reference, but probably isn't: '0' on line 402 ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 4226 Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. M'Raihi 3 Internet-Draft Verisign, Inc. 4 Intended status: Standards Track S. Machani 5 Expires: September 28, 2008 Diversinet Corp. 6 M. Pei 7 Verisign, Inc. 8 J. Rydell 9 Portwise, Inc. 10 March 27, 2008 12 TOTP: Time-based One-time Password Algorithm 13 draft-mraihi-totp-timebased-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 28, 2008. 40 Abstract 42 This document describes an extension of one-time password algorithm 43 HOTP as defined in [RFC4226] to support time based moving factor. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 3 51 3. Algorithm Requirements . . . . . . . . . . . . . . . . . . . . 3 52 4. TOTP Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4.1. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.2. Description . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5.2. Validation and Time-step Size . . . . . . . . . . . . . . 5 58 6. Resynchronization . . . . . . . . . . . . . . . . . . . . . . 6 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 9.1. Normative references . . . . . . . . . . . . . . . . . . . 7 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 Appendix A. TOTP Algorithm: Reference Implementation . . . . . . 8 65 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 12 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Introduction 71 1.1. Scope 73 This document describes an extension of one-time password algorithm 74 HOTP as defined in [RFC4226] to support time based moving factor. 76 1.2. Background 78 As defined in [RFC4226] the HOTP algorithm is based on the HMAC-SHA-1 79 algorithm, as specified in [RFC2104] applied to an increasing counter 80 value representing the message in the HMAC computation. 82 Basically, the output of the HMAC-SHA-1 calculation is truncated to 83 obtain user-friendly values: 85 HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)) 87 where Truncate represents the function that can convert an HMAC-SHA-1 88 value into an HOTP value. 90 TOTP is the time-based variant of this algorithm where a value T 91 derived from a time reference and a time step replaces the counter C 92 in the HOTP computation. 94 2. Notation and 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 [RFC2119] 100 3. Algorithm Requirements 102 This section summarizes the requirements taken into account for 103 designing the TOTP algorithm. 105 R1 - The prover (e.g. token, soft token) and verifier (authentication 106 or validation server) MUST have access to the Unix Time 108 R2 - The prover and verifier MUST either share a same secret or the 109 knowledge of a secret transformation to generate a shared secret 111 R3 - The algorithm MUST use HOTP [RFC4226] as a key building block. 113 R4 - The prover and verifier MUST use the same time step value X. 115 R5 - There MUST be a unique secret (key) for each prover. 117 R6 - The keys SHOULD be randomly generated or derived using a key 118 derivation algorithms. 120 R7 - The keys MAY be stored in a tamper-resistant device and SHOULD 121 be protected against unauthorized access and usage. 123 R8 - The TOTP algorithm SHOULD be used for online application. 125 4. TOTP Algorithm 127 This variant of the HOTP algorithm specifies the calculation of a 128 one-time password value, based on a representation of the counter as 129 a time factor. 131 4.1. Notations 133 - X represents the time step in seconds (default value X = 30 134 seconds) and is a system parameter; 136 - T0 is the Unix time to start counting time steps (default value is 137 0, Unix epoch) and is also a system parameter. 139 4.2. Description 141 Basically, we define TOTP as TOTP = HOTP(K, T) where T is an integer 142 and represents the number of time steps between the initial counter 143 time T0 and the current Unix time (i.e. the number of seconds elapsed 144 since midnight UTC of January 1, 1970). 146 More specifically T = (Current Unix time - T0) / X where: 148 - X represents the time step in seconds (default value X = 30 149 seconds) and is a system parameter; 151 - T0 is the Unix time to start counting time steps (default value is 152 0, Unix epoch) and is also a system parameter. 154 5. Security Considerations 156 5.1. General 158 The security and strength of this algorithm depends on the properties 159 of the underlying building block HOTP, which is a construction based 160 on HMAC [RFC2104] using SHA-1 as the hash function. 162 The conclusion of the security analysis detailed in [RFC4226] is 163 that, for all practical purposes, the outputs of the dynamic 164 truncation on distinct inputs are uniformly and independently 165 distributed strings. 167 The analysis demonstrates that the best possible attack against the 168 HOTP function is the brute force attack. 170 As indicated in the algorithm requirement section, keys SHOULD be 171 chosen at random or using a cryptographically strong pseudo-random 172 generator properly seeded with a random value. 174 We RECOMMEND following the recommendations in [RFC1750] for all 175 pseudo-random and random generations. The pseudo-random numbers used 176 for generating the keys SHOULD successfully pass the randomness test 177 specified in [CN] or a similar well-recognized test. 179 All the communications SHOULD take place over a secure channel e.g. 180 SSL/TLS, IPsec connections. 182 We also RECOMMEND storing the keys securely in the validation system, 183 and more specifically encrypting them using tamper-resistant hardware 184 encryption and exposing them only when required: for example, the key 185 is decrypted when needed to verify an OTP value, and re-encrypted 186 immediately to limit exposure in the RAM for a short period of time. 188 The key store MUST be in a secure area, to avoid as much as possible 189 direct attack on the validation system and secrets database. 190 Particularly, access to the key material should be limited to 191 programs and processes required by the validation system only. 193 5.2. Validation and Time-step Size 195 An OTP generated within the same Time-step will be the same. When an 196 OTP is received at a validation system, it doesn't know a client's 197 exact timestamp when an OTP was generated. The validation system may 198 typically use the timestamp when an OTP is received for OTP 199 comparison. Due to the network latency for an OTP to transmit from a 200 requesting application to a validation system and user's actual input 201 time of an OTP to a receiving system, such timestamp gap between the 202 actual OTP generation time and server's receiving time may be large. 203 The receiving time at the validation system and the actual OTP 204 generation may not fall within the same Time-step window that produce 205 the same OTP. When an OTP is generated at the end of a Time-step 206 window, the receiving time most likely falls into the next Time-step 207 window. A validation system SHOULD typically set a policy for an 208 acceptable OTP transmission delay window for validation. The 209 validation system should compare OTPs not only with the receiving 210 timestamp but also the past timesteps that are within the 211 transmission delay. A larger acceptable delay window would introduce 212 some OTP attack window. We RECOMMEND that at most one time step is 213 allowed as the network delay. 215 The Time-step size has impact on both security and usability. A 216 larger Time-step size means larger validity window for an OTP to be 217 accepted by a validation system. There are the following 218 implications with a larger Time-step size. 220 At first, a larger Time-step size exposes larger window for attack. 221 When an OTP is generated and exposed to a third party before it is 222 consumed, the third party can consume the OTP within the Time-step 223 window. 225 We RECOMMEND default Time-step size for 30 seconds. 227 Secondly, the next different OTP must be generated in the next Time- 228 step window. A user must wait till the clock moves to the next Time- 229 step window from the last submission. The waiting time may not be 230 exactly the length of Time-step depending on when the last OTP was 231 generated. For example, if the last OTP was generated at the half 232 way in a Time-step window, the waiting time for the next OTP is half 233 of length of Time-step. In general, a larger Time-step window means 234 larger waiting time for a user to get the next valid OTP after the 235 last successfully OTP validation. A too large window, for example 10 236 minutes, most probably won't be suitable for typical internet login 237 use cases; a user may not be able to get the next OTP within 10 238 minutes and therefore re-login back to the same site in 10 minutes. 239 The default Time-step size 30 seconds is recommended. 241 6. Resynchronization 243 Because of possible clock drifts between a client and a validation 244 server, we RECOMMEND that the validator be set with a specific limit 245 to the number of time steps a prover can be 'out of synch' before 246 being not validated/rejected. 248 This limit can be set both forward and backwards from the calculated 249 time step on receipt of the OTP value. If the time step is 30 250 seconds as recommended, and the validator is set to only accept 2 251 time step backwards then the maximum elapsed time drift would be 252 around 89 seconds, i.e. 29 seconds in the calculated time step and 60 253 for two backward time steps. 255 This would mean the validator could perform a validation against the 256 current time and then further two validations for each backward step 257 (for a total of 3 validations). Upon successful validation, the 258 validation server can record the detected clock drift for the token 259 in terms of number of Time-step. When a new OTP is received after 260 this step, the validator can validate the OTP with current timestamp 261 adjusted with recorded number of Time-step clock drifts for the 262 token. 264 Also, it is important to note that the longer a prover has not sent 265 an OTP to a validation system, the longer (potentially) the 266 accumulated clock drift between the prover and the verifier. In such 267 cases, the default synchronization may not be proper when the drift 268 exceeds beyond allowed threshold. Additional authentication measures 269 SHOULD be used for the validation system to safely authenticate the 270 prover. 272 7. IANA Considerations 274 A URI should be registered for the OTP algorithm defined in this 275 document. The following URI should be used to refer to this TOTP 276 algorithm: 278 TBD: http://www.ietf.org/rfc/totp 280 8. Acknowledgements 282 TBD 284 9. References 286 9.1. Normative references 288 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 289 Recommendations for Security", RFC 1750, December 1994, 290 . 292 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 293 Hashing for Message Authentication", RFC 2104, 294 February 1997, . 296 [RFC2119] "Key words for use in RFCs to Indicate Requirement 297 Levels", BCP 14, RFC 2119, March 1997, 298 . 300 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 301 O. Ranen, "HOTP: An HMAC-Based One-Time Password 302 Algorithm", RFC 4226, December 2005, 303 . 305 9.2. Informative References 307 [CN] Coron, J. and D. Naccache, "An accurate evaluation of 308 Maurer's universal test", LNCS 1556, February 1999, . 311 Appendix A. TOTP Algorithm: Reference Implementation 313 import java.lang.reflect.UndeclaredThrowableException; 314 import java.security.GeneralSecurityException; 315 import java.text.DateFormat; 316 import java.text.SimpleDateFormat; 317 import java.util.Calendar; 318 import java.util.Date; 319 import javax.crypto.Mac; 320 import javax.crypto.spec.SecretKeySpec; 321 import java.math.BigInteger; 322 import java.util.TimeZone; 324 /** 325 * This an example implementation of the OATH TOTP algorithm. 326 * Visit www.openauthentication.org for more information. 327 * 328 * @author Johan Rydell, PortWise 329 */ 330 public class TOTP { 332 private TOTP() {} 334 /** 335 * This method uses the JCE to provide the crypto 336 * algorithm. 337 * HMAC computes a Hashed Message Authentication Code with the 338 * crypto hash algorithm as a parameter. 339 * 340 * @param crypto the crypto algorithm (HmacSHA1, HmacSHA256, HmacSHA512) 341 * @param keyBytes the bytes to use for the HMAC key 342 * @param text the message or text to be authenticated. 343 */ 344 public static byte[] hmac_sha1(String crypto, byte[] keyBytes, byte[] text) 345 { 346 try { 347 Mac hmac; 348 hmac = Mac.getInstance(crypto); 349 SecretKeySpec macKey = 350 new SecretKeySpec(keyBytes, "RAW"); 351 hmac.init(macKey); 352 return hmac.doFinal(text); 353 } catch (GeneralSecurityException gse) { 354 throw new UndeclaredThrowableException(gse); 355 } 356 } 358 private static final int[] DIGITS_POWER 359 // 0 1 2 3 4 5 6 7 8 360 = {1,10,100,1000,10000,100000,1000000,10000000,100000000 }; 362 /** 363 * This method generates an TOTP value for the given 364 * set of parameters. 365 * 366 * @param key the shared secret, HEX encoded 367 * @param time a value that reflects a time 368 * @param returnDigits number of return digits 369 * 370 * @return A numeric String in base 10 that includes 371 * {@link truncationDigits} digits 372 */ 373 static public String generateTOTP(String key, 374 String time, 375 String returnDigits) 376 { 377 int codeDigits = Integer.decode(returnDigits); 378 String crypto = "HmacSHA1"; 379 String result = null; 380 byte[] bArray; 382 byte[] msg = new byte[8]; 383 // Put the bytes of "time" to the message 384 // Input is the HEX value of "time" 385 if(time.length() > 0){ 386 bArray = new BigInteger(time,16).toByteArray(); 387 if(bArray.length == 9){ 388 // First byte is the "sign" byte 389 for (int i = 0; i < 8 && i < bArray.length ; i++) { 390 msg[i + 8 - bArray.length] = bArray[i+1]; 391 } 392 } 393 else { 394 for (int i = 0; i < 8 && i < bArray.length ; i++) { 395 msg[i + 8 - bArray.length] = bArray[i]; 396 } 397 } 398 } 400 byte[] hash; 401 bArray = new BigInteger(key,16).toByteArray(); 402 if(bArray[0] == 0){ 403 byte[] b = new byte[bArray.length - 1]; 404 for(int i = 0 ; i < b.length; i++) 405 b[i]=bArray[i+1]; 406 hash = hmac_sha1(crypto, b, msg); 407 } 408 else{ 409 // compute hmac hash 410 hash = hmac_sha1(crypto, bArray, msg); 411 } 413 // put selected bytes into result int 414 int offset = hash[hash.length - 1] & 0xf; 416 int binary = 417 ((hash[offset] & 0x7f) << 24) | ((hash[offset + 1] & 0xff) << 16) | 418 ((hash[offset + 2] & 0xff) << 8) | (hash[offset + 3] & 0xff); 420 int otp = binary % DIGITS_POWER[codeDigits]; 422 result = Integer.toString(otp); 423 while (result.length() < codeDigits) { 424 result = "0" + result; 425 } 426 return result; 427 } 429 public static void main(String[] args) { 431 String seed = "3132333435363738393031323334353637383930"; 432 String time = "0"; 434 Date myDate = Calendar.getInstance().getTime(); 435 BigInteger b = new BigInteger("0"); 436 DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); 437 df.setTimeZone(TimeZone.getTimeZone("UTC")); 438 try { 439 System.out.println("+------------+-----------------------+------------------+--------+"); 440 System.out.println("| Unix Time | UTC Time | Value of T | OTP |"); 441 System.out.println("+------------+-----------------------+------------------+--------+"); 442 myDate.setTime(Long.parseLong("1000000000000")); 443 System.out.print("| " + myDate.getTime()/1000 + " | " + df.format(myDate) + " |"); 445 b = new BigInteger("0" + myDate.getTime()); 446 b = b.divide(new BigInteger("30000")); 447 time = b.toString(16).toUpperCase(); 448 while(time.length() < 16) time = "0" + time; 449 System.out.print(" " + time + " | "); 450 System.out.println(generateTOTP(seed, time, "6") + " |"); 452 System.out.println("+------------+-----------------------+------------------+--------+"); 454 myDate.setTime(Long.parseLong("1111111111000")); 455 System.out.print("| " + myDate.getTime()/1000 + " | " + df.format(myDate) + " |"); 457 b = new BigInteger("0" + myDate.getTime()); 458 b = b.divide(new BigInteger("30000")); 459 time = b.toString(16).toUpperCase(); 460 while(time.length() < 16) time = "0" + time; 461 System.out.print(" " + time + " | "); 462 System.out.println(generateTOTP(seed, time, "6") + " |"); 464 System.out.println("+------------+-----------------------+------------------+--------+"); 466 myDate.setTime(Long.parseLong("1234567890000")); 467 System.out.print("| " + myDate.getTime()/1000 + " | " + df.format(myDate) + " |"); 469 b = new BigInteger("0" + myDate.getTime()); 470 b = b.divide(new BigInteger("30000")); 471 time = b.toString(16).toUpperCase(); 472 while(time.length() < 16) time = "0" + time; 473 System.out.print(" " + time + " | "); 474 System.out.println(generateTOTP(seed, time, "6") + " |"); 476 System.out.println("+------------+-----------------------+------------------+--------+"); 478 myDate.setTime(Long.parseLong("2000000000000")); 479 System.out.print("| " + myDate.getTime()/1000 + " | " + df.format(myDate) + " |"); 481 b = new BigInteger("0" + myDate.getTime()); 482 b = b.divide(new BigInteger("30000")); 483 time = b.toString(16).toUpperCase(); 484 while(time.length() < 16) time = "0" + time; 485 System.out.print(" " + time + " | "); 486 System.out.println(generateTOTP(seed, time, "6") + " |"); 488 System.out.println("+------------+-----------------------+------------------+--------+"); 490 }catch (final Exception e){ 491 System.out.println("Error : " + e); 492 } 493 } 494 } 496 Appendix B. Test Vectors 498 This section provides test values that can be used for HOTP time- 499 based variant algorithm interoperability test. 501 The test token shared secret uses the ASCII string value 502 "12345678901234567890". With Time Step X = 30, and Unix epoch as 503 initial value to count time steps where T0 = 0, the HOTP time based 504 algorithm will display the following OTP values for corresponding 505 timestamps. 507 +------------+---------------------+------------------+--------+ 508 | Unix Time | UTC Time | Value of C | OTP | 509 +------------+---------------------+------------------+--------+ 510 | 1111111111 | 2005-03-18T01:58:31 | 00000000023523ED | 050471 | 511 | 1234567890 | 2009-02-13T23:31:30 | 000000000273EF07 | 005924 | 512 | 2000000000 | 2033-05-18T03:33:20 | 0000000003F940AA | 279037 | 513 +------------+---------------------+------------------+--------+ 515 Table 1: OTP Table 517 Authors' Addresses 519 David M'Raihi 520 Verisign, Inc. 521 685 E. Middlefield Road 522 Mountain View, CA 94043 523 USA 525 Email: dmraihi@verisign.com 527 Salah Machani 528 Diversinet Corp. 529 2225 Sheppard Avenue East, Suite 1801 530 Toronto, Ontario M2J 5C2 531 Canada 533 Email: smachani@diversinet.com 534 Mingliang Pei 535 Verisign, Inc. 536 685 E. Middlefield Road 537 Mountain View, CA 94043 538 USA 540 Email: mpei@verisign.com 542 Johan Rydell 543 Portwise, Inc. 544 275 Hawthorne Ave, Suite 119 545 Palo Alto, CA 94301 546 USA 548 Email: johan.rydell@portwise.com 550 Full Copyright Statement 552 Copyright (C) The IETF Trust (2008). 554 This document is subject to the rights, licenses and restrictions 555 contained in BCP 78, and except as set forth therein, the authors 556 retain all their rights. 558 This document and the information contained herein are provided on an 559 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 560 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 561 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 562 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 563 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 564 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 566 Intellectual Property 568 The IETF takes no position regarding the validity or scope of any 569 Intellectual Property Rights or other rights that might be claimed to 570 pertain to the implementation or use of the technology described in 571 this document or the extent to which any license under such rights 572 might or might not be available; nor does it represent that it has 573 made any independent effort to identify any such rights. Information 574 on the procedures with respect to rights in RFC documents can be 575 found in BCP 78 and BCP 79. 577 Copies of IPR disclosures made to the IETF Secretariat and any 578 assurances of licenses to be made available, or the result of an 579 attempt made to obtain a general license or permission for the use of 580 such proprietary rights by implementers or users of this 581 specification can be obtained from the IETF on-line IPR repository at 582 http://www.ietf.org/ipr. 584 The IETF invites any interested party to bring to its attention any 585 copyrights, patents or patent applications, or other proprietary 586 rights that may cover technology that may be required to implement 587 this standard. Please address the information to the IETF at 588 ietf-ipr@ietf.org.