idnits 2.17.1 draft-ietf-extra-imap-unauth-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2018) is 2215 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 (==), 2 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 Intended status: Standards Track March 27, 2018 5 Expires: September 28, 2018 7 IMAP UNAUTHENTICATE for Connection Reuse 8 draft-ietf-extra-imap-unauth-00 10 Abstract 12 This specification extends the Internet Message Access Protocol 13 (IMAP) to allow an administrative client to reuse the same IMAP 14 connection on behalf of multiple IMAP user identities. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 28, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 52 3. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 3 53 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.1. Stateful Extensions . . . . . . . . . . . . . . . . . . . 4 55 4.2. Client Certificates, SASL EXTERNAL and imaps . . . . . . 5 56 5. Revised State Machine . . . . . . . . . . . . . . . . . . . . 5 57 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 10.2. Informative References . . . . . . . . . . . . . . . . . 8 64 Appendix A. Design Considerations . . . . . . . . . . . . . . . 10 65 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 Modern IMAP [RFC3501] server deployments often have peer systems with 71 administrative privilege that perform actions on behalf of IMAP end- 72 users. For example, a voice mail gateway can use IMAP to store a 73 user's voicemail and mark that voicemail as \Seen when the user 74 listens to it via the phone interface. These systems can issue the 75 IMAP AUTHENTICATE command with administrative credentials to act on 76 behalf of other users. However, with the IMAP base specification, 77 these specialized IMAP clients must close the connection and create a 78 new connection for each user. For efficiency reasons, it is 79 desirable for these clients to reuse the same connection, 80 particularly if SSL has been negotiated. This specification proposes 81 the UNAUTHENTICATE command to achieve this goal. 83 The IMAP state machine described in section 3 of RFC 3501 does not 84 have a transition from authenticated or selected state to not 85 authenticated state. The UNAUTHENTICATE command adds a transition 86 from authenticated or selected state to not authenticated state. 88 2. Conventions Used in This Document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 3. UNAUTHENTICATE Command 96 Arguments: None 98 Responses: no specific response for this command 100 Result: OK - completed, now in not authenticated state 101 BAD - command unknown or arguments invalid 103 This command directs the server to reset all connection state, except 104 for state at the TLS [RFC5465] layer. Upon completion, the server 105 connection is placed in not authenticated state. This represents 106 transition 7 in the State Machine Diagram (Section 5). 108 If a mailbox was selected, the mailbox ceases to be selected but no 109 expunge event is generated. If a SASL [RFC4422] security layer was 110 active, it terminates immediately after the server sends the CRLF 111 following the OK response. For the client, it terminates immediately 112 after the CRLF following the UNAUTHENTICATE command. 114 After sending this command, the client is free to issue a new 115 AUTHENTICATE or LOGIN command as permitted based on the server's 116 capabilities. If no SASL security layer was active, the client is 117 permitted to pipeline the UNAUTHENTICATE command with a subsequent 118 AUTHENTICATE command. If the IMAP server also advertises SASL-IR 119 [RFC4959], this permits an administrative client to re-authenticate 120 in one round trip. Because of this pipelining optimization, a server 121 advertising UNAUTHENTICATE is not permitted to respond to the 122 UNAUTHENTICATE command with a NO response if it is unable to reset 123 state associated with the connection. Servers MAY close the 124 connection with an untagged BYE response if this preferably rare 125 situation occurs. 127 Servers MAY choose to advertise the UNAUTHENTICATE capability only 128 after authentication has completed. As a result, clients need to 129 issue an IMAP CAPABILITY command after authentication in order to 130 determine the availability of UNAUTHENTICATE. 132 The IMAP ID [RFC2971] command provides properties about the client 133 primarily for use in server log or audit files. Because IMAP ID is 134 not related to application authentication or user identity in any way 135 and caching it for the duration of the client connection can be 136 useful, the interaction between IMAP ID and the UNAUTHENTICATE 137 command is implementation defined. 139 4. Interactions 141 This section describes interactions between this extension and other 142 IMAP extensions or usage models. 144 4.1. Stateful Extensions 146 This lists some IMAP extensions that have connection state that MUST 147 be reset if both the specified extension is advertised and the 148 UNAUTHENTICATE command is advertised and used. This list may not be 149 complete; the requirement to reset connection state applies to all 150 current and future extensions except STARTTLS and ID. 152 o Cached identity information, such a group memberships, that are 153 used to evaluate access control lists [RFC4314] MUST be reset. 155 o CONDSTORE servers [RFC7162] MUST behave as if no CONDSTORE 156 enabling command had been issued after an UNAUTHENTICATE command 157 is issued. 159 o If IMAP COMPRESS [RFC4978] is active, the compression layer 160 terminates after the server sends the CRLF following the OK 161 response and after the client sends the CRLF following the 162 UNAUTHENTICATE command. In the event it matters, the compression 163 layer terminates before a SASL layer terminates. 165 o Any extensions enabled by the IMAP ENABLE [RFC5161] command cease 166 to be enabled when the UNAUTHENTICATE command is issued. This 167 includes, but is not limited to, CONDSTORE [RFC7162], QRESYNC 168 [RFC7162], METADATA [RFC5464], METADATA-SERVER [RFC5464] and 169 UTF8=ACCEPT [RFC6855]. 171 o A server advertising SEARCHRES [RFC5182] discards any saved search 172 results so that '$' subsequently represents the empty set. 174 o A server advertising LANGUAGE [RFC5255] will revert to the 175 "i-default" language. 177 o When a server advertises CONTEXT=SEARCH or CONTEXT=SORT [RFC5267], 178 the UNAUTHENTICATE command includes an implicit CANCELUPDATE for 179 all server contexts. 181 o When a server advertises NOTIFY [RFC5465], the UNAUTHENTICATE 182 command cancels server state related to the NOTIFY command and 183 reverts to default IMAP base-specification behavior for 184 notifications. 186 4.2. Client Certificates, SASL EXTERNAL and imaps 188 When a TLS [RFC5246] security layer is negotiated either via the 189 STARTTLS command or use of the imaps port [RFC6186], IMAP servers MAY 190 be configured to request a client certificate and IMAP clients MAY 191 provide one. Client credentials at the TLS layer do not normally 192 impact the application layer without use of the SASL EXTERNAL 193 mechanism [RFC4422] in an IMAP AUTHENTICATE command that directs the 194 server to use the provided client certificate to authenticate as the 195 specified IMAP user. The UNAUTHENTICATE command breaks any 196 application-level binding of the TLS client credentials but does not 197 discard the client credentials. As a result, an administrative 198 client may use a client certificate with administrative privilege to 199 act on behalf of multiple IMAP users in the same connection via the 200 EXTERNAL mechanism and the UNAUTHENTICATE command. 202 Some server implementations using the imaps port will request and use 203 a TLS client certificate to authenticate immediately as the default 204 IMAP identity associated with that certificate. These 205 implementations indicate this behavior by using the PREAUTH greeting 206 as indicated by transition 2 in the State Machine Diagram 207 (Section 5). As a result, TLS client certificates can not be used 208 for administrative proxy authentication with the imaps port unless 209 the UNAUTHENTICATE command is also advertised. In that case, an 210 administrative client can respond to the PREAUTH greeting with an 211 UNAUTHENTICATE command and then issue an AUTHENTICATE EXTERNAL 212 command. 214 5. Revised State Machine 215 +----------------------+ 216 |connection established| 217 +----------------------+ 218 || 219 \/ 220 +--------------------------------------+ 221 | server greeting | 222 +--------------------------------------+ 223 || (1) || (2) || (3) 224 \/ || || 225 +-----------------+ || || 226 |Not Authenticated|<===||=========++ || 227 +-----------------+ || (7) || || 228 || (8) || (4) || || || 229 || \/ \/ || || 230 || +----------------+ || || 231 || | |========++ || 232 || | Authenticated |<=++ || || 233 || +----------------+ || || || 234 || || (8) || (5) ||(6) || || 235 || || \/ || || || 236 || || +--------+ || || || 237 || || |Selected|==++ || || 238 || || | |========++ || 239 || || +--------+ || 240 || || || (8) || 241 \/ \/ \/ \/ 242 +--------------------------------------+ 243 | Logout | 244 +--------------------------------------+ 245 || 246 \/ 247 +-------------------------------+ 248 |both sides close the connection| 249 +-------------------------------+ 251 Revised IMAP state machine transitions: 253 1. connection without pre-authentication (OK greeting) 255 2. pre-authenticated connection (PREAUTH greeting) 257 3. rejected connection (BYE greeting) 259 4. successful LOGIN or AUTHENTICATE command 261 5. successful SELECT or EXAMINE command 262 6. CLOSE, UNSELECT [RFC3691] or failed SELECT or EXAMINE command 264 7. UNAUTHENTICATE command 266 8. LOGOUT command, server shutdown, or connection closed 268 6. Formal Syntax 270 The following syntax specification uses the Augmented Backus-Naur 271 Form (ABNF) as described in [RFC5234]. Amended terms are defined in 272 [RFC3501]. 274 capability =/ "UNAUTHENTICATE" 276 command-auth =/ "UNAUTHENTICATE" 278 command-select =/ "UNAUTHENTICATE" 280 7. IANA Considerations 282 The IANA shall add the UNAUTHENTICATE capability to the IMAP4 283 Capabilities Registry. 285 8. Security Considerations 287 The original IMAP state machine was designed to allow a server 288 implementation approach where each IMAP authentication identity 289 matches an operating system identity and the server revokes all 290 administrative privilege onces authentication completes. This 291 extension is not compatible with that implementation approach. 292 However, that approach has significant performance costs on Unix 293 systems, and this extension is designed for environments where 294 efficiency is a relatively high priority deployment goal. So this 295 extension is appropriate for some deployments but may not be 296 appropriate for the most security sensitive environments. 298 IMAP server implementations are complicated and can retain a lot of 299 state related to an authenticated user. Server implementers need to 300 take care to reset all server state such that authentication as a 301 subsequent user does not inherit any data or privileges from the 302 previous user. State data associated with a user can include cached 303 identity information such as group membership used to evaluate access 304 control lists [RFC4314], active notifications [RFC5465], access to 305 per-user data such as flags, etc. 307 IMAP server systems are often deployed in a two-tier model where a 308 server-side IMAP proxy routes to an IMAP back-end which handles all 309 connections for a subset of possible users. Some IMAP proxies enter 310 a pass-through mode after authentication. The UNAUTHENTICATE 311 command, if enabled, would allow a client to bypass any security 312 restrictions present in the proxy layer but not in the back-end 313 server layer on a subsequent authentication. As a result, IMAP 314 server implementations of this extension MUST provide a way to 315 disable it when it is not needed. Use of an IMAP proxy that 316 processes the UNAUTHENTICATE command at the proxy layer eliminates 317 this concern. Another option to mitigate this concern is for servers 318 to only enable the UNAUTHENTICATE extension if the supplied 319 authentication credentials were associated with an administrative 320 identity. 322 9. Privacy Considerations 324 For the most part, this extension will have no impact on the privacy 325 considerations already present in an IMAP implementation. However, 326 if this extension were used between data centers, it could improve 327 end-user privacy by increasing the difficultly of traffic analysis 328 due to connection re-use. 330 10. References 332 10.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 340 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 341 . 343 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 344 Specifications: ABNF", STD 68, RFC 5234, 345 DOI 10.17487/RFC5234, January 2008, 346 . 348 10.2. Informative References 350 [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, 351 DOI 10.17487/RFC2971, October 2000, 352 . 354 [RFC3691] Melnikov, A., "Internet Message Access Protocol (IMAP) 355 UNSELECT command", RFC 3691, DOI 10.17487/RFC3691, 356 February 2004, . 358 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 359 RFC 4314, DOI 10.17487/RFC4314, December 2005, 360 . 362 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 363 Authentication and Security Layer (SASL)", RFC 4422, 364 DOI 10.17487/RFC4422, June 2006, 365 . 367 [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for 368 Simple Authentication and Security Layer (SASL) Initial 369 Client Response", RFC 4959, DOI 10.17487/RFC4959, 370 September 2007, . 372 [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, 373 DOI 10.17487/RFC4978, August 2007, 374 . 376 [RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP 377 ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March 378 2008, . 380 [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last 381 SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March 382 2008, . 384 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 385 (TLS) Protocol Version 1.2", RFC 5246, 386 DOI 10.17487/RFC5246, August 2008, 387 . 389 [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 390 Message Access Protocol Internationalization", RFC 5255, 391 DOI 10.17487/RFC5255, June 2008, 392 . 394 [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, 395 DOI 10.17487/RFC5267, July 2008, 396 . 398 [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, 399 DOI 10.17487/RFC5464, February 2009, 400 . 402 [RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP 403 NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465, 404 February 2009, . 406 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 407 Submission/Access Services", RFC 6186, 408 DOI 10.17487/RFC6186, March 2011, 409 . 411 [RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP 412 Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March 413 2013, . 415 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag 416 Changes Resynchronization (CONDSTORE) and Quick Mailbox 417 Resynchronization (QRESYNC)", RFC 7162, 418 DOI 10.17487/RFC7162, May 2014, 419 . 421 Appendix A. Design Considerations 423 The author deliberately choose to add a separate UNAUTHENTICATE 424 command instead of allowing the LOGIN or AUTHENTICATE commands to be 425 issued when the connection is in a state other than unauthenticated 426 state. The primary reason for this choice is because the code that 427 transitions from not authenticated state to authenticated state in a 428 server is often the most security sensitive code as it needs to 429 assume and handle unconditionally hostile attackers. That sensitive 430 code is simpler if it only handles a single server state 431 (unauthenticated) and the state transition is as simple as possible. 432 Smaller and simpler code is easier to audit and write in a secure 433 way. 435 A secondary reason to have a separate command is that it is simpler 436 to enable or disable the feature with that design. See the 437 discussion in the security considerations section recommending 438 implementations provide a way to disable this extension. 440 Appendix B. Acknowledgements 442 Thanks to Fred Batty for implementing UNAUTHENTICATE, and to Cyrus 443 Daboo for constructive suggestions to improve this draft. 445 Author's Address 447 Chris Newman 448 Oracle 449 440 E. Huntington Dr., Suite 400 450 Arcadia, CA 91006 451 US 453 Email: chris.newman@oracle.com