doc/specification/draft-siemborski-rfc1734bis-10.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                  Robert Siemborski
   8 INTERNET-DRAFT                                              Google, Inc.
   9 Intended Category: Proposed Standard                   Abhijit Menon-Sen
  10 Obsoletes: RFC 1734                               Oryx Mail Systems GmbH
  11 Updates: RFC 2449                                           January 2007
  12
  13
  14                    POP3 SASL Authentication Mechanism
  15                    draft-siemborski-rfc1734bis-10.txt
  16
  17
  18 Status of this Memo
  19
  20     By submitting this Internet-Draft, each author represents that any
  21     applicable patent or other IPR claims of which he or she is aware
  22     have been or will be disclosed, and any of which he or she becomes
  23     aware will be disclosed, in accordance with Section 6 of BCP 79.
  24
  25     Internet-Drafts are working documents of the Internet Engineering
  26     Task Force (IETF), its areas, and its working groups.  Note that
  27     other groups may also distribute working documents as Internet-
  28     Drafts.
  29
  30     Internet-Drafts are draft documents valid for a maximum of six
  31     months and may be updated, replaced, or obsoleted by other documents
  32     at any time.  It is inappropriate to use Internet-Drafts as
  33     reference material or to cite them other than as "work in progress."
  34
  35     The list of current Internet-Drafts can be accessed at
  36     http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
  37     Draft Shadow Directories can be accessed at
  38     http://www.ietf.org/shadow.html.
  39
  40     This Internet-Draft will expire in May 2007.
  41
  42
  43 Abstract
  44
  45     This document defines a profile of the Simple Authentication and
  46     Security Layer (SASL) for the Post Office Protocol (POP3).  This
  47     extension allows a POP3 client to indicate an authentication
  48     mechanism to the server, perform an authentication protocol
  49     exchange, and optionally negotiate a security layer for subsequent
  50     protocol interactions during this session.
  51
  52     This document seeks to consolidate the information related to POP3
  53     AUTH into a single document.  To this end, this document obsoletes
  54     RFC 1734, replacing it as a Proposed Standard, and updates
  55
  56
  57
  58 Siemborski and Menon-Sen    Expires Jun 2007                    [Page 1]
  59 \f
  60 POP3 SASL Authentication Mechanism                          January 2007
  61
  62
  63     information contained in Section 6.3 of RFC 2449.
  64
  65
  66 1.  Conventions Used in This Document
  67
  68     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  69     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  70     document are to be interpreted as described in [RFC2119].
  71
  72     In examples, "C:" and "S:" indicate lines sent by the client and
  73     server respectively.
  74
  75     Formal syntax is defined by [RFC4234].
  76
  77
  78 2.  Introduction
  79
  80     The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered
  81     several problems in its specification.  The first is that it was
  82     very similar to a SASL framework defined by [RFC4422], but pre-dated
  83     the initial SASL specification.  It was therefore missing some key
  84     components, such as a way to list the available authentication
  85     mechanisms.
  86
  87     Later, [RFC2449] attempted to remedy this situation by adding the
  88     CAPA command and allowing an initial client response with the AUTH
  89     command, but problems remained in the clarity of the specification
  90     of how the initial client response was to be handled.
  91
  92     Together, this means creating a full POP3 AUTH implementation
  93     requires an understanding of material in at least five different
  94     documents (and [RFC3206] provides additional response codes that are
  95     useful during authentication).
  96
  97     This document attempts to combine the information in [RFC1734] and
  98     [RFC2449] to simplify this situation.  Additionally, it aims to
  99     clarify and update the older specifications where appropriate.
 100
 101
 102 3.  The SASL Capability
 103
 104     This section supersedes the definition of the SASL Capability in
 105     section 6.3 of [RFC2449].
 106
 107     CAPA tag:
 108         SASL
 109
 110
 111
 112
 113
 114 Siemborski and Menon-Sen    Expires Jun 2007                    [Page 2]
 115 \f
 116 POP3 SASL Authentication Mechanism                          January 2007
 117
 118
 119     Arguments:
 120         Supported SASL Mechanisms
 121
 122     Added commands:
 123         AUTH
 124
 125     Standard Commands Affected
 126         None
 127
 128     Announced states / possible differences:
 129         both / no
 130
 131     Commands valid in states:
 132         AUTHORIZATION
 133
 134     Specification Reference:
 135         This Document, [RFC4422]
 136
 137     Discussion
 138         The SASL capability permits the use of the AUTH command (as
 139         defined in section 4 of this document) to begin a SASL
 140         negotiation (as defined in [RFC4422]).  The argument to the SASL
 141         capability is a space-separated list of SASL mechanisms which
 142         are supported.
 143
 144         If a server either does not support the CAPA command or does not
 145         advertise the SASL capability, clients SHOULD NOT attempt the
 146         AUTH command.  If a client does attempt the AUTH command in such
 147         a situation, it MUST NOT supply the client initial response
 148         parameter (for backwards compatibility with [RFC1734]).
 149
 150         Note that the list of available mechanisms MAY change after a
 151         successful STLS command (see [RFC2595]).  However, as required
 152         by [RFC2449], implementations MUST continue to include the SASL
 153         capability even after a successful AUTH command has been
 154         completed (even though no further AUTH commands may be issued).
 155
 156     Example
 157         S: +OK pop.example.com BlurdyBlurp POP3 server ready
 158         C: CAPA
 159         S: +OK List of capabilities follows
 160         S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
 161         S: STLS
 162         S: IMPLEMENTATION BlurdyBlurp POP3 server
 163         S: .
 164
 165
 166
 167
 168
 169
 170 Siemborski and Menon-Sen    Expires Jun 2007                    [Page 3]
 171 \f
 172 POP3 SASL Authentication Mechanism                          January 2007
 173
 174
 175 4.  The AUTH Command
 176
 177     AUTH mechanism [initial-response]
 178
 179       Arguments:
 180
 181           mechanism: A string identifying a SASL authentication
 182           mechanism.
 183
 184           initial-response: An optional initial client response, as
 185           defined in section 3 of [RFC4422].  If present, this response
 186           MUST be encoded as Base64 (specified in Section 4 of
 187           [RFC4648]), or consist only of the single character "=", which
 188           represents an empty initial response.
 189
 190       Restrictions:
 191
 192           After an AUTH command has been successfully completed, no more
 193           AUTH commands may be issued in the same session.  After a
 194           successful AUTH command completes, a server MUST reject any
 195           further AUTH commands with an -ERR reply.
 196
 197           The AUTH command may only be given during the AUTHORIZATION
 198           state.
 199
 200       Discussion:
 201
 202           The AUTH command initiates a SASL authentication exchange
 203           between the client and the server.  The client identifies the
 204           SASL mechanism to use with the first parameter of the AUTH
 205           command.  If the server supports the requested authentication
 206           mechanism, it performs the SASL exchange to authenticate the
 207           user.  Optionally, it also negotiates a security layer for
 208           subsequent protocol interactions during this session.  If the
 209           requested authentication mechanism is not supported, the
 210           server rejects the AUTH command with an -ERR reply.
 211
 212           The authentication protocol exchange consists of a series of
 213           server challenges and client responses that are specific to
 214           the chosen SASL mechanism.
 215
 216           A server challenge is sent as a line consisting of a "+"
 217           character followed by a single space and a string encoded
 218           using Base64 as specified in Section 4 of [RFC4648].  This
 219           line MUST NOT contain any text other than the BASE64 encoded
 220           challenge.
 221
 222           A client response consists of a line containing a string
 223
 224
 225
 226 Siemborski and Menon-Sen    Expires Jun 2007                    [Page 4]
 227 \f
 228 POP3 SASL Authentication Mechanism                          January 2007
 229
 230
 231           encoded as Base64.  If the client wishes to cancel the
 232           authentication exchange, it issues a line with a single "*".
 233           If the server receives such a response, it MUST reject the
 234           AUTH command by sending an -ERR reply.
 235
 236           The optional initial-response argument to the AUTH command is
 237           used to save a round trip when using authentication mechanisms
 238           that support an initial client response.  If the initial
 239           response argument is omitted and the chosen mechanism requires
 240           an initial client response, the server MUST proceed by issuing
 241           an empty challenge, as defined in section 3 of [RFC4422].  In
 242           POP3, an empty server challenge is defined as line with only a
 243           "+" followed by a single space.  It MUST NOT contain any other
 244           data.
 245
 246           For the purposes of the initial client response, the 255-octet
 247           limit on the length of a single command, defined in section 4
 248           of [RFC2449], still applies.  If specifying an initial
 249           response would cause the AUTH command to exceed this length,
 250           the client MUST NOT use the initial-response parameter (and
 251           must proceed instead by sending its initial response after an
 252           empty challenge from the server, as in section 3 of
 253           [RFC4422]).
 254
 255           If the client needs to send a zero-length initial response, it
 256           MUST transmit the response as a single equals sign ("=").
 257           This indicates that the response is present, but contains no
 258           data.
 259
 260           If the client uses an initial-response argument to the AUTH
 261           command with a SASL mechanism that does not support an initial
 262           client send, the server MUST reject the AUTH command with an
 263           -ERR reply.
 264
 265           If the server cannot Base64 decode a client response, it MUST
 266           reject the AUTH command with an -ERR reply.  If the client
 267           cannot Base64 decode any of the server's challenges, it MUST
 268           cancel the authentication using the "*" response.  In
 269           particular, servers and clients MUST reject (and not ignore)
 270           any character not explicitly allowed by the Base64 alphabet,
 271           and MUST reject any sequence of Base64 characters that
 272           contains the pad character ('=') anywhere other than the end
 273           of the string (e.g. "=AAA" and "AAA=BBB" are not allowed).
 274
 275           Note that these Base64 strings (excepting the initial client
 276           response) may be of arbitrarily length.  Clients and servers
 277           MUST be able to handle the maximum encoded size of challenges
 278           and responses generated by their supported authentication
 279
 280
 281
 282 Siemborski and Menon-Sen    Expires Jun 2007                    [Page 5]
 283 \f
 284 POP3 SASL Authentication Mechanism                          January 2007
 285
 286
 287           mechanisms.  This requirement is independent of any line
 288           length limitations the client or server may have in other
 289           parts of its protocol implementation.
 290
 291           If the server is unable to authenticate the client, it MUST
 292           reject the AUTH command with an -ERR reply.  Should the client
 293           successfully complete the exchange, the server issues a +OK
 294           reply.  Additionally, upon success, the POP3 session enters
 295           the TRANSACTION state.
 296
 297           The authorization identity generated by the SASL exchange is a
 298           simple username, and SHOULD use the SASLprep profile (see
 299           [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to
 300           prepare these names for matching.  If preparation of the
 301           authorization identity fails or results in an empty string
 302           (unless it was transmitted as the empty string), the server
 303           MUST fail the authentication.
 304
 305           If a security layer is negotiated during the SASL exchange, it
 306           takes effect for the client on the octet immediately following
 307           the CRLF that concludes the last response generated by the
 308           client.  For the server, it takes effect immediately following
 309           the CRLF of its success reply.
 310
 311           When a security layer takes effect, the server MUST discard
 312           any knowledge previously obtained from the client, which was
 313           not obtained from the SASL negotiation itself.  Likewise, the
 314           client MUST discard any knowledge obtained from the server,
 315           such as the list of available POP3 service extensions.
 316
 317           When both TLS (see [RFC4346]) and SASL security layers are in
 318           effect, the TLS encoding MUST be applied after the SASL
 319           encoding when sending data. (According to [RFC2595], STLS can
 320           only be issued before AUTH in any case.)
 321
 322           Note that POP3 does not allow for additional data to be sent
 323           with a message indicating a successful outcome (see section
 324           3.6 of [RFC4422]).
 325
 326           The service name specified by this protocol's profile of SASL
 327           is "pop".
 328
 329           If an AUTH command fails, the client may try another
 330           authentication mechanism or present different credentials by
 331           issuing another AUTH command (or by using one of the other
 332           POP3 authentication mechanisms).  Likewise, the server MUST
 333           behave as if the client had not issued the AUTH command.
 334
 335
 336
 337
 338 Siemborski and Menon-Sen    Expires Jun 2007                    [Page 6]
 339 \f
 340 POP3 SASL Authentication Mechanism                          January 2007
 341
 342
 343           To ensure interoperability, client and server implementations
 344           of this extension MUST implement the PLAIN SASL mechanism,
 345           defined in [RFC4616].
 346
 347           A server implementation MUST implement a configuration in
 348           which it does NOT permit any plaintext password mechanisms,
 349           unless either the STLS command has been used to negotiate a
 350           TLS session (see [RFC2595]), or some other mechanism that
 351           protects the session from password snooping has been provided.
 352           Server sites SHOULD NOT use any configuration which permits a
 353           plaintext password mechanism without such a protection
 354           mechanism against password snooping. Client and server
 355           implementations SHOULD implement additional SASL mechanisms
 356           that do not send plaintext passwords, such as the [DIGEST-MD5]
 357           mechanism.
 358
 359
 360 5.  Formal Syntax
 361
 362     The following syntax specification uses the Augmented Backus-Naur
 363     Form notation as specified in [RFC4234]. The rules CRLF, ALPHA and
 364     DIGIT are imported from [RFC4234]. The sasl-mech rule is from
 365     [RFC4422].
 366
 367     Except as noted otherwise, all alphabetic characters are case-
 368     insensitive. The use of upper or lower case characters to define
 369     token strings is for editorial clarity only.  Implementations MUST
 370     accept these strings in a case-insensitive fashion.
 371
 372       auth-command    = "AUTH" SP sasl-mech [SP (base64 / "=")] *(CRLF
 373                         [base64]) CRLF
 374
 375       auth-resp       = ("*" / base64) CRLF
 376
 377       base64          = base64-terminal /
 378                         ( 1*(4base64-CHAR) [base64-terminal] )
 379
 380       base64-char     = ALPHA / DIGIT / "+" / "/"
 381                         ;; Case-sensitive
 382
 383       base64-terminal = (2base64-char "==") / (3base64-char "=")
 384
 385       continue-req    = "+" SP [base64] CRLF
 386
 387     Additionally, the ABNF specified in [RFC2449] is updated as follows:
 388
 389       response        =/ continue-req
 390
 391
 392
 393
 394 Siemborski and Menon-Sen    Expires Jun 2007                    [Page 7]
 395 \f
 396 POP3 SASL Authentication Mechanism                          January 2007
 397
 398
 399 6.  Examples
 400
 401     Here is an example of a client attempting AUTH PLAIN (see [RFC4616])
 402     under TLS and making use of the initial client response:
 403
 404         S: +OK pop.example.com BlurdyBlurp POP3 server ready
 405         C: CAPA
 406         S: +OK List of capabilities follows
 407         S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
 408         S: STLS
 409         S: IMPLEMENTATION BlurdyBlurp POP3 server
 410         S: .
 411         C: STLS
 412         S: +OK Begin TLS negotiation now
 413             (TLS negotiation proceeds, further commands protected by TLS
 414             layer)
 415         C: CAPA
 416         S: +OK List of capabilities follows
 417         S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
 418         S: IMPLEMENTATION BlurdyBlurp POP3 server
 419         S: .
 420         C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=
 421         S: +OK Maildrop locked and ready
 422
 423     Here is another client that is attempting AUTH PLAIN under a TLS
 424     layer, this time without the initial response.  Parts of the
 425     negotiation before the TLS layer was established have been omitted:
 426
 427             (TLS negotiation proceeds, further commands protected by TLS
 428             layer)
 429         C: CAPA
 430         S: +OK List of capabilities follows
 431         S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
 432         S: IMPLEMENTATION BlurdyBlurp POP3 server
 433         S: .
 434         C: AUTH PLAIN
 435             (note that there is a space following the '+' on the
 436             following line)
 437         S: +
 438         C: dGVzdAB0ZXN0AHRlc3Q=
 439         S: +OK Maildrop locked and ready
 440
 441     Here is an example using a mechanism in which the exchange begins
 442     with a server challenge (the long lines are broken for editorial
 443     clarity only):
 444
 445         S: +OK pop.example.com BlurdyBlurp POP3 server ready
 446         C: CAPA
 447
 448
 449
 450 Siemborski and Menon-Sen    Expires Jun 2007                    [Page 8]
 451 \f
 452 POP3 SASL Authentication Mechanism                          January 2007
 453
 454
 455         S: +OK List of capabilities follows
 456         S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
 457         S: STLS
 458         S: IMPLEMENTATION BlurdyBlurp POP3 server
 459         S: .
 460         C: AUTH DIGEST-MD5
 461         S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
 462              RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
 463              cnNldD11dGYtOA==
 464         C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
 465            QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
 466            MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In
 467            BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1
 468            NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA==
 469         S: + cnNwYXV0aD0wYjk3MTQ2MmNlZjVlOGY5MzBkYjlhMzNiMDJmYzlhMA==
 470         C:
 471         S: +OK Maildrop locked and ready
 472
 473
 474 7.  Security Considerations
 475
 476     Security issues are discussed throughout this document.
 477
 478
 479 8.  IANA Considerations
 480
 481     The IANA is requested to refer to this RFC instead of [RFC1734] in
 482     http://www.iana.org/assignments/pop3-extension-mechanism (the POP3
 483     extension registry).
 484
 485
 486 9.  Acknowledgments
 487
 488     The authors would like to acknowledge the contributions of John
 489     Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other
 490     contributors to RFC 1734 and RFC 2554, on which this document draws
 491     heavily.
 492
 493     The authors would also like to thank Ken Murchison, Randall Gellens,
 494     Alexey Melnikov, Mark Crispin, Arnt Gulbrandsen, Lisa Dusseault, and
 495     Frank Ellermann for their reviews of this document.
 496
 497
 498 10.  Changes From RFC 1734, RFC 2449.
 499
 500     1. The SASL-based semantics defined in RFC 2449 are now normative
 501         for the AUTH extension.
 502
 503
 504
 505
 506 Siemborski and Menon-Sen    Expires Jun 2007                    [Page 9]
 507 \f
 508 POP3 SASL Authentication Mechanism                          January 2007
 509
 510
 511     2. Clarifications and examples of the proper behavior of initial
 512         client response handling.
 513
 514     3. Minimum requirement of support for TLS+PLAIN.
 515
 516     4. Clarify ordering of TLS and SASL security layers.
 517
 518     5. Update references to newer versions of various specifications.
 519
 520     6. Clarify that the mechanism list can change.
 521
 522     7. Add the use of the SASLprep profile for preparing authorization
 523            identities.
 524
 525     8. General other editorial clarifications.
 526
 527     9. Consolidation of much applicable information into a single
 528         document.
 529
 530     10. CR is no longer (incorrectly) defined here.
 531
 532     12. Explicitly mention that "=" means a zero-length initial
 533         response.
 534
 535     13. Change MUST to SHOULD use SASLprep, because nobody does.
 536
 537     14. Clarify that the TLS encoding should be applied after any SASL
 538         one.
 539
 540     15. Note that POP3 doesn't allow additional data to be sent with
 541         +OK.
 542
 543     16. Change "_" to "-" in the ABNF, and use the sasl-mech rule
 544         instead of AUTH_CHAR.
 545
 546     17. Change the KERBEROS_V4 example to DIGEST-MD5 for now; remove
 547         KERBEROS_V4.
 548
 549     18. Reword the reference to [RFC3206] to make it clearer that it is
 550         not mandatory.
 551
 552     19. Define the initial-response by reference to SASL.
 553
 554     20. Add continue-req to the response production from [RFC2449].
 555
 556
 557
 558
 559
 560
 561
 562 Siemborski and Menon-Sen    Expires Jun 2007                   [Page 10]
 563 \f
 564 POP3 SASL Authentication Mechanism                          January 2007
 565
 566
 567 11. Normative References
 568
 569     [RFC1939]  Myers, Rose, "Post Office Protocol - Version 3", STD 53,
 570                RFC 1939, May 1996.
 571
 572     [RFC2119]  Bradner, "Key words for use in RFCs to Indicate
 573                Requirement Levels", BCP 14, RFC 2119, March 1997.
 574
 575     [RFC2449]  Gellens, Newman, Lundblade, "POP3 Extension Mechanism",
 576                RFC 2449, November 1998.
 577
 578     [RFC2595]  Newman, "Using TLS with IMAP, POP3, and ACAP", RFC 2595,
 579                June 1999.
 580
 581     [RFC3454] Hoffman, Blanchet, "Preparation of Internationalized
 582                Strings ("stringprep")", RFC 3454, December 2002.
 583
 584     [RFC4013]  Zeilenga, "SASLprep: Stringprep Profile for User Names
 585                and Passwords", RFC 4013, OpenLDAP Foundation, February
 586                2005.
 587
 588     [RFC4234]  Crocker, Overell, "Augmented BNF for Syntax
 589                Specifications: ABNF", RFC 4234, Brandenburg
 590                Internetworking, Demon Internet Ltd, October 2005.
 591
 592     [RFC4422]  Melnikov, Zeilenga, "Simple Authentication and Security
 593                Layer (SASL)", RFC 4422, June 2006.
 594
 595     [RFC4648]  Josefsson, "The Base16, Base32, and Base64 Data
 596                Encodings", RFC 4648, October 2003.
 597
 598     [RFC4616]  Zeilenga, "The PLAIN Simple Authentication and Security
 599                Layer (SASL) Mechanism", RFC 4616, OpenLDAP Foundation,
 600                August 2006.
 601
 602
 603 12. Informative References
 604
 605     [RFC1734]  Myers, "POP3 AUTHentication Command", RFC 1734, January
 606                1994.
 607
 608     [RFC3206]  Gellens, "The SYS and AUTH POP Response Codes", RFC 3206,
 609                February 2002.
 610
 611     [RFC4346]  Dierks, Rescorla, "The Transport Layer Security (TLS)
 612                Protocol, Version 1.1", RFC 4346, April 2006.
 613
 614     [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL
 615
 616
 617
 618 Siemborski and Menon-Sen    Expires Jun 2007                   [Page 11]
 619 \f
 620 POP3 SASL Authentication Mechanism                          January 2007
 621
 622
 623                Mechanism", draft-ietf-sasl-rfc2831bis-11.txt, Isode
 624                Ltd., November 2006
 625
 626
 627 13. Authors' Addresses
 628
 629     Robert Siemborski
 630     Google, Inc.
 631     1600 Ampitheatre Parkway
 632     Mountain View, CA 94043
 633
 634     Phone: +1 650 623 6925
 635     Email: robsiemb@google.com
 636
 637
 638     Abhijit Menon-Sen
 639     Oryx Mail Systems GmbH
 640
 641     Email: ams@oryx.com
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Siemborski and Menon-Sen    Expires Jun 2007                   [Page 12]
 675 \f
 676 POP3 SASL Authentication Mechanism                          January 2007
 677
 678
 679 Protocol Actions
 680
 681     [RFC Editor: Remove this section before publication]
 682
 683     This document obsoletes RFC 1734 and replaces it as a Proposed
 684     Standard.  By moving RFC 1734 to Historic, RFC 1731 can also be
 685     moved to Historic (as RFC 1734 was the last document to have a
 686     normative reference).
 687
 688     It also updates information contained in Section 6.3 of RFC 2449.
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Siemborski and Menon-Sen    Expires Jun 2007                   [Page 13]
 731 \f
 732 POP3 SASL Authentication Mechanism                          January 2007
 733
 734
 735 Intellectual Property Statement
 736
 737     The IETF takes no position regarding the validity or scope of any
 738     Intellectual Property Rights or other rights that might be claimed
 739     to pertain to the implementation or use of the technology described
 740     in this document or the extent to which any license under such
 741     rights might or might not be available; nor does it represent that
 742     it has made any independent effort to identify any such rights.
 743     Information on the procedures with respect to rights in RFC
 744     documents can be found in BCP 78 and BCP 79.
 745
 746     Copies of IPR disclosures made to the IETF Secretariat and any
 747     assurances of licenses to be made available, or the result of an
 748     attempt made to obtain a general license or permission for the use
 749     of such proprietary rights by implementers or users of this
 750     specification can be obtained from the IETF on-line IPR repository
 751     at http://www.ietf.org/ipr.
 752
 753     The IETF invites any interested party to bring to its attention any
 754     copyrights, patents or patent applications, or other proprietary
 755     rights that may cover technology that may be required to implement
 756     this standard.  Please address the information to the IETF at ietf-
 757     ipr@ietf.org.
 758
 759
 760 Full Copyright Statement
 761
 762     Copyright (C) The Internet Society (2007).  This document is subject
 763     to the rights, licenses and restrictions contained in BCP 78, and
 764     except as set forth therein, the authors retain all their rights.
 765
 766     This document and the information contained herein are provided on
 767     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 768     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 769     INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
 770     IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 771     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 772     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 773
 774
 775 Acknowledgment
 776
 777     Funding for the RFC Editor function is currently provided by the
 778     Internet Society.
 779
 780
 781
 782
 783
 784
 785
 786 Siemborski and Menon-Sen    Expires Jun 2007                   [Page 14]
 787 \f