From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8437.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc8437.txt (limited to 'doc/rfc/rfc8437.txt') diff --git a/doc/rfc/rfc8437.txt b/doc/rfc/rfc8437.txt new file mode 100644 index 0000000..4d8e135 --- /dev/null +++ b/doc/rfc/rfc8437.txt @@ -0,0 +1,619 @@ + + + + + + +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 '$' subsequently represents the empty set. + + o A server advertising LANGUAGE [RFC5255] will revert to the + "i-default" language. + + + + + +Newman Standards Track [Page 4] + +RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018 + + + o When a server advertises CONTEXT=SEARCH or CONTEXT=SORT [RFC5267], + the UNAUTHENTICATE command includes an implicit CANCELUPDATE for + all server contexts. + + o When a server advertises NOTIFY [RFC5465], the UNAUTHENTICATE + command cancels the server state related to the NOTIFY command and + reverts to default IMAP base-specification behavior for + notifications. + +4.2. Client Certificates, SASL EXTERNAL, and imaps + + When a TLS [RFC8446] security layer is negotiated using either the + STARTTLS command or the imaps port [RFC8314], 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; however, they do have an impact when + the SASL EXTERNAL mechanism [RFC4422] in an IMAP AUTHENTICATE command + is used to direct 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 2 in the State Machine Diagram + (Section 5). As a result, TLS client certificates cannot 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. + + + + + + + + + + + + + + +Newman Standards Track [Page 5] + +RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018 + + +5. Revised State Machine + + +----------------------+ + |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: + + 1. Connection without pre-authentication (OK greeting) + + 2. Pre-authenticated connection (PREAUTH greeting) + + 3. Rejected connection (BYE greeting) + + 4. Successful LOGIN or AUTHENTICATE command + + + + +Newman Standards Track [Page 6] + +RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018 + + + 5. Successful SELECT or EXAMINE command + + 6. CLOSE, UNSELECT [RFC3691], or failed SELECT or EXAMINE command + + 7. UNAUTHENTICATE command + + 8. LOGOUT command, server shutdown, or connection closed + +6. Formal Syntax + + The following syntax specification uses the Augmented Backus-Naur + Form (ABNF), as described in [RFC5234]. Amended terms are defined in + [RFC3501]. + + capability =/ "UNAUTHENTICATE" + + command-auth =/ "UNAUTHENTICATE" + + command-select =/ "UNAUTHENTICATE" + +7. IANA Considerations + + IANA has added the UNAUTHENTICATE capability to the "IMAP + Capabilities" registry. + +8. Security Considerations + + The original IMAP state machine was designed to allow a server- + implementation approach in which each IMAP authentication identity + matches an operating system identity and the server revokes all + administrative privilege once 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. This + extension is therefore 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 [RFC4314], active notifications [RFC5465], access to + per-user data such as flags, etc. + + + + + +Newman Standards Track [Page 7] + +RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018 + + + IMAP server systems are often deployed in a two-tier model where a + server-side IMAP proxy routes to an IMAP backend that handles all + connections for a subset of possible users. Some IMAP proxies enter + a pass-through mode after authentication. If enabled, the + UNAUTHENTICATE command would allow a client, on a subsequent + authentication, to bypass any security restrictions present in the + proxy layer but not in the backend server layer. 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 are associated with an administrative + identity. + +9. Privacy Considerations + + 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 reuse. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, + . + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + + + + + + +Newman Standards Track [Page 8] + +RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018 + + +10.2. Informative References + + [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, + DOI 10.17487/RFC2971, October 2000, + . + + [RFC3691] Melnikov, A., "Internet Message Access Protocol (IMAP) + UNSELECT command", RFC 3691, DOI 10.17487/RFC3691, + February 2004, . + + [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", + RFC 4314, DOI 10.17487/RFC4314, December 2005, + . + + [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, + DOI 10.17487/RFC4422, June 2006, + . + + [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for + Simple Authentication and Security Layer (SASL) Initial + Client Response", RFC 4959, DOI 10.17487/RFC4959, + September 2007, . + + [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, + DOI 10.17487/RFC4978, August 2007, + . + + [RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP + ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March + 2008, . + + [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last + SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March + 2008, . + + [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet + Message Access Protocol Internationalization", RFC 5255, + DOI 10.17487/RFC5255, June 2008, + . + + [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, + DOI 10.17487/RFC5267, July 2008, + . + + + + + + + +Newman Standards Track [Page 9] + +RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018 + + + [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, + DOI 10.17487/RFC5464, February 2009, + . + + [RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP + NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465, + February 2009, . + + [RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP + Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March + 2013, . + + [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag + Changes Resynchronization (CONDSTORE) and Quick Mailbox + Resynchronization (QRESYNC)", RFC 7162, + DOI 10.17487/RFC7162, May 2014, + . + + [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: + Use of Transport Layer Security (TLS) for Email Submission + and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, + . + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + + + + + + + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 10] + +RFC 8437 IMAP UNAUTHENTICATE for Connection Reuse August 2018 + + +Appendix A. Design Considerations + + The author deliberately chose 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. + The primary reason for this choice is that the code that transitions + from not authenticated state to authenticated state in a server is + often the most security-sensitive code, because 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 that + implementations provide a way to disable this extension. + +Acknowledgements + + Thanks to Fred Batty for implementing UNAUTHENTICATE and to Cyrus + Daboo for constructive suggestions to improve this document. + +Author's Address + + Chris Newman + Oracle + 440 E. Huntington Dr., Suite 400 + Arcadia, CA 91006 + United States of America + + Email: chris.newman@oracle.com + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 11] + -- cgit v1.2.3