Oracle

440 E. Huntington Dr., Suite 400 Arcadia CA 91006 US chris.newman@oracle.com

Applications I-D Internet-Draft 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.

Modern IMAP server deployments often have peer systems with administrative privilege that perform actions on behalf of IMAP end-users. For example, a voice mail 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 a transition from authenticated or selected state to not authenticated state.

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 .

None no specific response for this command OK - completed, now in not authenticated stateBAD - command unknown or arguments invalid This command directs the server to reset all connection state, except for state at the TLS layer. Upon completion, the server connection is placed in not authenticated state. This represents transition in the State Machine Diagram. If a mailbox was selected, the mailbox ceases to be selected but no expunge event is generated. If a SASL security layer was active, it terminates immediately after the server sends the CRLF following the OK response. For the client, it terminates immediately after the CRLF following the UNAUTHENTICATE command. 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 , 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 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 need to issue an IMAP CAPABILITY command after authentication in order to determine the availability of UNAUTHENTICATE. The IMAP ID 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 implementation defined.

This section describes interactions between this extension and other IMAP extensions or usage models.

This lists some IMAP extensions that have connection state that MUST be reset if both the specified extension is advertised and the UNAUTHENTICATE command is advertised and used. This list may not be complete; the requirement to reset connection state applies to all current and future extensions except STARTTLS and ID. Cached identity information, such a group memberships, that are used to evaluate access control lists MUST be reset. CONDSTORE servers MUST behave as if no CONDSTORE enabling command had been issued after an UNAUTHENTICATE command is issued. If IMAP COMPRESS is active, the compression layer terminates after the server sends the CRLF following the OK response and after the client sends the CRLF following the UNAUTHENTICATE command. In the event it matters, the compression layer terminates before a SASL layer terminates. Any extensions enabled by the IMAP ENABLE command cease to be enabled when the UNAUTHENTICATE command is issued. This includes, but is not limited to, CONDSTORE , QRESYNC , METADATA , METADATA-SERVER and UTF8=ACCEPT . A server advertising SEARCHRES discards any saved search results so that '$' subsequently represents the empty set. A server advertising LANGUAGE will revert to the "i-default" language. When a server advertises CONTEXT=SEARCH or CONTEXT=SORT , the UNAUTHENTICATE command includes an implicit CANCELUPDATE for all server contexts. When a server advertises NOTIFY , the UNAUTHENTICATE command cancels server state related to the NOTIFY command and reverts to default IMAP base-specification behavior for notifications.

When a TLS security layer is negotiated either via the STARTTLS command or use of the imaps port , IMAP servers MAY be configured to request a client certificate and IMAP clients MAY provide one. Client credentials at the TLS layer do not normally impact the application layer without use of the SASL EXTERNAL mechanism in an IMAP AUTHENTICATE command that directs the server to use the provided client certificate to authenticate as the specified IMAP user. The UNAUTHENTICATE command breaks any application-level binding of the TLS client credentials but does not discard the client credentials. As a result, an administrative client may use a client certificate with administrative privilege to act on behalf of multiple IMAP users in the same connection via the EXTERNAL mechanism and the UNAUTHENTICATE command. Some server implementations using the imaps port will request and use a TLS client certificate to authenticate immediately as the default IMAP identity associated with that certificate. These implementations indicate this behavior by using the PREAUTH greeting as indicated by transition in the State Machine Diagram. As a result, TLS client certificates can not be used for administrative proxy authentication with the imaps port unless the UNAUTHENTICATE command is also advertised. In that case, an administrative client can respond to the PREAUTH greeting with an UNAUTHENTICATE command and then issue an AUTHENTICATE EXTERNAL command.

+----------------------+ |connection established| +----------------------+ || \/ +--------------------------------------+ | server greeting | +--------------------------------------+ || (1) || (2) || (3) \/ || || +-----------------+ || || |Not Authenticated|<===||=========++ || +-----------------+ || (7) || || || (8) || (4) || || || || \/ \/ || || || +----------------+ || || || | |========++ || || | Authenticated |<=++ || || || +----------------+ || || || || || (8) || (5) ||(6) || || || || \/ || || || || || +--------+ || || || || || |Selected|==++ || || || || | |========++ || || || +--------+ || || || || (8) || \/ \/ \/ \/ +--------------------------------------+ | Logout | +--------------------------------------+ || \/ +-------------------------------+ |both sides close the connection| +-------------------------------+

Revised IMAP state machine transitions: connection without pre-authentication (OK greeting) pre-authenticated connection (PREAUTH greeting) rejected connection (BYE greeting) successful LOGIN or AUTHENTICATE command successful SELECT or EXAMINE command CLOSE, UNSELECT or failed SELECT or EXAMINE command UNAUTHENTICATE command LOGOUT command, server shutdown, or connection closed

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in . Amended terms are defined in .

capability =/ "UNAUTHENTICATE" command-auth =/ "UNAUTHENTICATE" command-select =/ "UNAUTHENTICATE"

The IANA shall add the UNAUTHENTICATE capability to the IMAP4 Capabilities Registry.

The original IMAP state machine was designed to allow a server implementation approach where each IMAP authentication identity matches an operating system identity and the server revokes all administrative privilege onces authentication completes. This extension is not compatible with that implementation approach. However, that approach has significant performance costs on Unix systems, and this extension is designed for environments where efficiency is a relatively high priority deployment goal. So this extension is appropriate for some deployments but may not be appropriate for the most security sensitive environments. IMAP server implementations are complicated and can retain a lot of state related to an authenticated user. Server implementers need to take care to reset all server state such that authentication as a subsequent user does not inherit any data or privileges from the previous user. State data associated with a user can include cached identity information such as group membership used to evaluate access control lists , active notifications , access to per-user data such as flags, etc. IMAP server systems are often deployed in a two-tier model where a server-side IMAP proxy routes to an IMAP back-end which handles all connections for a subset of possible users. Some IMAP proxies enter a pass-through mode after authentication. The UNAUTHENTICATE command, if enabled, would allow a client to bypass any security restrictions present in the proxy layer but not in the back-end server layer on a subsequent authentication. As a result, IMAP server implementations of this extension MUST provide a way to disable it when it is not needed. Use of an IMAP proxy that processes the UNAUTHENTICATE command at the proxy layer eliminates this concern. Another option to mitigate this concern is for servers to only enable the UNAUTHENTICATE extension if the supplied authentication credentials were associated with an administrative identity.

For the most part, this extension will have no impact on the privacy considerations already present in an IMAP implementation. However, if this extension were used between data centers, it could improve end-user privacy by increasing the difficultly of traffic analysis due to connection re-use.

The author deliberately choose to add a separate UNAUTHENTICATE command instead of allowing the LOGIN or AUTHENTICATE commands to be issued when the connection is in a state other than unauthenticated state. The primary reason for this choice is because the code that transitions from not authenticated state to authenticated state in a server is often the most security sensitive code as it needs to assume and handle unconditionally hostile attackers. That sensitive code is simpler if it only handles a single server state (unauthenticated) and the state transition is as simple as possible. Smaller and simpler code is easier to audit and write in a secure way. A secondary reason to have a separate command is that it is simpler to enable or disable the feature with that design. See the discussion in the security considerations section recommending implementations provide a way to disable this extension.

Thanks to Fred Batty for implementing UNAUTHENTICATE, and to Cyrus Daboo for constructive suggestions to improve this draft.