--- 1/draft-ietf-extra-imap-unauth-00.txt 2018-06-07 15:13:13.244436304 -0700 +++ 2/draft-ietf-extra-imap-unauth-01.txt 2018-06-07 15:13:13.268436890 -0700 @@ -1,18 +1,19 @@ Network Working Group C. Newman Internet-Draft Oracle -Intended status: Standards Track March 27, 2018 -Expires: September 28, 2018 +Updates: 3501 (if approved) June 7, 2018 +Intended status: Standards Track +Expires: December 9, 2018 IMAP UNAUTHENTICATE for Connection Reuse - draft-ietf-extra-imap-unauth-00 + draft-ietf-extra-imap-unauth-01 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 Internet-Draft is submitted in full conformance with the @@ -21,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 28, 2018. + This Internet-Draft will expire on December 9, 2018. 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 @@ -81,93 +82,103 @@ 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. 2. Conventions Used in This Document 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 [RFC2119]. + "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. 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 state at the TLS [RFC5465] layer. Upon completion, the server + for state at the TLS [RFC5246] 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 SASL [RFC4422] 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. + 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, and 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 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 + 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. 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 implementation defined. 4. Interactions This section describes interactions between this extension and other IMAP extensions or usage models. 4.1. Stateful Extensions - This lists some IMAP extensions that have connection state that MUST + The connection state for the following list of IMAP extensions 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. + current and future extensions except STARTTLS and ID. Additional + requirements apply to specific stateful extensions as follows: o Cached identity information, such a group memberships, that are used to evaluate access control lists [RFC4314] MUST be reset. o CONDSTORE servers [RFC7162] MUST behave as if no CONDSTORE enabling command had been issued after an UNAUTHENTICATE command is issued. - o If IMAP COMPRESS [RFC4978] 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. + 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. In the event + 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. @@ -179,22 +190,22 @@ all server contexts. o When a server advertises NOTIFY [RFC5465], the UNAUTHENTICATE command cancels 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 [RFC5246] security layer is negotiated either via the - STARTTLS command or use of the imaps port [RFC6186], IMAP servers MAY - be configured to request a client certificate and IMAP clients MAY + STARTTLS command or use of 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 without use of the SASL EXTERNAL mechanism [RFC4422] 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. @@ -280,21 +291,21 @@ 7. IANA Considerations The IANA shall add the UNAUTHENTICATE capability to the IMAP4 Capabilities Registry. 8. Security Considerations 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 + 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. 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 @@ -327,103 +338,107 @@ end-user privacy by increasing the difficultly of traffic analysis due to connection re-use. 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, . 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, . + 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, . + 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, . + 2008, . [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March - 2008, . + 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 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, - . + . [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, . - - [RFC6186] Daboo, C., "Use of SRV Records for Locating Email - Submission/Access Services", RFC 6186, - DOI 10.17487/RFC6186, March 2011, - . + 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, . + 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, + . Appendix A. Design Considerations 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