The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism
RFC 5034

Document Type RFC - Proposed Standard (July 2007; No errata)
Obsoletes RFC 1734
Updates RFC 2449
Was draft-siemborski-rfc1734bis (individual in gen area)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5034 (Proposed Standard)
Telechat date
Responsible AD Lisa Dusseault
Send notices to rjs3+@andrew.cmu.edu, ams@oryx.com,alexey.melnikov@isode.com
Network Working Group                                      R. Siemborski
Request for Comments: 5034                                  Google, Inc.
Obsoletes: 1734                                             A. Menon-Sen
Updates: 2449                                     Oryx Mail Systems GmbH
Category: Standards Track                                      July 2007

                    The Post Office Protocol (POP3)
Simple Authentication and Security Layer (SASL) Authentication Mechanism

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines a profile of the Simple Authentication and
   Security Layer (SASL) for the Post Office Protocol (POP3).  This
   extension allows a POP3 client to indicate an authentication
   mechanism to the server, perform an authentication protocol exchange,
   and optionally negotiate a security layer for subsequent protocol
   interactions during this session.

   This document seeks to consolidate the information related to POP3
   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.

Siemborski & Menon-Sen      Standards Track                     [Page 1]
RFC 5034           POP3 SASL Authentication Mechanism          July 2007

1.  Introduction

   The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered
   several problems in its specification.  The first is that it was very
   similar to a SASL framework defined by [RFC4422], but pre-dated the
   initial SASL specification.  It was therefore missing some key
   components, such as a way to list the available authentication
   mechanisms.

   Later, [RFC2449] attempted to remedy this situation by adding the
   CAPA command and allowing an initial client response with the AUTH
   command, but problems remained in the clarity of the specification of
   how the initial client response was to be handled.

   Together, this means creating a full POP3 AUTH implementation
   requires an understanding of material in at least five different
   documents (and [RFC3206] provides additional response codes that are
   useful during authentication).

   This document attempts to combine the information in [RFC1734] and
   [RFC2449] to simplify this situation.  Additionally, it aims to
   clarify and update the older specifications where appropriate.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   Formal syntax is defined by [RFC4234].

3.  The SASL Capability

   This section supersedes the definition of the SASL Capability in
   section 6.3 of [RFC2449].

   CAPA tag:
      SASL

   Arguments:
      Supported SASL Mechanisms

   Added commands:
      AUTH

Siemborski & Menon-Sen      Standards Track                     [Page 2]
RFC 5034           POP3 SASL Authentication Mechanism          July 2007

   Standard commands affected:
      None

   Announced states / possible differences:
      both / no

   Commands valid in states:
      AUTHORIZATION

   Specification reference:
      This document and [RFC4422]

   Discussion:
      The SASL capability permits the use of the AUTH command (as
      defined in Section 4 of this document) to begin a SASL negotiation
      (as defined in [RFC4422]).  The argument to the SASL capability is
      a space-separated list of SASL mechanisms that are supported.

      If a server either does not support the CAPA command or does not
      advertise the SASL capability, clients SHOULD NOT attempt the AUTH
      command.  If a client does attempt the AUTH command in such a
      situation, it MUST NOT supply the client initial response
      parameter (for backwards compatibility with [RFC1734]).

      Note that the list of available mechanisms MAY change after a
      successful STLS command (see [RFC2595]).  However, as required by
      [RFC2449], implementations MUST continue to include the SASL
      capability even after a successful AUTH command has been completed
Show full document text