draft-ietf-extra-imap-unauth-00.txt   draft-ietf-extra-imap-unauth-01.txt 
Network Working Group C. Newman Network Working Group C. Newman
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track March 27, 2018 Updates: 3501 (if approved) June 7, 2018
Expires: September 28, 2018 Intended status: Standards Track
Expires: December 9, 2018
IMAP UNAUTHENTICATE for Connection Reuse IMAP UNAUTHENTICATE for Connection Reuse
draft-ietf-extra-imap-unauth-00 draft-ietf-extra-imap-unauth-01
Abstract Abstract
This specification extends the Internet Message Access Protocol This specification extends the Internet Message Access Protocol
(IMAP) to allow an administrative client to reuse the same IMAP (IMAP) to allow an administrative client to reuse the same IMAP
connection on behalf of multiple IMAP user identities. connection on behalf of multiple IMAP user identities.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 48
the UNAUTHENTICATE command to achieve this goal. the UNAUTHENTICATE command to achieve this goal.
The IMAP state machine described in section 3 of RFC 3501 does not The IMAP state machine described in section 3 of RFC 3501 does not
have a transition from authenticated or selected state to not have a transition from authenticated or selected state to not
authenticated state. The UNAUTHENTICATE command adds a transition authenticated state. The UNAUTHENTICATE command adds a transition
from authenticated or selected state to not authenticated state. from authenticated or selected state to not authenticated state.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "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 3. UNAUTHENTICATE Command
Arguments: None Arguments: None
Responses: no specific response for this command Responses: no specific response for this command
Result: OK - completed, now in not authenticated state Result: OK - completed, now in not authenticated state
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
This command directs the server to reset all connection state, except 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 connection is placed in not authenticated state. This represents
transition 7 in the State Machine Diagram (Section 5). transition 7 in the State Machine Diagram (Section 5).
If a mailbox was selected, the mailbox ceases to be selected but no If a mailbox was selected, the mailbox ceases to be selected but no
expunge event is generated. If a SASL [RFC4422] security layer was expunge event is generated. If a SASL [RFC4422] security layer was
active, it terminates immediately after the server sends the CRLF active, the server terminates its outgoing security layer immediately
following the OK response. For the client, it terminates immediately after sending the CRLF following the OK response. The client's
after the CRLF following the UNAUTHENTICATE command. 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 After sending this command, the client is free to issue a new
AUTHENTICATE or LOGIN command as permitted based on the server's AUTHENTICATE or LOGIN command as permitted based on the server's
capabilities. If no SASL security layer was active, the client is capabilities. If no SASL security layer was active, the client is
permitted to pipeline the UNAUTHENTICATE command with a subsequent permitted to pipeline the UNAUTHENTICATE command with a subsequent
AUTHENTICATE command. If the IMAP server also advertises SASL-IR AUTHENTICATE command. If the IMAP server also advertises SASL-IR
[RFC4959], this permits an administrative client to re-authenticate [RFC4959], this permits an administrative client to re-authenticate
in one round trip. Because of this pipelining optimization, a server in one round trip. Because of this pipelining optimization, a server
advertising UNAUTHENTICATE is not permitted to respond to the advertising UNAUTHENTICATE is not permitted to respond to the
UNAUTHENTICATE command with a NO response if it is unable to reset UNAUTHENTICATE command with a NO response if it is unable to reset
state associated with the connection. Servers MAY close the state associated with the connection. Servers MAY close the
connection with an untagged BYE response if this preferably rare connection with an untagged BYE response if this preferably rare
situation occurs. situation occurs.
Servers MAY choose to advertise the UNAUTHENTICATE capability only 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 issue an IMAP CAPABILITY command after authentication in order to
determine the availability of UNAUTHENTICATE. determine the availability of UNAUTHENTICATE.
The IMAP ID [RFC2971] command provides properties about the client The IMAP ID [RFC2971] command provides properties about the client
primarily for use in server log or audit files. Because IMAP ID is primarily for use in server log or audit files. Because IMAP ID is
not related to application authentication or user identity in any way not related to application authentication or user identity in any way
and caching it for the duration of the client connection can be and caching it for the duration of the client connection can be
useful, the interaction between IMAP ID and the UNAUTHENTICATE useful, the interaction between IMAP ID and the UNAUTHENTICATE
command is implementation defined. command is implementation defined.
4. Interactions 4. Interactions
This section describes interactions between this extension and other This section describes interactions between this extension and other
IMAP extensions or usage models. IMAP extensions or usage models.
4.1. Stateful Extensions 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 be reset if both the specified extension is advertised and the
UNAUTHENTICATE command is advertised and used. This list may not be UNAUTHENTICATE command is advertised and used. This list may not be
complete; the requirement to reset connection state applies to all 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 o Cached identity information, such a group memberships, that are
used to evaluate access control lists [RFC4314] MUST be reset. used to evaluate access control lists [RFC4314] MUST be reset.
o CONDSTORE servers [RFC7162] MUST behave as if no CONDSTORE o CONDSTORE servers [RFC7162] MUST behave as if no CONDSTORE
enabling command had been issued after an UNAUTHENTICATE command enabling command had been issued after an UNAUTHENTICATE command
is issued. is issued.
o If IMAP COMPRESS [RFC4978] is active, the compression layer o If IMAP COMPRESS [RFC4978] is active, the server terminates its
terminates after the server sends the CRLF following the OK outgoing compression layer after it sends the CRLF following the
response and after the client sends the CRLF following the OK response. The client terminates its outgoing compression layer
UNAUTHENTICATE command. In the event it matters, the compression after the CRLF following the UNAUTHENTICATE command. In the event
layer terminates before a SASL layer terminates. it matters, the compression layer terminates before a SASL layer
terminates.
o Any extensions enabled by the IMAP ENABLE [RFC5161] command cease o Any extensions enabled by the IMAP ENABLE [RFC5161] command cease
to be enabled when the UNAUTHENTICATE command is issued. This to be enabled when the UNAUTHENTICATE command is issued. This
includes, but is not limited to, CONDSTORE [RFC7162], QRESYNC includes, but is not limited to, CONDSTORE [RFC7162], QRESYNC
[RFC7162], METADATA [RFC5464], METADATA-SERVER [RFC5464] and [RFC7162], METADATA [RFC5464], METADATA-SERVER [RFC5464] and
UTF8=ACCEPT [RFC6855]. UTF8=ACCEPT [RFC6855].
o A server advertising SEARCHRES [RFC5182] discards any saved search o A server advertising SEARCHRES [RFC5182] discards any saved search
results so that '$' subsequently represents the empty set. results so that '$' subsequently represents the empty set.
skipping to change at page 5, line 8 skipping to change at page 5, line 13
all server contexts. all server contexts.
o When a server advertises NOTIFY [RFC5465], the UNAUTHENTICATE o When a server advertises NOTIFY [RFC5465], the UNAUTHENTICATE
command cancels server state related to the NOTIFY command and command cancels server state related to the NOTIFY command and
reverts to default IMAP base-specification behavior for reverts to default IMAP base-specification behavior for
notifications. notifications.
4.2. Client Certificates, SASL EXTERNAL and imaps 4.2. Client Certificates, SASL EXTERNAL and imaps
When a TLS [RFC5246] security layer is negotiated either via the When a TLS [RFC5246] security layer is negotiated either via the
STARTTLS command or use of the imaps port [RFC6186], IMAP servers MAY STARTTLS command or use of the imaps port [RFC8314], IMAP servers may
be configured to request a client certificate and IMAP clients MAY be configured to request a client certificate and IMAP clients may
provide one. Client credentials at the TLS layer do not normally provide one. Client credentials at the TLS layer do not normally
impact the application layer without use of the SASL EXTERNAL impact the application layer without use of the SASL EXTERNAL
mechanism [RFC4422] in an IMAP AUTHENTICATE command that directs the mechanism [RFC4422] in an IMAP AUTHENTICATE command that directs the
server to use the provided client certificate to authenticate as the server to use the provided client certificate to authenticate as the
specified IMAP user. The UNAUTHENTICATE command breaks any specified IMAP user. The UNAUTHENTICATE command breaks any
application-level binding of the TLS client credentials but does not application-level binding of the TLS client credentials but does not
discard the client credentials. As a result, an administrative discard the client credentials. As a result, an administrative
client may use a client certificate with administrative privilege to client may use a client certificate with administrative privilege to
act on behalf of multiple IMAP users in the same connection via the act on behalf of multiple IMAP users in the same connection via the
EXTERNAL mechanism and the UNAUTHENTICATE command. EXTERNAL mechanism and the UNAUTHENTICATE command.
skipping to change at page 7, line 32 skipping to change at page 7, line 32
7. IANA Considerations 7. IANA Considerations
The IANA shall add the UNAUTHENTICATE capability to the IMAP4 The IANA shall add the UNAUTHENTICATE capability to the IMAP4
Capabilities Registry. Capabilities Registry.
8. Security Considerations 8. Security Considerations
The original IMAP state machine was designed to allow a server The original IMAP state machine was designed to allow a server
implementation approach where each IMAP authentication identity implementation approach where each IMAP authentication identity
matches an operating system identity and the server revokes all 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. extension is not compatible with that implementation approach.
However, that approach has significant performance costs on Unix However, that approach has significant performance costs on Unix
systems, and this extension is designed for environments where systems, and this extension is designed for environments where
efficiency is a relatively high priority deployment goal. So this efficiency is a relatively high priority deployment goal. So this
extension is appropriate for some deployments but may not be extension is appropriate for some deployments but may not be
appropriate for the most security sensitive environments. appropriate for the most security sensitive environments.
IMAP server implementations are complicated and can retain a lot of IMAP server implementations are complicated and can retain a lot of
state related to an authenticated user. Server implementers need to state related to an authenticated user. Server implementers need to
take care to reset all server state such that authentication as a take care to reset all server state such that authentication as a
skipping to change at page 8, line 31 skipping to change at page 8, line 31
end-user privacy by increasing the difficultly of traffic analysis end-user privacy by increasing the difficultly of traffic analysis
due to connection re-use. due to connection re-use.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
[RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971,
DOI 10.17487/RFC2971, October 2000, DOI 10.17487/RFC2971, October 2000,
<http://www.rfc-editor.org/info/rfc2971>. <https://www.rfc-editor.org/info/rfc2971>.
[RFC3691] Melnikov, A., "Internet Message Access Protocol (IMAP) [RFC3691] Melnikov, A., "Internet Message Access Protocol (IMAP)
UNSELECT command", RFC 3691, DOI 10.17487/RFC3691, UNSELECT command", RFC 3691, DOI 10.17487/RFC3691,
February 2004, <http://www.rfc-editor.org/info/rfc3691>. February 2004, <https://www.rfc-editor.org/info/rfc3691>.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, DOI 10.17487/RFC4314, December 2005, RFC 4314, DOI 10.17487/RFC4314, December 2005,
<http://www.rfc-editor.org/info/rfc4314>. <https://www.rfc-editor.org/info/rfc4314>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006, DOI 10.17487/RFC4422, June 2006,
<http://www.rfc-editor.org/info/rfc4422>. <https://www.rfc-editor.org/info/rfc4422>.
[RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
Simple Authentication and Security Layer (SASL) Initial Simple Authentication and Security Layer (SASL) Initial
Client Response", RFC 4959, DOI 10.17487/RFC4959, Client Response", RFC 4959, DOI 10.17487/RFC4959,
September 2007, <http://www.rfc-editor.org/info/rfc4959>. September 2007, <https://www.rfc-editor.org/info/rfc4959>.
[RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978,
DOI 10.17487/RFC4978, August 2007, DOI 10.17487/RFC4978, August 2007,
<http://www.rfc-editor.org/info/rfc4978>. <https://www.rfc-editor.org/info/rfc4978>.
[RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP [RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March
2008, <http://www.rfc-editor.org/info/rfc5161>. 2008, <https://www.rfc-editor.org/info/rfc5161>.
[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last
SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March
2008, <http://www.rfc-editor.org/info/rfc5182>. 2008, <https://www.rfc-editor.org/info/rfc5182>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
Message Access Protocol Internationalization", RFC 5255, Message Access Protocol Internationalization", RFC 5255,
DOI 10.17487/RFC5255, June 2008, DOI 10.17487/RFC5255, June 2008,
<http://www.rfc-editor.org/info/rfc5255>. <https://www.rfc-editor.org/info/rfc5255>.
[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267,
DOI 10.17487/RFC5267, July 2008, DOI 10.17487/RFC5267, July 2008,
<http://www.rfc-editor.org/info/rfc5267>. <https://www.rfc-editor.org/info/rfc5267>.
[RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464,
DOI 10.17487/RFC5464, February 2009, DOI 10.17487/RFC5464, February 2009,
<http://www.rfc-editor.org/info/rfc5464>. <https://www.rfc-editor.org/info/rfc5464>.
[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP [RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465, NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465,
February 2009, <http://www.rfc-editor.org/info/rfc5465>. February 2009, <https://www.rfc-editor.org/info/rfc5465>.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186,
DOI 10.17487/RFC6186, March 2011,
<http://www.rfc-editor.org/info/rfc6186>.
[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP [RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
2013, <http://www.rfc-editor.org/info/rfc6855>. 2013, <https://www.rfc-editor.org/info/rfc6855>.
[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
Changes Resynchronization (CONDSTORE) and Quick Mailbox Changes Resynchronization (CONDSTORE) and Quick Mailbox
Resynchronization (QRESYNC)", RFC 7162, Resynchronization (QRESYNC)", RFC 7162,
DOI 10.17487/RFC7162, May 2014, DOI 10.17487/RFC7162, May 2014,
<http://www.rfc-editor.org/info/rfc7162>. <https://www.rfc-editor.org/info/rfc7162>.
[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,
<https://www.rfc-editor.org/info/rfc8314>.
Appendix A. Design Considerations Appendix A. Design Considerations
The author deliberately choose to add a separate UNAUTHENTICATE The author deliberately choose to add a separate UNAUTHENTICATE
command instead of allowing the LOGIN or AUTHENTICATE commands to be command instead of allowing the LOGIN or AUTHENTICATE commands to be
issued when the connection is in a state other than unauthenticated issued when the connection is in a state other than unauthenticated
state. The primary reason for this choice is because the code that state. The primary reason for this choice is because the code that
transitions from not authenticated state to authenticated state in a transitions from not authenticated state to authenticated state in a
server is often the most security sensitive code as it needs to server is often the most security sensitive code as it needs to
assume and handle unconditionally hostile attackers. That sensitive assume and handle unconditionally hostile attackers. That sensitive
 End of changes. 30 change blocks. 
44 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/