| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Network Working Group K. Zeilenga, Ed. |
| 8 | Request for Comments: 4616 OpenLDAP Foundation |
| 9 | Updates: 2595 August 2006 |
| 10 | Category: Standards Track |
| 11 | |
| 12 | |
| 13 | The PLAIN Simple Authentication and Security Layer (SASL) Mechanism |
| 14 | |
| 15 | Status of This Memo |
| 16 | |
| 17 | This document specifies an Internet standards track protocol for the |
| 18 | Internet community, and requests discussion and suggestions for |
| 19 | improvements. Please refer to the current edition of the "Internet |
| 20 | Official Protocol Standards" (STD 1) for the standardization state |
| 21 | and status of this protocol. Distribution of this memo is unlimited. |
| 22 | |
| 23 | Copyright Notice |
| 24 | |
| 25 | Copyright (C) The Internet Society (2006). |
| 26 | |
| 27 | Abstract |
| 28 | |
| 29 | This document defines a simple clear-text user/password Simple |
| 30 | Authentication and Security Layer (SASL) mechanism called the PLAIN |
| 31 | mechanism. The PLAIN mechanism is intended to be used, in |
| 32 | combination with data confidentiality services provided by a lower |
| 33 | layer, in protocols that lack a simple password authentication |
| 34 | command. |
| 35 | |
| 36 | |
| 37 | |
| 38 | |
| 39 | |
| 40 | |
| 41 | |
| 42 | |
| 43 | |
| 44 | |
| 45 | |
| 46 | |
| 47 | |
| 48 | |
| 49 | |
| 50 | |
| 51 | |
| 52 | |
| 53 | |
| 54 | |
| 55 | |
| 56 | |
| 57 | |
| 58 | Zeilenga Standards Track [Page 1] |
| 59 | |
| 60 | RFC 4616 The PLAIN SASL Mechanism August 2006 |
| 61 | |
| 62 | |
| 63 | 1. Introduction |
| 64 | |
| 65 | Clear-text, multiple-use passwords are simple, interoperate with |
| 66 | almost all existing operating system authentication databases, and |
| 67 | are useful for a smooth transition to a more secure password-based |
| 68 | authentication mechanism. The drawback is that they are unacceptable |
| 69 | for use over network connections where data confidentiality is not |
| 70 | ensured. |
| 71 | |
| 72 | This document defines the PLAIN Simple Authentication and Security |
| 73 | Layer ([SASL]) mechanism for use in protocols with no clear-text |
| 74 | login command (e.g., [ACAP] or [SMTP-AUTH]). This document updates |
| 75 | RFC 2595, replacing Section 6. Changes since RFC 2595 are detailed |
| 76 | in Appendix A. |
| 77 | |
| 78 | The name associated with this mechanism is "PLAIN". |
| 79 | |
| 80 | The PLAIN SASL mechanism does not provide a security layer. |
| 81 | |
| 82 | The PLAIN mechanism should not be used without adequate data security |
| 83 | protection as this mechanism affords no integrity or confidentiality |
| 84 | protections itself. The mechanism is intended to be used with data |
| 85 | security protections provided by application-layer protocol, |
| 86 | generally through its use of Transport Layer Security ([TLS]) |
| 87 | services. |
| 88 | |
| 89 | By default, implementations SHOULD advertise and make use of the |
| 90 | PLAIN mechanism only when adequate data security services are in |
| 91 | place. Specifications for IETF protocols that indicate that this |
| 92 | mechanism is an applicable authentication mechanism MUST mandate that |
| 93 | implementations support an strong data security service, such as TLS. |
| 94 | |
| 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 [Keywords]. |
| 98 | |
| 99 | 2. PLAIN SASL Mechanism |
| 100 | |
| 101 | The mechanism consists of a single message, a string of [UTF-8] |
| 102 | encoded [Unicode] characters, from the client to the server. The |
| 103 | client presents the authorization identity (identity to act as), |
| 104 | followed by a NUL (U+0000) character, followed by the authentication |
| 105 | identity (identity whose password will be used), followed by a NUL |
| 106 | (U+0000) character, followed by the clear-text password. As with |
| 107 | other SASL mechanisms, the client does not provide an authorization |
| 108 | identity when it wishes the server to derive an identity from the |
| 109 | credentials and use that as the authorization identity. |
| 110 | |
| 111 | |
| 112 | |
| 113 | |
| 114 | Zeilenga Standards Track [Page 2] |
| 115 | |
| 116 | RFC 4616 The PLAIN SASL Mechanism August 2006 |
| 117 | |
| 118 | |
| 119 | The formal grammar for the client message using Augmented BNF [ABNF] |
| 120 | follows. |
| 121 | |
| 122 | message = [authzid] UTF8NUL authcid UTF8NUL passwd |
| 123 | authcid = 1*SAFE ; MUST accept up to 255 octets |
| 124 | authzid = 1*SAFE ; MUST accept up to 255 octets |
| 125 | passwd = 1*SAFE ; MUST accept up to 255 octets |
| 126 | UTF8NUL = %x00 ; UTF-8 encoded NUL character |
| 127 | |
| 128 | SAFE = UTF1 / UTF2 / UTF3 / UTF4 |
| 129 | ;; any UTF-8 encoded Unicode character except NUL |
| 130 | |
| 131 | UTF1 = %x01-7F ;; except NUL |
| 132 | UTF2 = %xC2-DF UTF0 |
| 133 | UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / |
| 134 | %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) |
| 135 | UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / |
| 136 | %xF4 %x80-8F 2(UTF0) |
| 137 | UTF0 = %x80-BF |
| 138 | |
| 139 | The authorization identity (authzid), authentication identity |
| 140 | (authcid), password (passwd), and NUL character deliminators SHALL be |
| 141 | transferred as [UTF-8] encoded strings of [Unicode] characters. As |
| 142 | the NUL (U+0000) character is used as a deliminator, the NUL (U+0000) |
| 143 | character MUST NOT appear in authzid, authcid, or passwd productions. |
| 144 | |
| 145 | The form of the authzid production is specific to the application- |
| 146 | level protocol's SASL profile [SASL]. The authcid and passwd |
| 147 | productions are form-free. Use of non-visible characters or |
| 148 | characters that a user may be unable to enter on some keyboards is |
| 149 | discouraged. |
| 150 | |
| 151 | Servers MUST be capable of accepting authzid, authcid, and passwd |
| 152 | productions up to and including 255 octets. It is noted that the |
| 153 | UTF-8 encoding of a Unicode character may be as long as 4 octets. |
| 154 | |
| 155 | Upon receipt of the message, the server will verify the presented (in |
| 156 | the message) authentication identity (authcid) and password (passwd) |
| 157 | with the system authentication database, and it will verify that the |
| 158 | authentication credentials permit the client to act as the (presented |
| 159 | or derived) authorization identity (authzid). If both steps succeed, |
| 160 | the user is authenticated. |
| 161 | |
| 162 | The presented authentication identity and password strings, as well |
| 163 | as the database authentication identity and password strings, are to |
| 164 | be prepared before being used in the verification process. The |
| 165 | [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED |
| 166 | preparation algorithm. The SASLprep preparation algorithm is |
| 167 | |
| 168 | |
| 169 | |
| 170 | Zeilenga Standards Track [Page 3] |
| 171 | |
| 172 | RFC 4616 The PLAIN SASL Mechanism August 2006 |
| 173 | |
| 174 | |
| 175 | recommended to improve the likelihood that comparisons behave in an |
| 176 | expected manner. The SASLprep preparation algorithm is not mandatory |
| 177 | so as to allow the server to employ other preparation algorithms |
| 178 | (including none) when appropriate. For instance, use of a different |
| 179 | preparation algorithm may be necessary for the server to interoperate |
| 180 | with an external system. |
| 181 | |
| 182 | When preparing the presented strings using [SASLPrep], the presented |
| 183 | strings are to be treated as "query" strings (Section 7 of |
| 184 | [StringPrep]) and hence unassigned code points are allowed to appear |
| 185 | in their prepared output. When preparing the database strings using |
| 186 | [SASLPrep], the database strings are to be treated as "stored" |
| 187 | strings (Section 7 of [StringPrep]) and hence unassigned code points |
| 188 | are prohibited from appearing in their prepared output. |
| 189 | |
| 190 | Regardless of the preparation algorithm used, if the output of a |
| 191 | non-invertible function (e.g., hash) of the expected string is |
| 192 | stored, the string MUST be prepared before input to that function. |
| 193 | |
| 194 | Regardless of the preparation algorithm used, if preparation fails or |
| 195 | results in an empty string, verification SHALL fail. |
| 196 | |
| 197 | When no authorization identity is provided, the server derives an |
| 198 | authorization identity from the prepared representation of the |
| 199 | provided authentication identity string. This ensures that the |
| 200 | derivation of different representations of the authentication |
| 201 | identity produces the same authorization identity. |
| 202 | |
| 203 | The server MAY use the credentials to initialize any new |
| 204 | authentication database, such as one suitable for [CRAM-MD5] or |
| 205 | [DIGEST-MD5]. |
| 206 | |
| 207 | 3. Pseudo-Code |
| 208 | |
| 209 | This section provides pseudo-code illustrating the verification |
| 210 | process (using hashed passwords and the SASLprep preparation |
| 211 | function) discussed above. This section is not definitive. |
| 212 | |
| 213 | boolean Verify(string authzid, string authcid, string passwd) { |
| 214 | string pAuthcid = SASLprep(authcid, true); # prepare authcid |
| 215 | string pPasswd = SASLprep(passwd, true); # prepare passwd |
| 216 | if (pAuthcid == NULL || pPasswd == NULL) { |
| 217 | return false; # preparation failed |
| 218 | } |
| 219 | if (pAuthcid == "" || pPasswd == "") { |
| 220 | return false; # empty prepared string |
| 221 | } |
| 222 | |
| 223 | |
| 224 | |
| 225 | |
| 226 | Zeilenga Standards Track [Page 4] |
| 227 | |
| 228 | RFC 4616 The PLAIN SASL Mechanism August 2006 |
| 229 | |
| 230 | |
| 231 | storedHash = FetchPasswordHash(pAuthcid); |
| 232 | if (storedHash == NULL || storedHash == "") { |
| 233 | return false; # error or unknown authcid |
| 234 | } |
| 235 | |
| 236 | if (!Compare(storedHash, Hash(pPasswd))) { |
| 237 | return false; # incorrect password |
| 238 | } |
| 239 | |
| 240 | if (authzid == NULL ) { |
| 241 | authzid = DeriveAuthzid(pAuthcid); |
| 242 | if (authzid == NULL || authzid == "") { |
| 243 | return false; # could not derive authzid |
| 244 | } |
| 245 | } |
| 246 | |
| 247 | if (!Authorize(pAuthcid, authzid)) { |
| 248 | return false; # not authorized |
| 249 | } |
| 250 | |
| 251 | return true; |
| 252 | } |
| 253 | |
| 254 | The second parameter of the SASLprep function, when true, indicates |
| 255 | that unassigned code points are allowed in the input. When the |
| 256 | SASLprep function is called to prepare the password prior to |
| 257 | computing the stored hash, the second parameter would be false. |
| 258 | |
| 259 | The second parameter provided to the Authorize function is not |
| 260 | prepared by this code. The application-level SASL profile should be |
| 261 | consulted to determine what, if any, preparation is necessary. |
| 262 | |
| 263 | Note that the DeriveAuthzid and Authorize functions (whether |
| 264 | implemented as one function or two, whether designed in a manner in |
| 265 | which these functions or whether the mechanism implementation can be |
| 266 | reused elsewhere) require knowledge and understanding of mechanism |
| 267 | and the application-level protocol specification and/or |
| 268 | implementation details to implement. |
| 269 | |
| 270 | Note that the Authorize function outcome is clearly dependent on |
| 271 | details of the local authorization model and policy. Both functions |
| 272 | may be dependent on other factors as well. |
| 273 | |
| 274 | |
| 275 | |
| 276 | |
| 277 | |
| 278 | |
| 279 | |
| 280 | |
| 281 | |
| 282 | Zeilenga Standards Track [Page 5] |
| 283 | |
| 284 | RFC 4616 The PLAIN SASL Mechanism August 2006 |
| 285 | |
| 286 | |
| 287 | 4. Examples |
| 288 | |
| 289 | This section provides examples of PLAIN authentication exchanges. |
| 290 | The examples are intended to help the readers understand the above |
| 291 | text. The examples are not definitive. |
| 292 | |
| 293 | "C:" and "S:" indicate lines sent by the client and server, |
| 294 | respectively. "<NUL>" represents a single NUL (U+0000) character. |
| 295 | The Application Configuration Access Protocol ([ACAP]) is used in the |
| 296 | examples. |
| 297 | |
| 298 | The first example shows how the PLAIN mechanism might be used for |
| 299 | user authentication. |
| 300 | |
| 301 | S: * ACAP (SASL "CRAM-MD5") (STARTTLS) |
| 302 | C: a001 STARTTLS |
| 303 | S: a001 OK "Begin TLS negotiation now" |
| 304 | <TLS negotiation, further commands are under TLS layer> |
| 305 | S: * ACAP (SASL "CRAM-MD5" "PLAIN") |
| 306 | C: a002 AUTHENTICATE "PLAIN" |
| 307 | S: + "" |
| 308 | C: {21} |
| 309 | C: <NUL>tim<NUL>tanstaaftanstaaf |
| 310 | S: a002 OK "Authenticated" |
| 311 | |
| 312 | The second example shows how the PLAIN mechanism might be used to |
| 313 | attempt to assume the identity of another user. In this example, the |
| 314 | server rejects the request. Also, this example makes use of the |
| 315 | protocol optional initial response capability to eliminate a round- |
| 316 | trip. |
| 317 | |
| 318 | S: * ACAP (SASL "CRAM-MD5") (STARTTLS) |
| 319 | C: a001 STARTTLS |
| 320 | S: a001 OK "Begin TLS negotiation now" |
| 321 | <TLS negotiation, further commands are under TLS layer> |
| 322 | S: * ACAP (SASL "CRAM-MD5" "PLAIN") |
| 323 | C: a002 AUTHENTICATE "PLAIN" {20+} |
| 324 | C: Ursel<NUL>Kurt<NUL>xipj3plmq |
| 325 | S: a002 NO "Not authorized to requested authorization identity" |
| 326 | |
| 327 | 5. Security Considerations |
| 328 | |
| 329 | As the PLAIN mechanism itself provided no integrity or |
| 330 | confidentiality protections, it should not be used without adequate |
| 331 | external data security protection, such as TLS services provided by |
| 332 | many application-layer protocols. By default, implementations SHOULD |
| 333 | NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless |
| 334 | adequate data security services are in place. |
| 335 | |
| 336 | |
| 337 | |
| 338 | Zeilenga Standards Track [Page 6] |
| 339 | |
| 340 | RFC 4616 The PLAIN SASL Mechanism August 2006 |
| 341 | |
| 342 | |
| 343 | When the PLAIN mechanism is used, the server gains the ability to |
| 344 | impersonate the user to all services with the same password |
| 345 | regardless of any encryption provided by TLS or other confidentiality |
| 346 | protection mechanisms. Whereas many other authentication mechanisms |
| 347 | have similar weaknesses, stronger SASL mechanisms address this issue. |
| 348 | Clients are encouraged to have an operational mode where all |
| 349 | mechanisms that are likely to reveal the user's password to the |
| 350 | server are disabled. |
| 351 | |
| 352 | General [SASL] security considerations apply to this mechanism. |
| 353 | |
| 354 | Unicode, [UTF-8], and [StringPrep] security considerations also |
| 355 | apply. |
| 356 | |
| 357 | 6. IANA Considerations |
| 358 | |
| 359 | The SASL Mechanism registry [IANA-SASL] entry for the PLAIN mechanism |
| 360 | has been updated by the IANA to reflect that this document now |
| 361 | provides its technical specification. |
| 362 | |
| 363 | To: iana@iana.org |
| 364 | Subject: Updated Registration of SASL mechanism PLAIN |
| 365 | |
| 366 | SASL mechanism name: PLAIN |
| 367 | Security considerations: See RFC 4616. |
| 368 | Published specification (optional, recommended): RFC 4616 |
| 369 | Person & email address to contact for further information: |
| 370 | Kurt Zeilenga <kurt@openldap.org> |
| 371 | IETF SASL WG <ietf-sasl@imc.org> |
| 372 | Intended usage: COMMON |
| 373 | Author/Change controller: IESG <iesg@ietf.org> |
| 374 | Note: Updates existing entry for PLAIN |
| 375 | |
| 376 | 7. Acknowledgements |
| 377 | |
| 378 | This document is a revision of RFC 2595 by Chris Newman. Portions of |
| 379 | the grammar defined in Section 2 were borrowed from [UTF-8] by |
| 380 | Francois Yergeau. |
| 381 | |
| 382 | This document is a product of the IETF Simple Authentication and |
| 383 | Security Layer (SASL) Working Group. |
| 384 | |
| 385 | |
| 386 | |
| 387 | |
| 388 | |
| 389 | |
| 390 | |
| 391 | |
| 392 | |
| 393 | |
| 394 | Zeilenga Standards Track [Page 7] |
| 395 | |
| 396 | RFC 4616 The PLAIN SASL Mechanism August 2006 |
| 397 | |
| 398 | |
| 399 | 8. Normative References |
| 400 | |
| 401 | [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
| 402 | Syntax Specifications: ABNF", RFC 4234, October 2005. |
| 403 | |
| 404 | [Keywords] Bradner, S., "Key words for use in RFCs to Indicate |
| 405 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| 406 | |
| 407 | [SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple |
| 408 | Authentication and Security Layer (SASL)", RFC 4422, |
| 409 | June 2006. |
| 410 | |
| 411 | [SASLPrep] Zeilenga, K., "SASLprep: Stringprep Profile for User |
| 412 | Names and Passwords", RFC 4013, February 2005. |
| 413 | |
| 414 | [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of |
| 415 | Internationalized Strings ("stringprep")", RFC 3454, |
| 416 | December 2002. |
| 417 | |
| 418 | [Unicode] The Unicode Consortium, "The Unicode Standard, Version |
| 419 | 3.2.0" is defined by "The Unicode Standard, Version |
| 420 | 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- |
| 421 | 61633-5), as amended by the "Unicode Standard Annex |
| 422 | #27: Unicode 3.1" |
| 423 | (http://www.unicode.org/reports/tr27/) and by the |
| 424 | "Unicode Standard Annex #28: Unicode 3.2" |
| 425 | (http://www.unicode.org/reports/tr28/). |
| 426 | |
| 427 | [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO |
| 428 | 10646", STD 63, RFC 3629, November 2003. |
| 429 | |
| 430 | [TLS] Dierks, T. and E. Rescorla, "The Transport Layer |
| 431 | Security (TLS) Protocol Version 1.1", RFC 4346, April |
| 432 | 2006. |
| 433 | |
| 434 | 9. Informative References |
| 435 | |
| 436 | [ACAP] Newman, C. and J. Myers, "ACAP -- Application |
| 437 | Configuration Access Protocol", RFC 2244, November |
| 438 | 1997. |
| 439 | |
| 440 | [CRAM-MD5] Nerenberg, L., Ed., "The CRAM-MD5 SASL Mechanism", Work |
| 441 | in Progress, June 2006. |
| 442 | |
| 443 | [DIGEST-MD5] Melnikov, A., Ed., "Using Digest Authentication as a |
| 444 | SASL Mechanism", Work in Progress, June 2006. |
| 445 | |
| 446 | |
| 447 | |
| 448 | |
| 449 | |
| 450 | Zeilenga Standards Track [Page 8] |
| 451 | |
| 452 | RFC 4616 The PLAIN SASL Mechanism August 2006 |
| 453 | |
| 454 | |
| 455 | [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) |
| 456 | MECHANISMS", |
| 457 | <http://www.iana.org/assignments/sasl-mechanisms>. |
| 458 | |
| 459 | [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", |
| 460 | RFC 2554, March 1999. |
| 461 | |
| 462 | |
| 463 | |
| 464 | |
| 465 | |
| 466 | |
| 467 | |
| 468 | |
| 469 | |
| 470 | |
| 471 | |
| 472 | |
| 473 | |
| 474 | |
| 475 | |
| 476 | |
| 477 | |
| 478 | |
| 479 | |
| 480 | |
| 481 | |
| 482 | |
| 483 | |
| 484 | |
| 485 | |
| 486 | |
| 487 | |
| 488 | |
| 489 | |
| 490 | |
| 491 | |
| 492 | |
| 493 | |
| 494 | |
| 495 | |
| 496 | |
| 497 | |
| 498 | |
| 499 | |
| 500 | |
| 501 | |
| 502 | |
| 503 | |
| 504 | |
| 505 | |
| 506 | Zeilenga Standards Track [Page 9] |
| 507 | |
| 508 | RFC 4616 The PLAIN SASL Mechanism August 2006 |
| 509 | |
| 510 | |
| 511 | Appendix A. Changes since RFC 2595 |
| 512 | |
| 513 | This appendix is non-normative. |
| 514 | |
| 515 | This document replaces Section 6 of RFC 2595. |
| 516 | |
| 517 | The specification details how the server is to compare client- |
| 518 | provided character strings with stored character strings. |
| 519 | |
| 520 | The ABNF grammar was updated. In particular, the grammar now allows |
| 521 | LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the |
| 522 | authzid, authcid, passwd productions. However, whether these control |
| 523 | characters may be used depends on the string preparation rules |
| 524 | applicable to the production. For passwd and authcid productions, |
| 525 | control characters are prohibited. For authzid, one must consult the |
| 526 | application-level SASL profile. This change allows PLAIN to carry |
| 527 | all possible authorization identity strings allowed in SASL. |
| 528 | |
| 529 | Pseudo-code was added. |
| 530 | |
| 531 | The example section was expanded to illustrate more features of the |
| 532 | PLAIN mechanism. |
| 533 | |
| 534 | Editor's Address |
| 535 | |
| 536 | Kurt D. Zeilenga |
| 537 | OpenLDAP Foundation |
| 538 | |
| 539 | EMail: Kurt@OpenLDAP.org |
| 540 | |
| 541 | |
| 542 | |
| 543 | |
| 544 | |
| 545 | |
| 546 | |
| 547 | |
| 548 | |
| 549 | |
| 550 | |
| 551 | |
| 552 | |
| 553 | |
| 554 | |
| 555 | |
| 556 | |
| 557 | |
| 558 | |
| 559 | |
| 560 | |
| 561 | |
| 562 | Zeilenga Standards Track [Page 10] |
| 563 | |
| 564 | RFC 4616 The PLAIN SASL Mechanism August 2006 |
| 565 | |
| 566 | |
| 567 | Full Copyright Statement |
| 568 | |
| 569 | Copyright (C) The Internet Society (2006). |
| 570 | |
| 571 | This document is subject to the rights, licenses and restrictions |
| 572 | contained in BCP 78, and except as set forth therein, the authors |
| 573 | retain all their rights. |
| 574 | |
| 575 | This document and the information contained herein are provided on an |
| 576 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
| 577 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET |
| 578 | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, |
| 579 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE |
| 580 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED |
| 581 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
| 582 | |
| 583 | Intellectual Property |
| 584 | |
| 585 | The IETF takes no position regarding the validity or scope of any |
| 586 | Intellectual Property Rights or other rights that might be claimed to |
| 587 | pertain to the implementation or use of the technology described in |
| 588 | this document or the extent to which any license under such rights |
| 589 | might or might not be available; nor does it represent that it has |
| 590 | made any independent effort to identify any such rights. Information |
| 591 | on the procedures with respect to rights in RFC documents can be |
| 592 | found in BCP 78 and BCP 79. |
| 593 | |
| 594 | Copies of IPR disclosures made to the IETF Secretariat and any |
| 595 | assurances of licenses to be made available, or the result of an |
| 596 | attempt made to obtain a general license or permission for the use of |
| 597 | such proprietary rights by implementers or users of this |
| 598 | specification can be obtained from the IETF on-line IPR repository at |
| 599 | http://www.ietf.org/ipr. |
| 600 | |
| 601 | The IETF invites any interested party to bring to its attention any |
| 602 | copyrights, patents or patent applications, or other proprietary |
| 603 | rights that may cover technology that may be required to implement |
| 604 | this standard. Please address the information to the IETF at |
| 605 | ietf-ipr@ietf.org. |
| 606 | |
| 607 | Acknowledgement |
| 608 | |
| 609 | Funding for the RFC Editor function is provided by the IETF |
| 610 | Administrative Support Activity (IASA). |
| 611 | |
| 612 | |
| 613 | |
| 614 | |
| 615 | |
| 616 | |
| 617 | |
| 618 | Zeilenga Standards Track [Page 11] |
| 619 | |