The IESG has approved the following document: - 'POP3 SASL Authentication Mechanism ' <draft-siemborski-rfc1734bis-11.txt> as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-siemborski-rfc1734bis-11.txt Technical Summary This document is a revision of RFC 1734, which specifies the POP3 AUTH command, which allows a POP3 client to initiate a SASL authentication exchange with a POP3 server. Working Group Summary This document is not the result of a WG. Document Quality The document has been reviewed by Frank Ellermann, Alexey Melnikov, Arnt Gulbrandsen, and Philip Guenther. Lisa Dusseault is the responsible AD. Note to RFC Editor Abstract, second paragraph: Replace OLD: AUTH into a single document. To this end, this document obsoletes RFC 1734, replacing it as a Proposed Standard, and updates information contained in Section 6.3 of RFC 2449. With NEW: AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained in Section 6.3 of RFC 2449. Section 4, penultimate and final paragraphs: Replace OLD: To ensure interoperability, client and server implementations of this extension MUST implement the PLAIN SASL mechanism, defined in [RFC4616]. A server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless either the STLS command has been used to negotiate a TLS session (see [RFC2595]), or some other mechanism that protects the session from password snooping has been provided. Server sites SHOULD NOT use any configuration which permits a plaintext password mechanism without such a protection mechanism against password snooping. Client and server implementations SHOULD implement additional SASL mechanisms that do not send plaintext passwords, such as the [DIGEST-MD5] mechanism. With NEW: To ensure interoperability, client and server implementations of this extension MUST implement the PLAIN SASL mechanism [RFC4616] running over TLS [RFC2595]. A server implementation MUST implement a configuration in which it does NOT advertise or permit any plaintext password mechanisms, unless the STLS command has been used to negotiate a TLS session (see [RFC2595]). As described by RFC 4616, this configuration SHOULD be the default configuration. Before using a plaintext password mechanism over a TLS session, client implementations MUST verify the TLS server certificate as required by RFC 2595 section 2.4. Client and server implementations SHOULD implement additional SASL mechanisms that do not send plaintext passwords, such as the GSSAPI [RFC4752] mechanism. Section 12, final item: Replace OLD: [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL Mechanism", draft-ietf-sasl-rfc2831bis-11.txt, Isode Ltd., November 2006 With NEW: [RFC4752] Melnikov, "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism, RFC 4752, Isode Ltd., November 2006 _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
