idnits 2.17.00 (12 Aug 2021) /tmp/idnits39224/draft-ietf-extra-imap-unauth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3501, updated by this document, for RFC5378 checks: 1997-09-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 7, 2018) is 1437 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet-Draft Oracle 4 Updates: 3501 (if approved) June 7, 2018 5 Intended status: Standards Track 6 Expires: December 9, 2018 8 IMAP UNAUTHENTICATE for Connection Reuse 9 draft-ietf-extra-imap-unauth-01 11 Abstract 13 This specification extends the Internet Message Access Protocol 14 (IMAP) to allow an administrative client to reuse the same IMAP 15 connection on behalf of multiple IMAP user identities. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 9, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 53 3. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 3 54 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. Stateful Extensions . . . . . . . . . . . . . . . . . . . 4 56 4.2. Client Certificates, SASL EXTERNAL and imaps . . . . . . 5 57 5. Revised State Machine . . . . . . . . . . . . . . . . . . . . 5 58 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 10.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Appendix A. Design Considerations . . . . . . . . . . . . . . . 10 66 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 Modern IMAP [RFC3501] server deployments often have peer systems with 72 administrative privilege that perform actions on behalf of IMAP end- 73 users. For example, a voice mail gateway can use IMAP to store a 74 user's voicemail and mark that voicemail as \Seen when the user 75 listens to it via the phone interface. These systems can issue the 76 IMAP AUTHENTICATE command with administrative credentials to act on 77 behalf of other users. However, with the IMAP base specification, 78 these specialized IMAP clients must close the connection and create a 79 new connection for each user. For efficiency reasons, it is 80 desirable for these clients to reuse the same connection, 81 particularly if SSL has been negotiated. This specification proposes 82 the UNAUTHENTICATE command to achieve this goal. 84 The IMAP state machine described in section 3 of RFC 3501 does not 85 have a transition from authenticated or selected state to not 86 authenticated state. The UNAUTHENTICATE command adds a transition 87 from authenticated or selected state to not authenticated state. 89 2. Conventions Used in This Document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 3. UNAUTHENTICATE Command 99 Arguments: None 101 Responses: no specific response for this command 103 Result: OK - completed, now in not authenticated state 104 BAD - command unknown or arguments invalid 106 This command directs the server to reset all connection state, except 107 for state at the TLS [RFC5246] layer. Upon completion, the server 108 connection is placed in not authenticated state. This represents 109 transition 7 in the State Machine Diagram (Section 5). 111 If a mailbox was selected, the mailbox ceases to be selected but no 112 expunge event is generated. If a SASL [RFC4422] security layer was 113 active, the server terminates its outgoing security layer immediately 114 after sending the CRLF following the OK response. The client's 115 outgoing security layer terminates immediately after the CRLF 116 following the UNAUTHENTICATE command. Note that a BAD response only 117 occurs if UNAUTHENTICATE is issued in an invalid state, is not 118 advertised by the server, or does not follow the command syntax in 119 the specification, and a NO response is not permitted. As a result, 120 specification-compliant implementations will interoperate across 121 security layer termination. 123 After sending this command, the client is free to issue a new 124 AUTHENTICATE or LOGIN command as permitted based on the server's 125 capabilities. If no SASL security layer was active, the client is 126 permitted to pipeline the UNAUTHENTICATE command with a subsequent 127 AUTHENTICATE command. If the IMAP server also advertises SASL-IR 128 [RFC4959], this permits an administrative client to re-authenticate 129 in one round trip. Because of this pipelining optimization, a server 130 advertising UNAUTHENTICATE is not permitted to respond to the 131 UNAUTHENTICATE command with a NO response if it is unable to reset 132 state associated with the connection. Servers MAY close the 133 connection with an untagged BYE response if this preferably rare 134 situation occurs. 136 Servers MAY choose to advertise the UNAUTHENTICATE capability only 137 after authentication has completed. As a result, clients may need to 138 issue an IMAP CAPABILITY command after authentication in order to 139 determine the availability of UNAUTHENTICATE. 141 The IMAP ID [RFC2971] command provides properties about the client 142 primarily for use in server log or audit files. Because IMAP ID is 143 not related to application authentication or user identity in any way 144 and caching it for the duration of the client connection can be 145 useful, the interaction between IMAP ID and the UNAUTHENTICATE 146 command is implementation defined. 148 4. Interactions 150 This section describes interactions between this extension and other 151 IMAP extensions or usage models. 153 4.1. Stateful Extensions 155 The connection state for the following list of IMAP extensions MUST 156 be reset if both the specified extension is advertised and the 157 UNAUTHENTICATE command is advertised and used. This list may not be 158 complete; the requirement to reset connection state applies to all 159 current and future extensions except STARTTLS and ID. Additional 160 requirements apply to specific stateful extensions as follows: 162 o Cached identity information, such a group memberships, that are 163 used to evaluate access control lists [RFC4314] MUST be reset. 165 o CONDSTORE servers [RFC7162] MUST behave as if no CONDSTORE 166 enabling command had been issued after an UNAUTHENTICATE command 167 is issued. 169 o If IMAP COMPRESS [RFC4978] is active, the server terminates its 170 outgoing compression layer after it sends the CRLF following the 171 OK response. The client terminates its outgoing compression layer 172 after the CRLF following the UNAUTHENTICATE command. In the event 173 it matters, the compression layer terminates before a SASL layer 174 terminates. 176 o Any extensions enabled by the IMAP ENABLE [RFC5161] command cease 177 to be enabled when the UNAUTHENTICATE command is issued. This 178 includes, but is not limited to, CONDSTORE [RFC7162], QRESYNC 179 [RFC7162], METADATA [RFC5464], METADATA-SERVER [RFC5464] and 180 UTF8=ACCEPT [RFC6855]. 182 o A server advertising SEARCHRES [RFC5182] discards any saved search 183 results so that '$' subsequently represents the empty set. 185 o A server advertising LANGUAGE [RFC5255] will revert to the 186 "i-default" language. 188 o When a server advertises CONTEXT=SEARCH or CONTEXT=SORT [RFC5267], 189 the UNAUTHENTICATE command includes an implicit CANCELUPDATE for 190 all server contexts. 192 o When a server advertises NOTIFY [RFC5465], the UNAUTHENTICATE 193 command cancels server state related to the NOTIFY command and 194 reverts to default IMAP base-specification behavior for 195 notifications. 197 4.2. Client Certificates, SASL EXTERNAL and imaps 199 When a TLS [RFC5246] security layer is negotiated either via the 200 STARTTLS command or use of the imaps port [RFC8314], IMAP servers may 201 be configured to request a client certificate and IMAP clients may 202 provide one. Client credentials at the TLS layer do not normally 203 impact the application layer without use of the SASL EXTERNAL 204 mechanism [RFC4422] in an IMAP AUTHENTICATE command that directs the 205 server to use the provided client certificate to authenticate as the 206 specified IMAP user. The UNAUTHENTICATE command breaks any 207 application-level binding of the TLS client credentials but does not 208 discard the client credentials. As a result, an administrative 209 client may use a client certificate with administrative privilege to 210 act on behalf of multiple IMAP users in the same connection via the 211 EXTERNAL mechanism and the UNAUTHENTICATE command. 213 Some server implementations using the imaps port will request and use 214 a TLS client certificate to authenticate immediately as the default 215 IMAP identity associated with that certificate. These 216 implementations indicate this behavior by using the PREAUTH greeting 217 as indicated by transition 2 in the State Machine Diagram 218 (Section 5). As a result, TLS client certificates can not be used 219 for administrative proxy authentication with the imaps port unless 220 the UNAUTHENTICATE command is also advertised. In that case, an 221 administrative client can respond to the PREAUTH greeting with an 222 UNAUTHENTICATE command and then issue an AUTHENTICATE EXTERNAL 223 command. 225 5. Revised State Machine 226 +----------------------+ 227 |connection established| 228 +----------------------+ 229 || 230 \/ 231 +--------------------------------------+ 232 | server greeting | 233 +--------------------------------------+ 234 || (1) || (2) || (3) 235 \/ || || 236 +-----------------+ || || 237 |Not Authenticated|<===||=========++ || 238 +-----------------+ || (7) || || 239 || (8) || (4) || || || 240 || \/ \/ || || 241 || +----------------+ || || 242 || | |========++ || 243 || | Authenticated |<=++ || || 244 || +----------------+ || || || 245 || || (8) || (5) ||(6) || || 246 || || \/ || || || 247 || || +--------+ || || || 248 || || |Selected|==++ || || 249 || || | |========++ || 250 || || +--------+ || 251 || || || (8) || 252 \/ \/ \/ \/ 253 +--------------------------------------+ 254 | Logout | 255 +--------------------------------------+ 256 || 257 \/ 258 +-------------------------------+ 259 |both sides close the connection| 260 +-------------------------------+ 262 Revised IMAP state machine transitions: 264 1. connection without pre-authentication (OK greeting) 266 2. pre-authenticated connection (PREAUTH greeting) 268 3. rejected connection (BYE greeting) 270 4. successful LOGIN or AUTHENTICATE command 272 5. successful SELECT or EXAMINE command 273 6. CLOSE, UNSELECT [RFC3691] or failed SELECT or EXAMINE command 275 7. UNAUTHENTICATE command 277 8. LOGOUT command, server shutdown, or connection closed 279 6. Formal Syntax 281 The following syntax specification uses the Augmented Backus-Naur 282 Form (ABNF) as described in [RFC5234]. Amended terms are defined in 283 [RFC3501]. 285 capability =/ "UNAUTHENTICATE" 287 command-auth =/ "UNAUTHENTICATE" 289 command-select =/ "UNAUTHENTICATE" 291 7. IANA Considerations 293 The IANA shall add the UNAUTHENTICATE capability to the IMAP4 294 Capabilities Registry. 296 8. Security Considerations 298 The original IMAP state machine was designed to allow a server 299 implementation approach where each IMAP authentication identity 300 matches an operating system identity and the server revokes all 301 administrative privilege once authentication completes. This 302 extension is not compatible with that implementation approach. 303 However, that approach has significant performance costs on Unix 304 systems, and this extension is designed for environments where 305 efficiency is a relatively high priority deployment goal. So this 306 extension is appropriate for some deployments but may not be 307 appropriate for the most security sensitive environments. 309 IMAP server implementations are complicated and can retain a lot of 310 state related to an authenticated user. Server implementers need to 311 take care to reset all server state such that authentication as a 312 subsequent user does not inherit any data or privileges from the 313 previous user. State data associated with a user can include cached 314 identity information such as group membership used to evaluate access 315 control lists [RFC4314], active notifications [RFC5465], access to 316 per-user data such as flags, etc. 318 IMAP server systems are often deployed in a two-tier model where a 319 server-side IMAP proxy routes to an IMAP back-end which handles all 320 connections for a subset of possible users. Some IMAP proxies enter 321 a pass-through mode after authentication. The UNAUTHENTICATE 322 command, if enabled, would allow a client to bypass any security 323 restrictions present in the proxy layer but not in the back-end 324 server layer on a subsequent authentication. As a result, IMAP 325 server implementations of this extension MUST provide a way to 326 disable it when it is not needed. Use of an IMAP proxy that 327 processes the UNAUTHENTICATE command at the proxy layer eliminates 328 this concern. Another option to mitigate this concern is for servers 329 to only enable the UNAUTHENTICATE extension if the supplied 330 authentication credentials were associated with an administrative 331 identity. 333 9. Privacy Considerations 335 For the most part, this extension will have no impact on the privacy 336 considerations already present in an IMAP implementation. However, 337 if this extension were used between data centers, it could improve 338 end-user privacy by increasing the difficultly of traffic analysis 339 due to connection re-use. 341 10. References 343 10.1. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 351 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 352 . 354 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 355 Specifications: ABNF", STD 68, RFC 5234, 356 DOI 10.17487/RFC5234, January 2008, 357 . 359 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 360 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 361 May 2017, . 363 10.2. Informative References 365 [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, 366 DOI 10.17487/RFC2971, October 2000, 367 . 369 [RFC3691] Melnikov, A., "Internet Message Access Protocol (IMAP) 370 UNSELECT command", RFC 3691, DOI 10.17487/RFC3691, 371 February 2004, . 373 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 374 RFC 4314, DOI 10.17487/RFC4314, December 2005, 375 . 377 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 378 Authentication and Security Layer (SASL)", RFC 4422, 379 DOI 10.17487/RFC4422, June 2006, 380 . 382 [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for 383 Simple Authentication and Security Layer (SASL) Initial 384 Client Response", RFC 4959, DOI 10.17487/RFC4959, 385 September 2007, . 387 [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, 388 DOI 10.17487/RFC4978, August 2007, 389 . 391 [RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP 392 ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March 393 2008, . 395 [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last 396 SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March 397 2008, . 399 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 400 (TLS) Protocol Version 1.2", RFC 5246, 401 DOI 10.17487/RFC5246, August 2008, 402 . 404 [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 405 Message Access Protocol Internationalization", RFC 5255, 406 DOI 10.17487/RFC5255, June 2008, 407 . 409 [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, 410 DOI 10.17487/RFC5267, July 2008, 411 . 413 [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, 414 DOI 10.17487/RFC5464, February 2009, 415 . 417 [RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP 418 NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465, 419 February 2009, . 421 [RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP 422 Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March 423 2013, . 425 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag 426 Changes Resynchronization (CONDSTORE) and Quick Mailbox 427 Resynchronization (QRESYNC)", RFC 7162, 428 DOI 10.17487/RFC7162, May 2014, 429 . 431 [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: 432 Use of Transport Layer Security (TLS) for Email Submission 433 and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, 434 . 436 Appendix A. Design Considerations 438 The author deliberately choose to add a separate UNAUTHENTICATE 439 command instead of allowing the LOGIN or AUTHENTICATE commands to be 440 issued when the connection is in a state other than unauthenticated 441 state. The primary reason for this choice is because the code that 442 transitions from not authenticated state to authenticated state in a 443 server is often the most security sensitive code as it needs to 444 assume and handle unconditionally hostile attackers. That sensitive 445 code is simpler if it only handles a single server state 446 (unauthenticated) and the state transition is as simple as possible. 447 Smaller and simpler code is easier to audit and write in a secure 448 way. 450 A secondary reason to have a separate command is that it is simpler 451 to enable or disable the feature with that design. See the 452 discussion in the security considerations section recommending 453 implementations provide a way to disable this extension. 455 Appendix B. Acknowledgements 457 Thanks to Fred Batty for implementing UNAUTHENTICATE, and to Cyrus 458 Daboo for constructive suggestions to improve this draft. 460 Author's Address 461 Chris Newman 462 Oracle 463 440 E. Huntington Dr., Suite 400 464 Arcadia, CA 91006 465 US 467 Email: chris.newman@oracle.com