7Internet Engineering Task Force (IETF) C. Newman
8Request for Comments: 8437 Oracle
9Updates: 3501 August 2018
10Category: Standards Track
14 IMAP UNAUTHENTICATE Extension for Connection Reuse
18 This specification extends the Internet Message Access Protocol
19 (IMAP) to allow an administrative client to reuse the same IMAP
20 connection on behalf of multiple IMAP user identities.
24 This is an Internet Standards Track document.
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 7841.
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 https://www.rfc-editor.org/info/rfc8437.
38 Copyright (c) 2018 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
58Newman Standards Track [Page 1]
60RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 2
67 3. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 3
68 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 4
69 4.1. Stateful Extensions . . . . . . . . . . . . . . . . . . . 4
70 4.2. Client Certificates, SASL EXTERNAL, and imaps . . . . . . 5
71 5. Revised State Machine . . . . . . . . . . . . . . . . . . . . 6
72 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
75 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
77 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
78 10.2. Informative References . . . . . . . . . . . . . . . . . 9
79 Appendix A. Design Considerations . . . . . . . . . . . . . . . 11
80 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
85 Modern IMAP [RFC3501] server deployments often have peer systems with
86 administrative privilege that perform actions on behalf of IMAP end
87 users. For example, a voicemail gateway can use IMAP to store a
88 user's voicemail and mark that voicemail as \Seen when the user
89 listens to it via the phone interface. These systems can issue the
90 IMAP AUTHENTICATE command with administrative credentials to act on
91 behalf of other users. However, with the IMAP base specification,
92 these specialized IMAP clients must close the connection and create a
93 new connection for each user. For efficiency reasons, it is
94 desirable for these clients to reuse the same connection,
95 particularly if SSL has been negotiated. This specification proposes
96 the UNAUTHENTICATE command to achieve this goal.
98 The IMAP state machine described in Section 3 of RFC 3501 does not
99 have a transition from authenticated or selected state to not
100 authenticated state. The UNAUTHENTICATE command adds this
1032. Conventions Used in This Document
105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
107 "OPTIONAL" in this document are to be interpreted as described in
108 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
109 capitals, as shown here.
114Newman Standards Track [Page 2]
116RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
1193. UNAUTHENTICATE Command
123 Responses: No specific response for this command
125 Result: OK - Completed, now in not authenticated state
126 BAD - Command unknown or arguments invalid
128 This command directs the server to reset all connection state except
129 for the state of the TLS [RFC8446] layer. Upon completion, the
130 server connection is placed in not authenticated state. This
131 represents Transition 7 in the State Machine Diagram (Section 5).
133 If a mailbox was selected, the mailbox ceases to be selected, but no
134 expunge event is generated. If a Simple Authentication and Security
135 Layer (SASL) [RFC4422] was active, the server terminates its outgoing
136 security layer immediately after sending the CRLF following the OK
137 response. The client's outgoing security layer terminates
138 immediately after the CRLF following the UNAUTHENTICATE command.
139 Note that a BAD response only occurs if UNAUTHENTICATE is issued in
140 an invalid state, is not advertised by the server, or does not follow
141 the command syntax in the specification. A NO response is not
142 permitted. As a result, specification-compliant implementations will
143 interoperate across security layer termination.
145 After sending this command, the client is free to issue a new
146 AUTHENTICATE or LOGIN command as permitted based on the server's
147 capabilities. If no SASL security layer was active, the client is
148 permitted to pipeline the UNAUTHENTICATE command with a subsequent
149 AUTHENTICATE command. If the IMAP server also advertises SASL-IR
150 [RFC4959], this permits an administrative client to re-authenticate
151 in one round trip. Because of this pipelining optimization, a server
152 advertising UNAUTHENTICATE is not permitted to respond to the
153 UNAUTHENTICATE command with a NO response if it is unable to reset
154 the state associated with the connection. Servers MAY close the
155 connection with an untagged BYE response if this preferably rare
158 Servers MAY choose to advertise the UNAUTHENTICATE capability only
159 after authentication has completed. As a result, clients may need to
160 issue an IMAP CAPABILITY command after authentication in order to
161 determine the availability of UNAUTHENTICATE.
170Newman Standards Track [Page 3]
172RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
175 The IMAP ID [RFC2971] command provides properties about the client
176 primarily for use in server log or audit files. Because IMAP ID is
177 not related to application authentication or user identity in any
178 way, and caching it for the duration of the client connection can be
179 useful, the interaction between IMAP ID and the UNAUTHENTICATE
180 command is defined by the implementation.
184 This section describes interactions between this extension and other
185 IMAP extensions or usage models.
1874.1. Stateful Extensions
189 The connection state for the following list of IMAP extensions MUST
190 be reset if both a) the specified extension is advertised and b) the
191 UNAUTHENTICATE command is advertised and used. This list may not be
192 complete; the requirement to reset the connection state applies to
193 all current and future extensions except STARTTLS and ID. Additional
194 requirements apply to specific stateful extensions as follows:
196 o Cached identity information, such as group memberships, that are
197 used to evaluate access control lists [RFC4314] MUST be reset.
199 o After an UNAUTHENTICATE command is issued, CONDSTORE servers
200 [RFC7162] MUST behave as if no CONDSTORE-enabling command was
203 o If IMAP COMPRESS [RFC4978] is active, the server terminates its
204 outgoing compression layer after it sends the CRLF following the
205 OK response. The client terminates its outgoing compression layer
206 after the CRLF following the UNAUTHENTICATE command. When it
207 matters, the compression layer terminates before a SASL layer
210 o Any extensions enabled by the IMAP ENABLE [RFC5161] command cease
211 to be enabled when the UNAUTHENTICATE command is issued. This
212 includes, but is not limited to, CONDSTORE [RFC7162], QRESYNC
213 [RFC7162], METADATA [RFC5464], METADATA-SERVER [RFC5464], and
214 UTF8=ACCEPT [RFC6855].
216 o A server advertising SEARCHRES [RFC5182] discards any saved search
217 results so that '$' subsequently represents the empty set.
219 o A server advertising LANGUAGE [RFC5255] will revert to the
220 "i-default" language.
226Newman Standards Track [Page 4]
228RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
231 o When a server advertises CONTEXT=SEARCH or CONTEXT=SORT [RFC5267],
232 the UNAUTHENTICATE command includes an implicit CANCELUPDATE for
235 o When a server advertises NOTIFY [RFC5465], the UNAUTHENTICATE
236 command cancels the server state related to the NOTIFY command and
237 reverts to default IMAP base-specification behavior for
2404.2. Client Certificates, SASL EXTERNAL, and imaps
242 When a TLS [RFC8446] security layer is negotiated using either the
243 STARTTLS command or the imaps port [RFC8314], IMAP servers may be
244 configured to request a client certificate, and IMAP clients may
245 provide one. Client credentials at the TLS layer do not normally
246 impact the application layer; however, they do have an impact when
247 the SASL EXTERNAL mechanism [RFC4422] in an IMAP AUTHENTICATE command
248 is used to direct the server to use the provided client certificate
249 to authenticate as the specified IMAP user. The UNAUTHENTICATE
250 command breaks any application-level binding of the TLS client
251 credentials but does not discard the client credentials. As a
252 result, an administrative client may use a client certificate with
253 administrative privilege to act on behalf of multiple IMAP users in
254 the same connection via the EXTERNAL mechanism and the UNAUTHENTICATE
257 Some server implementations using the imaps port will request and use
258 a TLS client certificate to authenticate immediately as the default
259 IMAP identity associated with that certificate. These
260 implementations indicate this behavior by using the PREAUTH greeting,
261 as indicated by Transition 2 in the State Machine Diagram
262 (Section 5). As a result, TLS client certificates cannot be used for
263 administrative proxy authentication with the imaps port unless the
264 UNAUTHENTICATE command is also advertised. In that case, an
265 administrative client can respond to the PREAUTH greeting with an
266 UNAUTHENTICATE command and then issue an AUTHENTICATE EXTERNAL
282Newman Standards Track [Page 5]
284RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
2875. Revised State Machine
289 +----------------------+
290 |connection established|
291 +----------------------+
294 +--------------------------------------+
296 +--------------------------------------+
299 +-----------------+ || ||
300 |Not Authenticated|<===||=========++ ||
301 +-----------------+ || (7) || ||
302 || (8) || (4) || || ||
304 || +----------------+ || ||
306 || | Authenticated |<=++ || ||
307 || +----------------+ || || ||
308 || || (8) || (5) ||(6) || ||
310 || || +--------+ || || ||
311 || || |Selected|==++ || ||
312 || || | |========++ ||
316 +--------------------------------------+
318 +--------------------------------------+
321 +-------------------------------+
322 |both sides close the connection|
323 +-------------------------------+
325 Revised IMAP state machine transitions:
327 1. Connection without pre-authentication (OK greeting)
329 2. Pre-authenticated connection (PREAUTH greeting)
331 3. Rejected connection (BYE greeting)
333 4. Successful LOGIN or AUTHENTICATE command
338Newman Standards Track [Page 6]
340RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
343 5. Successful SELECT or EXAMINE command
345 6. CLOSE, UNSELECT [RFC3691], or failed SELECT or EXAMINE command
347 7. UNAUTHENTICATE command
349 8. LOGOUT command, server shutdown, or connection closed
353 The following syntax specification uses the Augmented Backus-Naur
354 Form (ABNF), as described in [RFC5234]. Amended terms are defined in
357 capability =/ "UNAUTHENTICATE"
359 command-auth =/ "UNAUTHENTICATE"
361 command-select =/ "UNAUTHENTICATE"
3637. IANA Considerations
365 IANA has added the UNAUTHENTICATE capability to the "IMAP
366 Capabilities" registry.
3688. Security Considerations
370 The original IMAP state machine was designed to allow a server-
371 implementation approach in which each IMAP authentication identity
372 matches an operating system identity and the server revokes all
373 administrative privilege once authentication completes. This
374 extension is not compatible with that implementation approach.
375 However, that approach has significant performance costs on Unix
376 systems, and this extension is designed for environments where
377 efficiency is a relatively high-priority deployment goal. This
378 extension is therefore appropriate for some deployments but may not
379 be appropriate for the most security-sensitive environments.
381 IMAP server implementations are complicated and can retain a lot of
382 state related to an authenticated user. Server implementers need to
383 take care to reset all server state such that authentication as a
384 subsequent user does not inherit any data or privileges from the
385 previous user. State data associated with a user can include cached
386 identity information such as group membership used to evaluate access
387 control lists [RFC4314], active notifications [RFC5465], access to
388 per-user data such as flags, etc.
394Newman Standards Track [Page 7]
396RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
399 IMAP server systems are often deployed in a two-tier model where a
400 server-side IMAP proxy routes to an IMAP backend that handles all
401 connections for a subset of possible users. Some IMAP proxies enter
402 a pass-through mode after authentication. If enabled, the
403 UNAUTHENTICATE command would allow a client, on a subsequent
404 authentication, to bypass any security restrictions present in the
405 proxy layer but not in the backend server layer. As a result, IMAP
406 server implementations of this extension MUST provide a way to
407 disable it when it is not needed. Use of an IMAP proxy that
408 processes the UNAUTHENTICATE command at the proxy layer eliminates
409 this concern. Another option to mitigate this concern is for servers
410 to only enable the UNAUTHENTICATE extension if the supplied
411 authentication credentials are associated with an administrative
4149. Privacy Considerations
416 For the most part, this extension will have no impact on the privacy
417 considerations already present in an IMAP implementation. However,
418 if this extension were used between data centers, it could improve
419 end-user privacy by increasing the difficultly of traffic analysis
420 due to connection reuse.
42410.1. Normative References
426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
427 Requirement Levels", BCP 14, RFC 2119,
428 DOI 10.17487/RFC2119, March 1997,
429 <https://www.rfc-editor.org/info/rfc2119>.
431 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
432 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
433 <https://www.rfc-editor.org/info/rfc3501>.
435 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
436 Specifications: ABNF", STD 68, RFC 5234,
437 DOI 10.17487/RFC5234, January 2008,
438 <https://www.rfc-editor.org/info/rfc5234>.
440 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
441 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
442 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
450Newman Standards Track [Page 8]
452RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
45510.2. Informative References
457 [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971,
458 DOI 10.17487/RFC2971, October 2000,
459 <https://www.rfc-editor.org/info/rfc2971>.
461 [RFC3691] Melnikov, A., "Internet Message Access Protocol (IMAP)
462 UNSELECT command", RFC 3691, DOI 10.17487/RFC3691,
463 February 2004, <https://www.rfc-editor.org/info/rfc3691>.
465 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
466 RFC 4314, DOI 10.17487/RFC4314, December 2005,
467 <https://www.rfc-editor.org/info/rfc4314>.
469 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
470 Authentication and Security Layer (SASL)", RFC 4422,
471 DOI 10.17487/RFC4422, June 2006,
472 <https://www.rfc-editor.org/info/rfc4422>.
474 [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
475 Simple Authentication and Security Layer (SASL) Initial
476 Client Response", RFC 4959, DOI 10.17487/RFC4959,
477 September 2007, <https://www.rfc-editor.org/info/rfc4959>.
479 [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978,
480 DOI 10.17487/RFC4978, August 2007,
481 <https://www.rfc-editor.org/info/rfc4978>.
483 [RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
484 ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March
485 2008, <https://www.rfc-editor.org/info/rfc5161>.
487 [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last
488 SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March
489 2008, <https://www.rfc-editor.org/info/rfc5182>.
491 [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
492 Message Access Protocol Internationalization", RFC 5255,
493 DOI 10.17487/RFC5255, June 2008,
494 <https://www.rfc-editor.org/info/rfc5255>.
496 [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
497 DOI 10.17487/RFC5267, July 2008,
498 <https://www.rfc-editor.org/info/rfc5267>.
506Newman Standards Track [Page 9]
508RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
511 [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464,
512 DOI 10.17487/RFC5464, February 2009,
513 <https://www.rfc-editor.org/info/rfc5464>.
515 [RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
516 NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465,
517 February 2009, <https://www.rfc-editor.org/info/rfc5465>.
519 [RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
520 Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
521 2013, <https://www.rfc-editor.org/info/rfc6855>.
523 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
524 Changes Resynchronization (CONDSTORE) and Quick Mailbox
525 Resynchronization (QRESYNC)", RFC 7162,
526 DOI 10.17487/RFC7162, May 2014,
527 <https://www.rfc-editor.org/info/rfc7162>.
529 [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
530 Use of Transport Layer Security (TLS) for Email Submission
531 and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
532 <https://www.rfc-editor.org/info/rfc8314>.
534 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
535 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
536 <https://www.rfc-editor.org/info/rfc8446>.
562Newman Standards Track [Page 10]
564RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018
567Appendix A. Design Considerations
569 The author deliberately chose to add a separate UNAUTHENTICATE
570 command instead of allowing the LOGIN or AUTHENTICATE commands to be
571 issued when the connection is in a state other than unauthenticated.
572 The primary reason for this choice is that the code that transitions
573 from not authenticated state to authenticated state in a server is
574 often the most security-sensitive code, because it needs to assume
575 and handle unconditionally hostile attackers. That sensitive code is
576 simpler if it only handles a single server state (unauthenticated)
577 and the state transition is as simple as possible. Smaller and
578 simpler code is easier to audit and write in a secure way.
580 A secondary reason to have a separate command is that it is simpler
581 to enable or disable the feature with that design. See the
582 discussion in the Security Considerations section recommending that
583 implementations provide a way to disable this extension.
587 Thanks to Fred Batty for implementing UNAUTHENTICATE and to Cyrus
588 Daboo for constructive suggestions to improve this document.
594 440 E. Huntington Dr., Suite 400
596 United States of America
598 Email: chris.newman@oracle.com
618Newman Standards Track [Page 11]