Protocol Action: 'POP3 SASL Authentication Mechanism' to Proposed Standard

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce