💾 Archived View for gmi.noulin.net › rfc › rfc8437.gmi captured on 2022-07-17 at 00:12:51. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-06-12)
-=-=-=-=-=-=-
Updates:
Keywords: IMAP, unauthenticate, SASL, login, authenticate, authentication
Internet Engineering Task Force (IETF) C. Newman
Request for Comments: 8437 Oracle
Updates: 3501 August 2018
Category: Standards Track
ISSN: 2070-1721
IMAP UNAUTHENTICATE Extension for Connection Reuse
Abstract
This specification extends the Internet Message Access Protocol
(IMAP) to allow an administrative client to reuse the same IMAP
connection on behalf of multiple IMAP user identities.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8437.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Newman Standards Track [Page 1]
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 3
4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Stateful Extensions . . . . . . . . . . . . . . . . . . . 4
4.2. Client Certificates, SASL EXTERNAL, and imaps . . . . . . 5
5. Revised State Machine . . . . . . . . . . . . . . . . . . . . 6
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Design Considerations . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Modern IMAP [RFC3501] server deployments often have peer systems with
administrative privilege that perform actions on behalf of IMAP end
users. For example, a voicemail gateway can use IMAP to store a
user's voicemail and mark that voicemail as \Seen when the user
listens to it via the phone interface. These systems can issue the
IMAP AUTHENTICATE command with administrative credentials to act on
behalf of other users. However, with the IMAP base specification,
these specialized IMAP clients must close the connection and create a
new connection for each user. For efficiency reasons, it is
desirable for these clients to reuse the same connection,
particularly if SSL has been negotiated. This specification proposes
the UNAUTHENTICATE command to achieve this goal.
The IMAP state machine described in Section 3 of RFC 3501 does not
have a transition from authenticated or selected state to not
authenticated state. The UNAUTHENTICATE command adds this
transition.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Newman Standards Track [Page 2]
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
3. UNAUTHENTICATE Command
Arguments: None
Responses: No specific response for this command
Result: OK - Completed, now in not authenticated state
BAD - Command unknown or arguments invalid
This command directs the server to reset all connection state except
for the state of the TLS [RFC8446] layer. Upon completion, the
server connection is placed in not authenticated state. This
represents Transition 7 in the State Machine Diagram (Section 5).
If a mailbox was selected, the mailbox ceases to be selected, but no
expunge event is generated. If a Simple Authentication and Security
Layer (SASL) [RFC4422] was active, the server terminates its outgoing
security layer immediately after sending the CRLF following the OK
response. The client's outgoing security layer terminates
immediately after the CRLF following the UNAUTHENTICATE command.
Note that a BAD response only occurs if UNAUTHENTICATE is issued in
an invalid state, is not advertised by the server, or does not follow
the command syntax in the specification. A NO response is not
permitted. As a result, specification-compliant implementations will
interoperate across security layer termination.
After sending this command, the client is free to issue a new
AUTHENTICATE or LOGIN command as permitted based on the server's
capabilities. If no SASL security layer was active, the client is
permitted to pipeline the UNAUTHENTICATE command with a subsequent
AUTHENTICATE command. If the IMAP server also advertises SASL-IR
[RFC4959], this permits an administrative client to re-authenticate
in one round trip. Because of this pipelining optimization, a server
advertising UNAUTHENTICATE is not permitted to respond to the
UNAUTHENTICATE command with a NO response if it is unable to reset
the state associated with the connection. Servers MAY close the
connection with an untagged BYE response if this preferably rare
situation occurs.
Servers MAY choose to advertise the UNAUTHENTICATE capability only
after authentication has completed. As a result, clients may need to
issue an IMAP CAPABILITY command after authentication in order to
determine the availability of UNAUTHENTICATE.
Newman Standards Track [Page 3]
RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
The IMAP ID [RFC2971] command provides properties about the client
primarily for use in server log or audit files. Because IMAP ID is
not related to application authentication or user identity in any
way, and caching it for the duration of the client connection can be
useful, the interaction between IMAP ID and the UNAUTHENTICATE
command is defined by the implementation.
4. Interactions
This section describes interactions between this extension and other
IMAP extensions or usage models.
4.1. Stateful Extensions
The connection state for the following list of IMAP extensions MUST
be reset if both a) the specified extension is advertised and b) the
UNAUTHENTICATE command is advertised and used. This list may not be
complete; the requirement to reset the connection state applies to
all current and future extensions except STARTTLS and ID. Additional
requirements apply to specific stateful extensions as follows:
o Cached identity information, such as group memberships, that are
used to evaluate access control lists [RFC4314] MUST be reset.
o After an UNAUTHENTICATE command is issued, CONDSTORE servers
[RFC7162] MUST behave as if no CONDSTORE-enabling command was
issued.
o If IMAP COMPRESS [RFC4978] is active, the server terminates its
outgoing compression layer after it sends the CRLF following the
OK response. The client terminates its outgoing compression layer
after the CRLF following the UNAUTHENTICATE command. When it
matters, the compression layer terminates before a SASL layer
terminates.
o Any extensions enabled by the IMAP ENABLE [RFC5161] command cease
to be enabled when the UNAUTHENTICATE command is issued. This
includes, but is not limited to, CONDSTORE [RFC7162], QRESYNC
[RFC7162], METADATA [RFC5464], METADATA-SERVER [RFC5464], and
UTF8=ACCEPT [RFC6855].
o A server advertising SEARCHRES [RFC5182] discards any saved search
results so that '