ietf-corpus

rfc-8437

IMAP UNAUTHENTICATE Extension for Connection Reuse

C. Newman
date2018-08 streamIETF areaart wgextra statusPROPOSED STANDARD pages11 canonicalhttps://www.rfc-editor.org/rfc/rfc8437 doi10.17487/RFC8437
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.

updates

Extracted elements (23)

design-rationale §A

A secondary reason for using a separate UNAUTHENTICATE command is that it is simpler to enable or disable the feature with that design, supporting the Security Considerations recommendation that implementations provide a way to disable the extension.

email, security

design-rationale §A

A separate UNAUTHENTICATE command was chosen rather than allowing LOGIN or AUTHENTICATE to be issued in non-unauthenticated states, because the code that transitions to authenticated state is the most security-sensitive code in the server — it must handle hostile attackers unconditionally — and keeping that code path simple (starting only from unauthenticated state) makes it easier to audit and implement securely.

email, security

interoperability-note §4.2

Some imaps-port server implementations authenticate immediately using the TLS client certificate and signal this with a PREAUTH greeting. TLS client certificates cannot be used for administrative proxy authentication on the imaps port unless UNAUTHENTICATE is also advertised, allowing the client to issue UNAUTHENTICATE after PREAUTH before re-authenticating via AUTHENTICATE EXTERNAL.

email, tls

interoperability-note §4.2

The UNAUTHENTICATE command breaks any application-level binding of TLS client credentials but does not discard those credentials. An administrative client may therefore use a single client certificate with administrative privilege to act on behalf of multiple IMAP users via SASL EXTERNAL across UNAUTHENTICATE calls.

email, tls, security

normative-requirement §3 MAY

A NO response to UNAUTHENTICATE is not permitted. A BAD response is only permitted if UNAUTHENTICATE is issued in an invalid state, not advertised, or syntactically invalid. Servers that cannot reset connection state MAY close the connection with an untagged BYE instead.

email

normative-requirement §4.1 MUST

A server advertising SEARCHRES (RFC 5182) MUST discard any saved search results after UNAUTHENTICATE, so that '$' subsequently represents the empty set. A server advertising LANGUAGE (RFC 5255) reverts to the 'i-default' language.

email

normative-requirement §4.1 MUST

After UNAUTHENTICATE, CONDSTORE servers (RFC 7162) MUST behave as if no CONDSTORE-enabling command was issued.

email

normative-requirement §4.1 MUST

Any extensions enabled by the IMAP ENABLE command (RFC 5161) cease to be enabled when UNAUTHENTICATE is issued, including CONDSTORE, QRESYNC, METADATA, METADATA-SERVER, and UTF8=ACCEPT.

email

normative-requirement §4.1 MUST

Cached identity information used to evaluate access control lists (RFC 4314), such as group memberships, MUST be reset after UNAUTHENTICATE.

email, security

normative-requirement §4.1 MUST

Connection state for all stateful IMAP extensions (except STARTTLS and ID) MUST be reset if the extension is advertised and UNAUTHENTICATE is advertised and used. This requirement applies to all current and future extensions.

email

normative-requirement §4.1 MUST

If IMAP COMPRESS (RFC 4978) is active, the server terminates its outgoing compression layer after the CRLF following the OK response, and the client terminates its outgoing compression layer after the CRLF following UNAUTHENTICATE. Compression terminates before the SASL layer when both are active.

email

normative-requirement §3 MUST NOT

If no SASL security layer is active, the client is permitted to pipeline the UNAUTHENTICATE command with a subsequent AUTHENTICATE command, enabling re-authentication in one round trip when SASL-IR is also advertised. A server advertising UNAUTHENTICATE is not permitted to respond with NO when it cannot reset state.

email

normative-requirement §3 MAY

Servers MAY choose to advertise the UNAUTHENTICATE capability only after authentication has completed, so clients may need to issue a CAPABILITY command after authentication to determine its availability.

email

normative-requirement §3 MUST

Upon UNAUTHENTICATE, if a mailbox was selected it ceases to be selected without generating an expunge event. If a SASL security layer was active, the server terminates its outgoing security layer immediately after sending the CRLF following the OK response; the client terminates its outgoing security layer immediately after the CRLF following the UNAUTHENTICATE command.

email, security

normative-requirement §4.1 MUST

When a server advertises CONTEXT=SEARCH or CONTEXT=SORT (RFC 5267), the UNAUTHENTICATE command includes an implicit CANCELUPDATE for all server contexts. When NOTIFY (RFC 5465) is advertised, UNAUTHENTICATE cancels server state related to NOTIFY and reverts to default IMAP notification behavior.

email

privacy-consideration §9

If UNAUTHENTICATE is used between data centers, it can improve end-user privacy by increasing the difficulty of traffic analysis due to connection reuse across multiple user identities on the same connection.

email, privacy

protocol-element §6

ABNF syntax adds 'UNAUTHENTICATE' to the capability, command-auth, and command-select productions from RFC 3501, making the command valid in both authenticated and selected states.

email

protocol-element §3

The UNAUTHENTICATE command directs the server to reset all connection state except the TLS layer, placing the connection in the not authenticated state. It takes no arguments and produces no specific response beyond the tagged OK or BAD.

email, security

registry §7

IANA has added the UNAUTHENTICATE capability to the 'IMAP Capabilities' registry.

email, registry

security-consideration §8 MUST

In two-tier IMAP proxy deployments, UNAUTHENTICATE could allow a client to bypass security restrictions present in the proxy layer but absent in the backend. Server implementations of this extension MUST provide a way to disable it when not needed; alternatively, the proxy itself can process the UNAUTHENTICATE command, or servers can restrict the extension to administrative identities.

email, security

security-consideration §8

Server implementers must take care to reset all server state so that authentication as a subsequent user does not inherit any data or privileges from the previous user, including cached group memberships, active notifications, per-user flags, and access control information.

email, security

security-consideration §8

The original IMAP state machine was designed to allow server implementations in which each IMAP authentication identity matches an OS identity and administrative privilege is revoked after authentication. UNAUTHENTICATE is incompatible with that model and is appropriate for performance-sensitive deployments but may not be suitable for the most security-sensitive environments.

email, security

state-machine §5

The revised IMAP state machine adds Transition 7: from Authenticated or Selected state back to Not Authenticated state, triggered by the UNAUTHENTICATE command. All other transitions (1–6, 8) from RFC 3501 are preserved.

email