| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Network Working Group R. Siemborski, Ed. |
| 8 | Request for Comments: 4954 Google, Inc. |
| 9 | Obsoletes: 2554 A. Melnikov, Ed. |
| 10 | Updates: 3463 Isode Limited |
| 11 | Category: Standards Track July 2007 |
| 12 | |
| 13 | |
| 14 | SMTP Service Extension for Authentication |
| 15 | |
| 16 | Status of This Memo |
| 17 | |
| 18 | This document specifies an Internet standards track protocol for the |
| 19 | Internet community, and requests discussion and suggestions for |
| 20 | improvements. Please refer to the current edition of the "Internet |
| 21 | Official Protocol Standards" (STD 1) for the standardization state |
| 22 | and status of this protocol. Distribution of this memo is unlimited. |
| 23 | |
| 24 | Copyright Notice |
| 25 | |
| 26 | Copyright (C) The IETF Trust (2007). |
| 27 | |
| 28 | Abstract |
| 29 | |
| 30 | This document defines a Simple Mail Transport Protocol (SMTP) |
| 31 | extension whereby an SMTP client may indicate an authentication |
| 32 | mechanism to the server, perform an authentication protocol exchange, |
| 33 | and optionally negotiate a security layer for subsequent protocol |
| 34 | interactions during this session. This extension includes a profile |
| 35 | of the Simple Authentication and Security Layer (SASL) for SMTP. |
| 36 | |
| 37 | This document obsoletes RFC 2554. |
| 38 | |
| 39 | |
| 40 | |
| 41 | |
| 42 | |
| 43 | |
| 44 | |
| 45 | |
| 46 | |
| 47 | |
| 48 | |
| 49 | |
| 50 | |
| 51 | |
| 52 | |
| 53 | |
| 54 | |
| 55 | |
| 56 | |
| 57 | |
| 58 | Siemborski & Melnikov Standards Track [Page 1] |
| 59 | |
| 60 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 61 | |
| 62 | |
| 63 | Table of Contents |
| 64 | |
| 65 | 1. Introduction ....................................................2 |
| 66 | 2. How to Read This Document .......................................2 |
| 67 | 3. The Authentication Service Extension ............................3 |
| 68 | 4. The AUTH Command ................................................3 |
| 69 | 4.1. Examples ...................................................7 |
| 70 | 5. The AUTH Parameter to the MAIL FROM command .....................9 |
| 71 | 5.1. Examples ..................................................10 |
| 72 | 6. Status Codes ...................................................11 |
| 73 | 7. Additional requirements on servers .............................12 |
| 74 | 8. Formal Syntax ..................................................13 |
| 75 | 9. Security Considerations ........................................14 |
| 76 | 10. IANA Considerations ...........................................15 |
| 77 | 11. Normative References ..........................................15 |
| 78 | 12. Informative References ........................................16 |
| 79 | 13. Acknowledgments ...............................................17 |
| 80 | 14. Additional Requirements When Using SASL PLAIN over TLS ........17 |
| 81 | 15. Changes since RFC 2554 ........................................18 |
| 82 | |
| 83 | 1. Introduction |
| 84 | |
| 85 | This document defines a Simple Mail Transport Protocol (SMTP) |
| 86 | extension whereby an SMTP client may indicate an authentication |
| 87 | mechanism to the server, perform an authentication protocol exchange, |
| 88 | optionally negotiate a security layer for subsequent protocol |
| 89 | interactions during this session and, during a mail transaction, |
| 90 | optionally specify a mailbox associated with the identity that |
| 91 | submitted the message to the mail delivery system. |
| 92 | |
| 93 | This extension includes a profile of the Simple Authentication and |
| 94 | Security Layer (SASL) for SMTP. |
| 95 | |
| 96 | When compared to RFC 2554, this document deprecates use of the 538 |
| 97 | response code, adds a new Enhanced Status Code, adds a requirement to |
| 98 | support SASLprep profile for preparing authorization identities, |
| 99 | recommends use of RFC 3848 transmission types in the Received trace |
| 100 | header field, and clarifies interaction with SMTP PIPELINING |
| 101 | [PIPELINING] extension. |
| 102 | |
| 103 | 2. How to Read This Document |
| 104 | |
| 105 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| 106 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| 107 | document are to be interpreted as described in [KEYWORDS]. |
| 108 | |
| 109 | In examples, "C:" and "S:" indicate lines sent by the client and |
| 110 | server, respectively. |
| 111 | |
| 112 | |
| 113 | |
| 114 | Siemborski & Melnikov Standards Track [Page 2] |
| 115 | |
| 116 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 117 | |
| 118 | |
| 119 | 3. The Authentication Service Extension |
| 120 | |
| 121 | 1. The name of this [SMTP] service extension is "Authentication". |
| 122 | |
| 123 | 2. The EHLO keyword value associated with this extension is "AUTH". |
| 124 | |
| 125 | 3. The AUTH EHLO keyword contains as a parameter a space-separated |
| 126 | list of the names of available [SASL] mechanisms. The list of |
| 127 | available mechanisms MAY change after a successful STARTTLS |
| 128 | command [SMTP-TLS]. |
| 129 | |
| 130 | 4. A new [SMTP] verb "AUTH" is defined. |
| 131 | |
| 132 | 5. An optional parameter using the keyword "AUTH" is added to the |
| 133 | MAIL FROM command, and extends the maximum line length of the |
| 134 | MAIL FROM command by 500 characters. |
| 135 | |
| 136 | 6. This extension is appropriate for the submission protocol |
| 137 | [SUBMIT]. |
| 138 | |
| 139 | 4. The AUTH Command |
| 140 | |
| 141 | AUTH mechanism [initial-response] |
| 142 | |
| 143 | Arguments: |
| 144 | mechanism: A string identifying a [SASL] authentication |
| 145 | mechanism. |
| 146 | |
| 147 | initial-response: An optional initial client response. If |
| 148 | present, this response MUST be encoded as described in Section |
| 149 | 4 of [BASE64] or contain a single character "=". |
| 150 | |
| 151 | Restrictions: |
| 152 | After an AUTH command has been successfully completed, no more |
| 153 | AUTH commands may be issued in the same session. After a |
| 154 | successful AUTH command completes, a server MUST reject any |
| 155 | further AUTH commands with a 503 reply. |
| 156 | |
| 157 | The AUTH command is not permitted during a mail transaction. |
| 158 | An AUTH command issued during a mail transaction MUST be |
| 159 | rejected with a 503 reply. |
| 160 | |
| 161 | Discussion: |
| 162 | The AUTH command initiates a [SASL] authentication exchange |
| 163 | between the client and the server. The client identifies the |
| 164 | SASL mechanism to use with the first parameter of the AUTH |
| 165 | command. If the server supports the requested authentication |
| 166 | mechanism, it performs the SASL exchange to authenticate the |
| 167 | |
| 168 | |
| 169 | |
| 170 | Siemborski & Melnikov Standards Track [Page 3] |
| 171 | |
| 172 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 173 | |
| 174 | |
| 175 | user. Optionally, it also negotiates a security layer for |
| 176 | subsequent protocol interactions during this session. If the |
| 177 | requested authentication mechanism is invalid (e.g., is not |
| 178 | supported or requires an encryption layer), the server rejects |
| 179 | the AUTH command with a 504 reply. If the server supports the |
| 180 | [ESMTP-CODES] extension, it SHOULD return a 5.5.4 enhanced |
| 181 | response code. |
| 182 | |
| 183 | The SASL authentication exchange consists of a series of |
| 184 | server challenges and client responses that are specific to |
| 185 | the chosen [SASL] mechanism. |
| 186 | |
| 187 | A server challenge is sent as a 334 reply with the text part |
| 188 | containing the [BASE64] encoded string supplied by the SASL |
| 189 | mechanism. This challenge MUST NOT contain any text other |
| 190 | than the BASE64 encoded challenge. |
| 191 | |
| 192 | A client response consists of a line containing a [BASE64] |
| 193 | encoded string. If the client wishes to cancel the |
| 194 | authentication exchange, it issues a line with a single "*". |
| 195 | If the server receives such a response, it MUST reject the |
| 196 | AUTH command by sending a 501 reply. |
| 197 | |
| 198 | The optional initial response argument to the AUTH command is |
| 199 | used to save a round-trip when using authentication mechanisms |
| 200 | that support an initial client response. If the initial |
| 201 | response argument is omitted and the chosen mechanism requires |
| 202 | an initial client response, the server MUST proceed as defined |
| 203 | in Section 5.1 of [SASL]. In SMTP, a server challenge that |
| 204 | contains no data is defined as a 334 reply with no text part. |
| 205 | Note that there is still a space following the reply code, so |
| 206 | the complete response line is "334 ". |
| 207 | |
| 208 | Note that the AUTH command is still subject to the line length |
| 209 | limitations defined in [SMTP]. If use of the initial response |
| 210 | argument would cause the AUTH command to exceed this length, |
| 211 | the client MUST NOT use the initial response parameter (and |
| 212 | instead proceed as defined in Section 5.1 of [SASL]). |
| 213 | |
| 214 | If the client is transmitting an initial response of zero |
| 215 | length, it MUST instead transmit the response as a single |
| 216 | equals sign ("="). This indicates that the response is |
| 217 | present, but contains no data. |
| 218 | |
| 219 | If the client uses an initial-response argument to the AUTH |
| 220 | command with a SASL mechanism in which the client does not |
| 221 | begin the authentication exchange, the server MUST reject the |
| 222 | |
| 223 | |
| 224 | |
| 225 | |
| 226 | Siemborski & Melnikov Standards Track [Page 4] |
| 227 | |
| 228 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 229 | |
| 230 | |
| 231 | AUTH command with a 501 reply. Servers using the enhanced |
| 232 | status codes extension [ESMTP-CODES] SHOULD return an enhanced |
| 233 | status code of 5.7.0 in this case. |
| 234 | |
| 235 | If the server cannot [BASE64] decode any client response, it |
| 236 | MUST reject the AUTH command with a 501 reply (and an enhanced |
| 237 | status code of 5.5.2). If the client cannot BASE64 decode any |
| 238 | of the server's challenges, it MUST cancel the authentication |
| 239 | using the "*" response. In particular, servers and clients |
| 240 | MUST reject (and not ignore) any character not explicitly |
| 241 | allowed by the BASE64 alphabet, and MUST reject any sequence |
| 242 | of BASE64 characters that contains the pad character ('=') |
| 243 | anywhere other than the end of the string (e.g., "=AAA" and |
| 244 | "AAA=BBB" are not allowed). |
| 245 | |
| 246 | Note that these [BASE64] strings can be much longer than |
| 247 | normal SMTP commands. Clients and servers MUST be able to |
| 248 | handle the maximum encoded size of challenges and responses |
| 249 | generated by their supported authentication mechanisms. This |
| 250 | requirement is independent of any line length limitations the |
| 251 | client or server may have in other parts of its protocol |
| 252 | implementation. (At the time of writing of this document, |
| 253 | 12288 octets is considered to be a sufficient line length |
| 254 | limit for handling of deployed authentication mechanisms.) |
| 255 | If, during an authentication exchange, the server receives a |
| 256 | line that is longer than the server's authentication buffer, |
| 257 | the server fails the AUTH command with the 500 reply. Servers |
| 258 | using the enhanced status codes extension [ESMTP-CODES] SHOULD |
| 259 | return an enhanced status code of 5.5.6 in this case. |
| 260 | |
| 261 | The authorization identity generated by this [SASL] exchange |
| 262 | is a "simple username" (in the sense defined in [SASLprep]), |
| 263 | and both client and server SHOULD (*) use the [SASLprep] |
| 264 | profile of the [StringPrep] algorithm to prepare these names |
| 265 | for transmission or comparison. If preparation of the |
| 266 | authorization identity fails or results in an empty string |
| 267 | (unless it was transmitted as the empty string), the server |
| 268 | MUST fail the authentication. |
| 269 | |
| 270 | (*) Note: Future revision of this specification may change this |
| 271 | requirement to MUST. Currently, the SHOULD is used in order to |
| 272 | avoid breaking the majority of existing implementations. |
| 273 | |
| 274 | If the server is unable to authenticate the client, it SHOULD reject |
| 275 | the AUTH command with a 535 reply unless a more specific error code |
| 276 | is appropriate. Should the client successfully complete the |
| 277 | exchange, the SMTP server issues a 235 reply. (Note that the SMTP |
| 278 | protocol doesn't support the SASL feature of returning additional |
| 279 | |
| 280 | |
| 281 | |
| 282 | Siemborski & Melnikov Standards Track [Page 5] |
| 283 | |
| 284 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 285 | |
| 286 | |
| 287 | data with a successful outcome.) These status codes, along with |
| 288 | others defined by this extension, are discussed in Section 6 of this |
| 289 | document. |
| 290 | |
| 291 | If a security layer is negotiated during the SASL exchange, it takes |
| 292 | effect for the client on the octet immediately following the CRLF |
| 293 | that concludes the last response generated by the client. For the |
| 294 | server, it takes effect immediately following the CRLF of its success |
| 295 | reply. |
| 296 | |
| 297 | When a security layer takes effect, the SMTP protocol is reset to the |
| 298 | initial state (the state in SMTP after a server issues a 220 service |
| 299 | ready greeting). The server MUST discard any knowledge obtained from |
| 300 | the client, such as the EHLO argument, which was not obtained from |
| 301 | the SASL negotiation itself. Likewise, the client MUST discard any |
| 302 | knowledge obtained from the server, such as the list of SMTP service |
| 303 | extensions, which was not obtained from the SASL negotiation itself. |
| 304 | (Note that a client MAY compare the advertised SASL mechanisms before |
| 305 | and after authentication in order to detect an active down- |
| 306 | negotiation attack). |
| 307 | |
| 308 | The client SHOULD send an EHLO command as the first command after a |
| 309 | successful SASL negotiation that results in the enabling of a |
| 310 | security layer. |
| 311 | |
| 312 | When an entity (whether it is the client or the server end) is |
| 313 | sending data, and both [TLS] and SASL security layers are in effect, |
| 314 | the TLS encoding MUST be applied after the SASL encoding, regardless |
| 315 | of the order in which the layers were negotiated. |
| 316 | |
| 317 | The service name specified by this protocol's profile of SASL is |
| 318 | "smtp". This service name is also to be used for the [SUBMIT] |
| 319 | protocol. |
| 320 | |
| 321 | If an AUTH command fails, the client MAY proceed without |
| 322 | authentication. Alternatively, the client MAY try another |
| 323 | authentication mechanism or present different credentials by issuing |
| 324 | another AUTH |
| 325 | |
| 326 | Note: A server implementation MUST implement a configuration in which |
| 327 | it does NOT permit any plaintext password mechanisms, unless either |
| 328 | the STARTTLS [SMTP-TLS] command has been negotiated or some other |
| 329 | mechanism that protects the session from password snooping has been |
| 330 | provided. Server sites SHOULD NOT use any configuration which |
| 331 | permits a plaintext password mechanism without such a protection |
| 332 | mechanism against password snooping. |
| 333 | |
| 334 | |
| 335 | |
| 336 | |
| 337 | |
| 338 | Siemborski & Melnikov Standards Track [Page 6] |
| 339 | |
| 340 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 341 | |
| 342 | |
| 343 | To ensure interoperability, client and server implementations of this |
| 344 | extension MUST implement the [PLAIN] SASL mechanism running over TLS |
| 345 | [TLS] [SMTP-TLS]. See also Section 15 for additional requirements on |
| 346 | implementations of [PLAIN] over [TLS]. |
| 347 | |
| 348 | Note that many existing client and server implementations implement |
| 349 | CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to ensure |
| 350 | interoperability with deployed software, new implementations MAY |
| 351 | implement it; however, implementations should be aware that this SASL |
| 352 | mechanism doesn't provide any server authentication. Note that at |
| 353 | the time of writing of this document the SASL Working Group is |
| 354 | working on several replacement SASL mechanisms that provide server |
| 355 | authentication and other features. |
| 356 | |
| 357 | When the AUTH command is used together with the [PIPELINING] |
| 358 | extension, it MUST be the last command in a pipelined group of |
| 359 | commands. The only exception to this rule is when the AUTH command |
| 360 | contains an initial response for a SASL mechanism that allows the |
| 361 | client to send data first, the SASL mechanism is known to complete in |
| 362 | one round-trip, and a security layer is not negotiated by the client. |
| 363 | Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL |
| 364 | [SASL]. |
| 365 | |
| 366 | 4.1. Examples |
| 367 | |
| 368 | Here is an example of a client attempting AUTH using the [PLAIN] SASL |
| 369 | mechanism under a TLS layer, and making use of the initial client |
| 370 | response: |
| 371 | |
| 372 | S: 220-smtp.example.com ESMTP Server |
| 373 | C: EHLO client.example.com |
| 374 | S: 250-smtp.example.com Hello client.example.com |
| 375 | S: 250-AUTH GSSAPI DIGEST-MD5 |
| 376 | S: 250-ENHANCEDSTATUSCODES |
| 377 | S: 250 STARTTLS |
| 378 | C: STARTTLS |
| 379 | S: 220 Ready to start TLS |
| 380 | ... TLS negotiation proceeds, further commands |
| 381 | protected by TLS layer ... |
| 382 | C: EHLO client.example.com |
| 383 | S: 250-smtp.example.com Hello client.example.com |
| 384 | S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN |
| 385 | C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ= |
| 386 | S: 235 2.7.0 Authentication successful |
| 387 | |
| 388 | Here is another client that is attempting AUTH PLAIN under a TLS |
| 389 | layer, this time without the initial response. Parts of the |
| 390 | negotiation before the TLS layer was established have been omitted: |
| 391 | |
| 392 | |
| 393 | |
| 394 | Siemborski & Melnikov Standards Track [Page 7] |
| 395 | |
| 396 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 397 | |
| 398 | |
| 399 | ... TLS negotiation proceeds, further commands |
| 400 | protected by TLS layer ... |
| 401 | C: EHLO client.example.com |
| 402 | S: 250-smtp.example.com Hello client.example.com |
| 403 | S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN |
| 404 | C: AUTH PLAIN |
| 405 | (note: there is a single space following the 334 |
| 406 | on the following line) |
| 407 | S: 334 |
| 408 | C: dGVzdAB0ZXN0ADEyMzQ= |
| 409 | S: 235 2.7.0 Authentication successful |
| 410 | |
| 411 | Here is an example using CRAM-MD5 [CRAM-MD5], a mechanism in which |
| 412 | the client does not begin the authentication exchange, and includes a |
| 413 | server challenge: |
| 414 | |
| 415 | S: 220-smtp.example.com ESMTP Server |
| 416 | C: EHLO client.example.com |
| 417 | S: 250-smtp.example.com Hello client.example.com |
| 418 | S: 250-AUTH DIGEST-MD5 CRAM-MD5 |
| 419 | S: 250-ENHANCEDSTATUSCODES |
| 420 | S: 250 STARTTLS |
| 421 | C: AUTH CRAM-MD5 |
| 422 | S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk |
| 423 | dT4= |
| 424 | C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA== |
| 425 | S: 235 2.7.0 Authentication successful |
| 426 | |
| 427 | Here is an example of a client attempting AUTH EXTERNAL under TLS, |
| 428 | using the derived authorization ID (and thus a zero-length initial |
| 429 | client response). |
| 430 | |
| 431 | S: 220-smtp.example.com ESMTP Server |
| 432 | C: EHLO client.example.com |
| 433 | S: 250-smtp.example.com Hello client.example.com |
| 434 | S: 250-AUTH GSSAPI DIGEST-MD5 |
| 435 | S: 250-ENHANCEDSTATUSCODES |
| 436 | S: 250 STARTTLS |
| 437 | C: STARTTLS |
| 438 | S: 220 Ready to start TLS |
| 439 | ... TLS negotiation proceeds, further commands |
| 440 | protected by TLS layer ... |
| 441 | C: EHLO client.example.com |
| 442 | S: 250-smtp.example.com Hello client.example.com |
| 443 | S: 250 AUTH EXTERNAL GSSAPI DIGEST-MD5 PLAIN |
| 444 | C: AUTH EXTERNAL = |
| 445 | S: 235 2.7.0 Authentication successful |
| 446 | |
| 447 | |
| 448 | |
| 449 | |
| 450 | Siemborski & Melnikov Standards Track [Page 8] |
| 451 | |
| 452 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 453 | |
| 454 | |
| 455 | 5. The AUTH Parameter to the MAIL FROM command |
| 456 | |
| 457 | AUTH=mailbox |
| 458 | |
| 459 | Arguments: |
| 460 | A <mailbox> (see Section 4.1.2 of [SMTP]) that is associated |
| 461 | with the identity that submitted the message to the delivery |
| 462 | system, or the two character sequence "<>" indicating such an |
| 463 | identity is unknown or insufficiently authenticated. To comply |
| 464 | with restrictions imposed on ESMTP parameters, the <mailbox> is |
| 465 | encoded inside an xtext. The syntax of an xtext is described in |
| 466 | Section 4 of [ESMTP-DSN]. |
| 467 | |
| 468 | Note: |
| 469 | For the purposes of this discussion, "authenticated identity" |
| 470 | refers to the identity (if any) derived from the authorization |
| 471 | identity of previous AUTH command, while the terms "authorized |
| 472 | identity" and "supplied <mailbox>" refer to the sender identity |
| 473 | that is being associated with a particular message. Note that |
| 474 | one authenticated identity may be able to identify messages as |
| 475 | being sent by any number of authorized identities within a |
| 476 | single session. For example, this may be the case when an SMTP |
| 477 | server (one authenticated identity) is processing its queue |
| 478 | (many messages with distinct authorized identities). |
| 479 | |
| 480 | Discussion: |
| 481 | The optional AUTH parameter to the MAIL FROM command allows |
| 482 | cooperating agents in a trusted environment to communicate the |
| 483 | authorization identity associated with individual messages. |
| 484 | |
| 485 | If the server trusts the authenticated identity of the client to |
| 486 | assert that the message was originally submitted by the supplied |
| 487 | <mailbox>, then the server SHOULD supply the same <mailbox> in |
| 488 | an AUTH parameter when relaying the message to any other server |
| 489 | which supports the AUTH extension. |
| 490 | |
| 491 | For this reason, servers that advertise support for this |
| 492 | extension MUST support the AUTH parameter to the MAIL FROM |
| 493 | command even when the client has not authenticated itself to the |
| 494 | server. |
| 495 | |
| 496 | A MAIL FROM parameter of AUTH=<> indicates that the original |
| 497 | submitter of the message is not known. The server MUST NOT |
| 498 | treat the message as having been originally submitted by the |
| 499 | authenticated identity that resulted from the AUTH command. |
| 500 | |
| 501 | |
| 502 | |
| 503 | |
| 504 | |
| 505 | |
| 506 | Siemborski & Melnikov Standards Track [Page 9] |
| 507 | |
| 508 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 509 | |
| 510 | |
| 511 | If the AUTH parameter to the MAIL FROM command is not supplied, |
| 512 | the client has authenticated, and the server believes the |
| 513 | message is an original submission, the server MAY generate a |
| 514 | <mailbox> from the user's authenticated identity for use in an |
| 515 | AUTH parameter when relaying the message to any server which |
| 516 | supports the AUTH extension. The generated <mailbox> is |
| 517 | implementation specific, but it MUST conform to the syntax of |
| 518 | [SMTP]. If the implementation cannot generate a valid |
| 519 | <mailbox>, it MUST transmit AUTH=<> when relaying this message. |
| 520 | |
| 521 | If the server does not sufficiently trust the authenticated |
| 522 | identity of the client, or if the client is not authenticated, |
| 523 | then the server MUST behave as if the AUTH=<> parameter was |
| 524 | supplied. The server MAY, however, write the value of any |
| 525 | supplied AUTH parameter to a log file. |
| 526 | |
| 527 | If an AUTH=<> parameter was supplied, either explicitly or due |
| 528 | to the requirement in the previous paragraph, then the server |
| 529 | MUST supply the AUTH=<> parameter when relaying the message to |
| 530 | any server which it has authenticated to using the AUTH |
| 531 | extension. |
| 532 | |
| 533 | A server MAY treat expansion of a mailing list as a new |
| 534 | submission, setting the AUTH parameter to the mailing list |
| 535 | address or mailing list administration address when relaying the |
| 536 | message to list subscribers. |
| 537 | |
| 538 | Note that an implementation which is hard-coded to treat all |
| 539 | clients as being insufficiently trusted is compliant with this |
| 540 | specification. In that case, the implementation does nothing |
| 541 | more than parse and discard syntactically valid AUTH parameters |
| 542 | to the MAIL FROM command, and supply AUTH=<> parameters to any |
| 543 | servers that it authenticates to. |
| 544 | |
| 545 | 5.1. Examples |
| 546 | |
| 547 | An example where the original identity of the sender is trusted and |
| 548 | known: |
| 549 | |
| 550 | C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com |
| 551 | S: 250 OK |
| 552 | |
| 553 | One example where the identity of the sender is not trusted or is |
| 554 | otherwise being suppressed by the client: |
| 555 | |
| 556 | C: MAIL FROM:<john+@example.org> AUTH=<> |
| 557 | S: 250 OK |
| 558 | |
| 559 | |
| 560 | |
| 561 | |
| 562 | Siemborski & Melnikov Standards Track [Page 10] |
| 563 | |
| 564 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 565 | |
| 566 | |
| 567 | 6. Status Codes |
| 568 | |
| 569 | The following error codes may be used to indicate various success or |
| 570 | failure conditions. Servers that return enhanced status codes |
| 571 | [ESMTP-CODES] SHOULD use the enhanced codes suggested here. |
| 572 | |
| 573 | 235 2.7.0 Authentication Succeeded |
| 574 | |
| 575 | This response to the AUTH command indicates that the authentication |
| 576 | was successful. |
| 577 | |
| 578 | 432 4.7.12 A password transition is needed |
| 579 | |
| 580 | This response to the AUTH command indicates that the user needs to |
| 581 | transition to the selected authentication mechanism. This is |
| 582 | typically done by authenticating once using the [PLAIN] |
| 583 | authentication mechanism. The selected mechanism SHOULD then work |
| 584 | for authentications in subsequent sessions. |
| 585 | |
| 586 | 454 4.7.0 Temporary authentication failure |
| 587 | |
| 588 | This response to the AUTH command indicates that the authentication |
| 589 | failed due to a temporary server failure. The client SHOULD NOT |
| 590 | prompt the user for another password in this case, and should instead |
| 591 | notify the user of server failure. |
| 592 | |
| 593 | 534 5.7.9 Authentication mechanism is too weak |
| 594 | |
| 595 | This response to the AUTH command indicates that the selected |
| 596 | authentication mechanism is weaker than server policy permits for |
| 597 | that user. The client SHOULD retry with a new authentication |
| 598 | mechanism. |
| 599 | |
| 600 | 535 5.7.8 Authentication credentials invalid |
| 601 | |
| 602 | This response to the AUTH command indicates that the authentication |
| 603 | failed due to invalid or insufficient authentication credentials. In |
| 604 | this case, the client SHOULD ask the user to supply new credentials |
| 605 | (such as by presenting a password dialog box). |
| 606 | |
| 607 | 500 5.5.6 Authentication Exchange line is too long |
| 608 | |
| 609 | This response to the AUTH command indicates that the authentication |
| 610 | failed due to the client sending a [BASE64] response that is longer |
| 611 | than the maximum buffer size available for the currently selected |
| 612 | SASL mechanism. |
| 613 | |
| 614 | |
| 615 | |
| 616 | |
| 617 | |
| 618 | Siemborski & Melnikov Standards Track [Page 11] |
| 619 | |
| 620 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 621 | |
| 622 | |
| 623 | 530 5.7.0 Authentication required |
| 624 | |
| 625 | This response SHOULD be returned by any command other than AUTH, |
| 626 | EHLO, HELO, NOOP, RSET, or QUIT when server policy requires |
| 627 | authentication in order to perform the requested action and |
| 628 | authentication is not currently in force. |
| 629 | |
| 630 | 538 5.7.11 Encryption required for requested authentication |
| 631 | mechanism |
| 632 | |
| 633 | This response to the AUTH command indicates that the selected |
| 634 | authentication mechanism may only be used when the underlying SMTP |
| 635 | connection is encrypted. Note that this response code is documented |
| 636 | here for historical purposes only. Modern implementations SHOULD NOT |
| 637 | advertise mechanisms that are not permitted due to lack of |
| 638 | encryption, unless an encryption layer of sufficient strength is |
| 639 | currently being employed. |
| 640 | |
| 641 | This document adds several new enhanced status codes to the list |
| 642 | defined in [ENHANCED]: |
| 643 | |
| 644 | The following 3 Enhanced Status Codes were defined above: |
| 645 | |
| 646 | 5.7.8 Authentication credentials invalid |
| 647 | 5.7.9 Authentication mechanism is too weak |
| 648 | 5.7.11 Encryption required for requested authentication mechanism |
| 649 | |
| 650 | X.5.6 Authentication Exchange line is too long |
| 651 | |
| 652 | This enhanced status code SHOULD be returned when the server fails |
| 653 | the AUTH command due to the client sending a [BASE64] response which |
| 654 | is longer than the maximum buffer size available for the currently |
| 655 | selected SASL mechanism. This is useful for both permanent and |
| 656 | persistent transient errors. |
| 657 | |
| 658 | 7. Additional Requirements on Servers |
| 659 | |
| 660 | As described in Section 4.4 of [SMTP], an SMTP server that receives a |
| 661 | message for delivery or further processing MUST insert the |
| 662 | "Received:" header field at the beginning of the message content. |
| 663 | This document places additional requirements on the content of a |
| 664 | generated "Received:" header field. Upon successful authentication, |
| 665 | a server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] (when |
| 666 | appropriate) keyword in the "with" clause of the Received header |
| 667 | field. |
| 668 | |
| 669 | |
| 670 | |
| 671 | |
| 672 | |
| 673 | |
| 674 | Siemborski & Melnikov Standards Track [Page 12] |
| 675 | |
| 676 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 677 | |
| 678 | |
| 679 | 8. Formal Syntax |
| 680 | |
| 681 | The following syntax specification uses the Augmented Backus-Naur |
| 682 | Form notation as specified in [ABNF]. Non-terminals referenced but |
| 683 | not defined below are as defined by [ABNF] or [SASL]. The non- |
| 684 | terminal <mailbox> is defined in [SMTP]. |
| 685 | |
| 686 | Except as noted otherwise, all alphabetic characters are case- |
| 687 | insensitive. The use of upper or lower case characters to define |
| 688 | token strings is for editorial clarity only. Implementations MUST |
| 689 | accept these strings in a case-insensitive fashion. |
| 690 | |
| 691 | hexchar = "+" HEXDIG HEXDIG |
| 692 | |
| 693 | xchar = %x21-2A / %x2C-3C / %x3E-7E |
| 694 | ;; US-ASCII except for "+", "=", SP, and CTL |
| 695 | |
| 696 | xtext = *(xchar / hexchar) |
| 697 | ;; non-US-ASCII is only allowed as hexchar |
| 698 | |
| 699 | auth-command = "AUTH" SP sasl-mech [SP initial-response] |
| 700 | *(CRLF [base64]) [CRLF cancel-response] |
| 701 | CRLF |
| 702 | ;; <sasl-mech> is defined in [SASL] |
| 703 | |
| 704 | auth-param = "AUTH=" xtext |
| 705 | ;; Parameter to the MAIL FROM command. |
| 706 | ;; This non-terminal complies with |
| 707 | ;; syntax defined by esmtp-param [SMTP]. |
| 708 | ;; |
| 709 | ;; The decoded form of the xtext MUST be |
| 710 | ;; either a <mailbox> or the two |
| 711 | ;; characters "<>" |
| 712 | |
| 713 | base64 = base64-terminal / |
| 714 | ( 1*(4base64-char) [base64-terminal] ) |
| 715 | |
| 716 | base64-char = ALPHA / DIGIT / "+" / "/" |
| 717 | ;; Case-sensitive |
| 718 | |
| 719 | base64-terminal = (2base64-char "==") / (3base64-char "=") |
| 720 | |
| 721 | continue-req = "334" SP [base64] CRLF |
| 722 | ;; Intermediate response to the AUTH |
| 723 | ;; command. |
| 724 | ;; This non-terminal complies with |
| 725 | ;; syntax defined by Reply-line [SMTP]. |
| 726 | |
| 727 | |
| 728 | |
| 729 | |
| 730 | Siemborski & Melnikov Standards Track [Page 13] |
| 731 | |
| 732 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 733 | |
| 734 | |
| 735 | initial-response= base64 / "=" |
| 736 | |
| 737 | cancel-response = "*" |
| 738 | |
| 739 | 9. Security Considerations |
| 740 | |
| 741 | Security issues are discussed throughout this memo. |
| 742 | |
| 743 | If a client uses this extension to get an encrypted tunnel through an |
| 744 | insecure network to a cooperating server, it needs to be configured |
| 745 | to never send mail to that server when the connection is not mutually |
| 746 | authenticated and encrypted. Otherwise, an attacker could steal the |
| 747 | client's mail by hijacking the [SMTP] connection and either |
| 748 | pretending the server does not support the Authentication extension |
| 749 | or causing all AUTH commands to fail. |
| 750 | |
| 751 | Before the [SASL] negotiation has begun, any protocol interactions |
| 752 | are performed in the clear and may be modified by an active attacker. |
| 753 | For this reason, clients and servers MUST discard any knowledge |
| 754 | obtained prior to the start of the SASL negotiation upon the |
| 755 | establishment of a security layer. |
| 756 | |
| 757 | This mechanism does not protect the TCP port, so an active attacker |
| 758 | may redirect a relay connection attempt (i.e., a connection between |
| 759 | two Mail Transfer Agents (MTAs)) to the submission port [SUBMIT]. |
| 760 | The AUTH=<> parameter prevents such an attack from causing a relayed |
| 761 | message and, in the absence of other envelope authentication, from |
| 762 | picking up the authentication of the relay client. |
| 763 | |
| 764 | A message submission client may require the user to authenticate |
| 765 | whenever a suitable [SASL] mechanism is advertised. Therefore, it |
| 766 | may not be desirable for a submission server [SUBMIT] to advertise a |
| 767 | SASL mechanism when use of that mechanism grants the clients no |
| 768 | benefits over anonymous submission. |
| 769 | |
| 770 | Servers MAY implement a policy whereby the connection is dropped |
| 771 | after a number of failed authentication attempts. If they do so, |
| 772 | they SHOULD NOT drop the connection until at least 3 attempts to |
| 773 | authenticate have failed. |
| 774 | |
| 775 | If an implementation supports SASL mechanisms that are vulnerable to |
| 776 | passive eavesdropping attacks (such as [PLAIN]), then the |
| 777 | implementation MUST support at least one configuration where these |
| 778 | SASL mechanisms are not advertised or used without the presence of an |
| 779 | external security layer such as [TLS]. |
| 780 | |
| 781 | |
| 782 | |
| 783 | |
| 784 | |
| 785 | |
| 786 | Siemborski & Melnikov Standards Track [Page 14] |
| 787 | |
| 788 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 789 | |
| 790 | |
| 791 | This extension is not intended to replace or be used instead of end- |
| 792 | to-end message signature and encryption systems such as [S/MIME] or |
| 793 | [PGP]. This extension addresses a different problem than end-to-end |
| 794 | systems; it has the following key differences: |
| 795 | |
| 796 | 1. It is generally useful only within a trusted enclave. |
| 797 | |
| 798 | 2. It protects the entire envelope of a message, not just the |
| 799 | message's body. |
| 800 | |
| 801 | 3. It authenticates the message submission, not authorship of the |
| 802 | message content. |
| 803 | |
| 804 | 4. When mutual authentication is used along with a security layer, |
| 805 | it can give the sender some assurance that the message was |
| 806 | successfully delivered to the next hop. |
| 807 | |
| 808 | Additional security considerations are mentioned in the [SASL] |
| 809 | specification. Additional security considerations specific to a |
| 810 | particular SASL mechanism are described in the relevant |
| 811 | specification. Additional security considerations for [PLAIN] over |
| 812 | [TLS] are mentioned in Section 15 of this document. |
| 813 | |
| 814 | 10. IANA Considerations |
| 815 | |
| 816 | IANA updated the entry for the "smtp" SASL protocol name to point at |
| 817 | this document. |
| 818 | |
| 819 | IANA updated the registration of the Authentication SMTP service |
| 820 | extension as defined in Section 3 of this document. This registry is |
| 821 | currently located at <http://www.iana.org/assignments/mail- |
| 822 | parameters>. |
| 823 | |
| 824 | 11. Normative References |
| 825 | |
| 826 | [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax |
| 827 | Specifications: ABNF", RFC 4234, October 2005. |
| 828 | |
| 829 | [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data |
| 830 | Encodings", RFC 4648, October 2006. |
| 831 | |
| 832 | [ESMTP-CODES] Freed, N., "SMTP Service Extension for Returning |
| 833 | Enhanced Error Codes", RFC 2034, October 1996. |
| 834 | |
| 835 | [ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC |
| 836 | 3463, January 2003. |
| 837 | |
| 838 | |
| 839 | |
| 840 | |
| 841 | |
| 842 | Siemborski & Melnikov Standards Track [Page 15] |
| 843 | |
| 844 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 845 | |
| 846 | |
| 847 | [ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) |
| 848 | Service Extension Delivery Status Notifications |
| 849 | (DSNs)", RFC 3461, January 2003. |
| 850 | |
| 851 | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate |
| 852 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| 853 | |
| 854 | [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication |
| 855 | and Security Layer (SASL)", RFC 4422, June 2006. |
| 856 | |
| 857 | [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User |
| 858 | Names and Passwords", RFC 4013, February 2005. |
| 859 | |
| 860 | [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, |
| 861 | April 2001. |
| 862 | |
| 863 | [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP |
| 864 | over Transport Layer Security", RFC 3207, February |
| 865 | 2002. |
| 866 | |
| 867 | [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of |
| 868 | Internationalized Strings ("stringprep")", RFC 3454, |
| 869 | December 2002. |
| 870 | |
| 871 | [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for |
| 872 | Mail", RFC 4409, April 2006. |
| 873 | |
| 874 | [SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types |
| 875 | Registration", RFC 3848, July 2004. |
| 876 | |
| 877 | [PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and |
| 878 | Security Layer (SASL) Mechanism", RFC 4616, August |
| 879 | 2006. |
| 880 | |
| 881 | [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet |
| 882 | X.509 Public Key Infrastructure Certificate and |
| 883 | Certificate Revocation List (CRL) Profile", RFC 3280, |
| 884 | April 2002. |
| 885 | |
| 886 | 12. Informative References |
| 887 | |
| 888 | [PGP] Elkins, M., "MIME Security with Pretty Good Privacy |
| 889 | (PGP)", RFC 2015, October 1996. |
| 890 | |
| 891 | [S/MIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail |
| 892 | Extensions (S/MIME) Version 3.1 Message Specification", |
| 893 | RFC 3851, July 2004. |
| 894 | |
| 895 | |
| 896 | |
| 897 | |
| 898 | Siemborski & Melnikov Standards Track [Page 16] |
| 899 | |
| 900 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 901 | |
| 902 | |
| 903 | [TLS] Dierks, T. and E. Rescorla, "The Transport Layer |
| 904 | Security (TLS) Protocol Version 1.1", RFC 4346, April |
| 905 | 2006. |
| 906 | |
| 907 | [PIPELINING] Freed, N., "SMTP Service Extension for Command |
| 908 | Pipelining", STD 60, RFC 2920, September 2000. |
| 909 | |
| 910 | [CRAM-MD5] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP |
| 911 | AUTHorize Extension for Simple Challenge/Response", RFC |
| 912 | 2195, September 1997. |
| 913 | |
| 914 | 13. Acknowledgments |
| 915 | |
| 916 | The editors would like to acknowledge the contributions of John Myers |
| 917 | and other contributors to RFC 2554, on which this document draws from |
| 918 | heavily. |
| 919 | |
| 920 | The editors would also like to thank Ken Murchison, Mark Crispin, |
| 921 | Chris Newman, David Wilson, Dave Cridland, Frank Ellermann, Ned |
| 922 | Freed, John Klensin, Tony Finch, Abhijit Menon-Sen, Philip Guenther, |
| 923 | Sam Hartman, Russ Housley, Cullen Jennings, and Lisa Dusseault for |
| 924 | the time they devoted to reviewing of this document and/or for the |
| 925 | comments received. |
| 926 | |
| 927 | 14. Additional Requirements When Using SASL PLAIN over TLS |
| 928 | |
| 929 | This section is normative for SMTP implementations that support SASL |
| 930 | [PLAIN] over [TLS]. |
| 931 | |
| 932 | If an SMTP client is willing to use SASL PLAIN over TLS to |
| 933 | authenticate to the SMTP server, the client verifies the server |
| 934 | certificate according to the rules of [X509]. If the server has not |
| 935 | provided any certificate, or if the certificate verification fails, |
| 936 | the client MUST NOT attempt to authenticate using the SASL PLAIN |
| 937 | mechanism. |
| 938 | |
| 939 | After a successful [TLS] negotiation, the client MUST check its |
| 940 | understanding of the server hostname against the server's identity as |
| 941 | presented in the server Certificate message, in order to prevent |
| 942 | man-in-the-middle attacks. If the match fails, the client MUST NOT |
| 943 | attempt to authenticate using the SASL PLAIN mechanism. Matching is |
| 944 | performed according to the following rules: |
| 945 | |
| 946 | The client MUST use the server hostname it used to open the |
| 947 | connection as the value to compare against the server name as |
| 948 | expressed in the server certificate. The client MUST NOT use |
| 949 | |
| 950 | |
| 951 | |
| 952 | |
| 953 | |
| 954 | Siemborski & Melnikov Standards Track [Page 17] |
| 955 | |
| 956 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 957 | |
| 958 | |
| 959 | any form of the server hostname derived from an insecure remote |
| 960 | source (e.g., insecure DNS lookup). CNAME canonicalization is |
| 961 | not done. |
| 962 | |
| 963 | If a subjectAltName extension of type dNSName is present in the |
| 964 | certificate, it SHOULD be used as the source of the server's |
| 965 | identity. |
| 966 | |
| 967 | Matching is case-insensitive. |
| 968 | |
| 969 | A "*" wildcard character MAY be used as the leftmost name |
| 970 | component in the certificate. For example, *.example.com would |
| 971 | match a.example.com, foo.example.com, etc., but would not match |
| 972 | example.com. |
| 973 | |
| 974 | If the certificate contains multiple names (e.g., more than one |
| 975 | dNSName field), then a match with any one of the fields is |
| 976 | considered acceptable. |
| 977 | |
| 978 | 15. Changes since RFC 2554 |
| 979 | |
| 980 | 1. Clarified that servers MUST support the use of the AUTH=mailbox |
| 981 | parameter to MAIL FROM, even when the client is not |
| 982 | authenticated. |
| 983 | |
| 984 | 2. Clarified the initial-client-send requirements, and give |
| 985 | additional examples. |
| 986 | |
| 987 | 3. Updated references to newer versions of various specifications. |
| 988 | |
| 989 | 4. Required SASL PLAIN (over TLS) as mandatory-to-implement. |
| 990 | |
| 991 | 5. Clarified that the mechanism list can change. |
| 992 | |
| 993 | 6. Deprecated the use of the 538 response code. |
| 994 | |
| 995 | 7. Added the use of the SASLprep profile for preparing authorization |
| 996 | identities. |
| 997 | |
| 998 | 8. Substantial cleanup of response codes and indicated suggested |
| 999 | enhanced response codes. Also indicated what response codes |
| 1000 | should result in a client prompting the user for new credentials. |
| 1001 | |
| 1002 | 9. Updated ABNF section to use RFC 4234. |
| 1003 | |
| 1004 | 10. Clarified interaction with SMTP PIPELINING extension. |
| 1005 | |
| 1006 | 11. Added a reference to RFC 3848. |
| 1007 | |
| 1008 | |
| 1009 | |
| 1010 | Siemborski & Melnikov Standards Track [Page 18] |
| 1011 | |
| 1012 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 1013 | |
| 1014 | |
| 1015 | 12. Added a new Enhanced Status Code for "authentication line too |
| 1016 | long" case. |
| 1017 | |
| 1018 | 13. Other general editorial clarifications. |
| 1019 | |
| 1020 | Editors' Addresses |
| 1021 | |
| 1022 | Robert Siemborski |
| 1023 | Google, Inc. |
| 1024 | 1600 Ampitheatre Parkway |
| 1025 | Mountain View, CA 94043, USA |
| 1026 | |
| 1027 | Phone: +1 650 623 6925 |
| 1028 | EMail: robsiemb@google.com |
| 1029 | |
| 1030 | |
| 1031 | Alexey Melnikov |
| 1032 | Isode Limited |
| 1033 | 5 Castle Business Village, 36 Station Road, |
| 1034 | Hampton, Middlesex, TW12 2BX, UK |
| 1035 | |
| 1036 | EMail: Alexey.Melnikov@isode.com |
| 1037 | |
| 1038 | |
| 1039 | |
| 1040 | |
| 1041 | |
| 1042 | |
| 1043 | |
| 1044 | |
| 1045 | |
| 1046 | |
| 1047 | |
| 1048 | |
| 1049 | |
| 1050 | |
| 1051 | |
| 1052 | |
| 1053 | |
| 1054 | |
| 1055 | |
| 1056 | |
| 1057 | |
| 1058 | |
| 1059 | |
| 1060 | |
| 1061 | |
| 1062 | |
| 1063 | |
| 1064 | |
| 1065 | |
| 1066 | Siemborski & Melnikov Standards Track [Page 19] |
| 1067 | |
| 1068 | RFC 4954 SMTP Service Extension for Authentication July 2007 |
| 1069 | |
| 1070 | |
| 1071 | Full Copyright Statement |
| 1072 | |
| 1073 | Copyright (C) The IETF Trust (2007). |
| 1074 | |
| 1075 | This document is subject to the rights, licenses and restrictions |
| 1076 | contained in BCP 78, and except as set forth therein, the authors |
| 1077 | retain all their rights. |
| 1078 | |
| 1079 | This document and the information contained herein are provided on an |
| 1080 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
| 1081 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
| 1082 | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |
| 1083 | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |
| 1084 | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED |
| 1085 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
| 1086 | |
| 1087 | Intellectual Property |
| 1088 | |
| 1089 | The IETF takes no position regarding the validity or scope of any |
| 1090 | Intellectual Property Rights or other rights that might be claimed to |
| 1091 | pertain to the implementation or use of the technology described in |
| 1092 | this document or the extent to which any license under such rights |
| 1093 | might or might not be available; nor does it represent that it has |
| 1094 | made any independent effort to identify any such rights. Information |
| 1095 | on the procedures with respect to rights in RFC documents can be |
| 1096 | found in BCP 78 and BCP 79. |
| 1097 | |
| 1098 | Copies of IPR disclosures made to the IETF Secretariat and any |
| 1099 | assurances of licenses to be made available, or the result of an |
| 1100 | attempt made to obtain a general license or permission for the use of |
| 1101 | such proprietary rights by implementers or users of this |
| 1102 | specification can be obtained from the IETF on-line IPR repository at |
| 1103 | http://www.ietf.org/ipr. |
| 1104 | |
| 1105 | The IETF invites any interested party to bring to its attention any |
| 1106 | copyrights, patents or patent applications, or other proprietary |
| 1107 | rights that may cover technology that may be required to implement |
| 1108 | this standard. Please address the information to the IETF at |
| 1109 | ietf-ipr@ietf.org. |
| 1110 | |
| 1111 | Acknowledgement |
| 1112 | |
| 1113 | Funding for the RFC Editor function is currently provided by the |
| 1114 | Internet Society. |
| 1115 | |
| 1116 | |
| 1117 | |
| 1118 | |
| 1119 | |
| 1120 | |
| 1121 | |
| 1122 | Siemborski & Melnikov Standards Track [Page 20] |
| 1123 | |